From owner-ibis Thu May 1 15:17:50 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id PAA25497 for ; Thu, 1 May 1997 15:17:48 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 1 May 97 15:17 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 May 97 15:17 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 May 97 15:17 PDT Message-Id: Date: Thu, 1 May 97 15:17 PDT From: bob@icx.com ( Bob Ross) To: FYT46205@pcvan.or.jp, ibis@vhdl.org Subject: IBIS TREE Ogawa-san and IBIS community: I am forwarding part of a private note because it contains a nice outline of the IBIS keywords in a tree configuration. This should be useful when reading IBIS Version 2.1 to understand where the keywords fit in. Best Regards, Bob Ross Interconnectix Date: Thu, 01 May 1997 22:28:24 +0900 From: =?ISO-2022-JP?B?GyRCPi5AbiEhRkY7VhsoQg==?= To: bob@icx.com Subject: Re:IBIS Version 2.1 Terminology Suggestions Dear Mr. Bob Ross snip ... In this vacation, I make tree figure of .ibs file. (Show last section.) I have a plan of IBIS explanation meeting. I may use this tree at the time. I know some problems in the tree. One is [Comment char]. IBIS template said "The [Comment char] keyword can be used throughout the file, as desired". But I think that, limitted use makes a few problems. I can't find a advantage of free use of [Comment char] keyword. I can find a advantage of free use of comment character(pipe). Mr. Bob , If you feel some advantege of this tree figure, please use this format to the next version. Best Regards, Atsushi Ogawa at my house e-mail FYT46205@pcvan.or.jp (I can use at my house) .ibs FILE --------- |-- File date section | ----------------- | |-- [IBIS Ver] | |-- [Comment char] | |-- [File name] | |-- [File Rev] | |-- [Date] | |-- [Source] | |-- [Notes] | |-- [Disclaimer] | |-- [Copyright] | |-- [Component] | ----------- | |-- [Manufacturer] | |-- [Package] | |-- [Pin] | |-- [Package Model] | |-- [Pin Mapping] | |-- [Diff Pin] | |-- [Model] | | ------- | | |-- [Temperature Range] | | |-- [Voltage Range] | | |-- [Pullup Reference] | | |-- [Pulldown Reference] | | |-- [POWER Clamp Reference] | | |-- [GND Clamp Reference] | | |-- [Pulldown] | | |-- [Pullup] | | |-- [GND Clamp] | | |-- [POWER Clamp] | | |-- [Rgnd] | | |-- [Rpower] | | |-- [Rac] | | |-- [Cac] | | |-- [Ramp] | | |-- [Rising Waveform] | | |-- [Falling Waveform] | | | |-- [Model] | | |-- [Component] | | |-- [Define Package Model] | ---------------------- | |-- [Manufacturer] | |-- [OEM] | |-- [Description] | |-- [Number of Pins] | |-- [Pin Numbers] | |-- [Model Data] | | ------------ | | |-- [Resistance Matrix] | | | ------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [Inductance Matrix] | | | ------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [Capacitance Matrix] | | | -------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [End Model Data] | |-- [End Package Model] | |-- [Define Package Model] | |-- [End] SHORT TYPE .ibs FILE --------- |-- File date section | ----------------- | |-- [IBIS Ver], [Comment char], [File name], [File Rev], [Date] | |-- [Source], [Notes], [Disclaimer], [Copyright] | |-- [Component] | ----------- | |-- [Manufacturer], [Package], [Pin], [Package Model], [Pin Mapping] | |-- [Diff Pin] | |-- [Model] | | ------- | | |-- [Temperature Range], [Voltage Range], [Pullup Reference] | | |-- [Pulldown Reference], [POWER Clamp Reference] | | |-- [GND Clamp Reference], [Pulldown], [Pullup], [GND Clamp] | | |-- [POWER Clamp], [Rgnd], [Rpower], [Rac], [Cac], [Ramp] | | |-- [Rising Waveform], [Falling Waveform] | | | |-- [Model] | | |-- [Component] | | |-- [Define Package Model] | ---------------------- | |-- [Manufacturer], [OEM], [Description], [Number of Pins] | |-- [Pin Numbers] | |-- [Model Data] | | ------------ | | |-- [Resistance Matrix] | | | ------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [Inductance Matrix] | | | ------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [Capacitance Matrix] | | | -------------------- | | | |-- [Bandwidth] | | | |--[Row] | | | |--[Row] | | | | ｜ | | |-- [End Model Data] | | | |-- [End Package Model] | |-- [Define Package Model] | |-- [End] Atsushi Ogawa Manager Memory Engineering Department Semiconductor Solution Engineering Division NEC Corporation e-mail FYT46205@pcvan.or.jp p.s. Please correction [Temperature] to [Temperature Range] in "NOTES ON DATA DERIVATION METHOD" section. (2-points) I'm sorry. I can't show the line number, because of my house personal computer haven't line number counter program! From owner-ibis Fri May 2 12:30:24 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA14744 for ; Fri, 2 May 1997 12:30:22 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 2 May 97 12:29 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 2 May 97 12:29 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 2 May 97 12:29 PDT Message-Id: Date: Fri, 2 May 97 12:29 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 5/9/97 IBIS Open Forum Meeting Agenda for 5/9/97 Bridge Number Reservation # Passcode (916) 356-9200 1-137661 81111263 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions DAC97 IBIS Meeting Planning Rusher International Progress Rusher/Ross Cookbook Rokusek/Peters FAQ Update Huq s2ibis2 Issues (& NT) Dodd New Administrative Issues All 8:50 Technical Discussion BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Fitzpatrick Connector Status Peters Switched Terminators Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri May 2 13:51:19 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA16151 for ; Fri, 2 May 1997 13:51:19 -0700 (PDT) Received: from us8rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA26389; Fri, 2 May 1997 16:44:48 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA26456; Fri, 2 May 97 16:43:47 -0400 Message-Id: <9705022043.AA26456@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Fri, 2 May 97 16:45:06 EDT Date: Fri, 2 May 97 16:45:06 EDT From: Andy Ingraham To: ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org Subject: IBIS version 2.0 spec is missing, corrupt In case anyone cares.... The IBIS spec version 2.0 file appears to be corrupt. It ends rather abruptly. The file can be found at: ftp://ftp.vhdl.org/pub/ibis/ver2.0/ver2_0.txt or http://www.vhdl.org/pub/ibis/ver2.0/ver2_0.txt which is linked to from the bottom of the IBIS homepage, http://www.eia.org/eig/ibis/ibis.htm I can find no ver2_0.ibs ... it looks like that file got wiped out entirely! ver2_0.txt is the DOS'ified version with carriage-return line breaks. I hope there is a backup copy of both files, somewhere. Regards, Andy From owner-ibis Fri May 2 15:15:18 1997 Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA17612 for ; Fri, 2 May 1997 15:15:11 -0700 (PDT) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id PAA04148 for ; Fri, 2 May 1997 15:14:28 -0700 (PDT) Received: from hpnmhjw.sr.hp.com (hpsrpoh.sr.hp.com) by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA074131267; Fri, 2 May 1997 15:14:27 -0700 Received: by hpnmhjw.sr.hp.com (1.37.109.16/15.5+ECS 3.3) id AA023711267; Fri, 2 May 1997 15:14:27 -0700 From: Jian Yang Message-Id: <199705022214.AA023711267@hpnmhjw.sr.hp.com> Subject: unsubscribe To: ibis@vhdl.org Date: Fri, 2 May 1997 15:14:26 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Please remove me from ibis distribution list. jyang@sr.hp.com From owner-ibis Fri May 2 16:15:40 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id QAA18665 for ; Fri, 2 May 1997 16:15:39 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id QAA25657 for ; Fri, 2 May 1997 16:10:57 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma024827; Fri, 2 May 97 16:09:57 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28429 for ibis@vhdl.org; Fri, 2 May 97 16:13:47 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA20654; Fri, 2 May 97 16:17:16 PDT Date: Fri, 2 May 97 16:17:16 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9705022317.AA20654@rockie.nsc.com> To: ibis@vhdl.org Subject: Call for papers - DAC97 IBIS summit Cc: huq@rockie.nsc.com IBIS fans, IBIS Summit at DAC'97 June12th 1997 Anaheim, CA C a l l f o r P a p e r s / P r e s e n t a t i o n s ------------------------------------------------------------------------- The ANSI/EIA-656 IBIS Committee will have it's yearly summit meeting during the Design Automation Conference(DAC) on June12th 1997. This is a summit meeting to share information, discuss technical challenges, and ratify IBISv3.0 We would like this DAC97 summit to address experiences, success stories, technical challenges etc from the Users, Model providers, EDA vendors and any interested groups. So, here is the call for presentation. We would like to keep the format similar to the last year's meeting. Meaning, each speaker will get 15 to 20 minutes to present. You do not have to be a member to attend the meeting. Pls forward your presentation ideas and the amount of time you will need to either Bob Ross(bob@icx.com) Interconnectix Syed Huq(huq@rockie.nsc.com) National Semiconductor Corp Jon Powell(jon@qdt.com) Quad Design We will put an agenda together based on topics to be covered and the number of papers to be presented. Your prompt responses will be highly appreciated. Best Regards, Syed Huq Vice-Chair ANSI/EIA-656 National Semiconductor Corp. From owner-ibis Fri May 2 18:01:35 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA20413 for ; Fri, 2 May 1997 18:01:34 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 2 May 97 18:00 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 2 May 97 18:00 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 2 May 97 18:00 PDT Message-Id: Date: Fri, 2 May 97 18:00 PDT From: bob@icx.com ( Bob Ross) To: ingraham@wrksys.enet.dec.com Subject: Re: IBIS version 2.0 spec is missing, corrupt Cc: ibis@vhdl.org Andy: You are right! I put replacement version of ver2_0.txt and ver2_0.ibs on vhdl.org. Best Regards, Bob Ross, Interconnectix > Date: Fri, 2 May 97 18:03:27 EDT > From: Andy Ingraham > To: bob@icx.com > Cc: ingraham@wrksys.ENET.dec.com > Apparently-To: bob@icx.com > Subject: Re: IBIS version 2.0 spec is missing, corrupt > Status: R > Hi Bob, > "ver2_0.txt" _is_ there ... but it's truncated! > "ver2_0.ibs" is entirely missing. > Regards, > Andy > > Andy: > > > > ver2_0.txt seems to download OK for me with Netscape 3 > > on a Sun system using both http and ftp. The file > > still exists on the system. > > > > You may have some other problem. > > > > Bob Ross > > Interconnectix > > > > > Date: Fri, 2 May 97 16:45:06 EDT > > > From: Andy Ingraham > > > To: ibis@vhdl.org > > > Cc: ingraham@wrksys.ENET.dec.com > > > Apparently-To: ibis@vhdl.org > > > Subject: IBIS version 2.0 spec is missing, corrupt > > > Status: RO > > > > > In case anyone cares.... > > > > > The IBIS spec version 2.0 file appears to be corrupt. It ends rather > > > abruptly. > > > > > The file can be found at: > > > > > ftp://ftp.vhdl.org/pub/ibis/ver2.0/ver2_0.txt or > > > http://www.vhdl.org/pub/ibis/ver2.0/ver2_0.txt > > > > > which is linked to from the bottom of the IBIS homepage, > > > http://www.eia.org/eig/ibis/ibis.htm > > > > > I can find no ver2_0.ibs ... it looks like that file got wiped out > > > entirely! ver2_0.txt is the DOS'ified version with carriage-return > > > line breaks. > > > > > I hope there is a backup copy of both files, somewhere. > > > > > Regards, > > > Andy From owner-ibis Sat May 3 23:06:54 1997 Received: from omni.taec.com (ns.taec.com [204.162.152.5]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id XAA14208 for ; Sat, 3 May 1997 23:06:54 -0700 (PDT) Received: from lisburn.taec.com by omni.taec.com (8.6.12/Toshiba-AEC-RELAY.1) id XAA28388; Sat, 3 May 1997 23:06:03 -0700 Received: from jakarta.sanjose (jakarta.taec.com [204.162.154.60]) by lisburn.taec.com (8.8.5/8.8.5) with SMTP id XAA01073 for ; Sat, 3 May 1997 23:04:47 -0700 (PDT) Date: Sat, 3 May 1997 23:04:47 -0700 (PDT) From: Yu-Tai Chia Message-Id: <199705040604.XAA01073@lisburn.taec.com> To: ibis@vhdl.org Subject: unsubscribe Thank you for your nice service. Please remove me from you distribution list. Thanks & Regards, Chia, Yu-Tai From owner-ibis Sun May 4 15:03:54 1997 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA29284 for ; Sun, 4 May 1997 15:03:54 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id PAA26280; Sun, 4 May 1997 15:02:59 -0700 (PDT) Message-Id: <3.0.32.19970504150259.006c4e10@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 04 May 1997 15:03:00 -0700 To: jerry.isaac@amd.com, ibis@vhdl.org From: Kellee Crisafulli Subject: Jerry's questions re: [Rising Waveform], [Falling Waveform] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Jerry, >Hello, I'm seeking some advice about the subject keywords. I have included >them in a model I've developed for a customer (since the drivers I'm modeling >do have slew rate control), but I'm not entirely sure how simulators use >the V/T tables versus using the [Ramp] data. In particular, I have the >following questions: > >1) What xxx_fixture values should I specify for my SPICE simulations (and >hence place into the IBIS model)? I would suggest a value that reflects typical usage of your device. >2) Should the xxx_fixture values vary for each customer based on their >application? For simplicity I would recommend creating a single V/T for use by all customers unless your outputs are relatively high impedance. Say > 15 ohms. Most CMOS outputs today are less than 10 ohms, many are less than 3 ohms. (This is a rough guess so don't shoot me if I am off a few ohms) >3) What would happen (in other words, what would a simulator do?) if the >V/T tables use a different loading assumption than the assumptions used >to produce the dV/dt_r and dV/dt_f values? (a response that this is not >appropriate for an IBIS model would be acceptable to me). It depends on the simulator. V/T curves are provided to augment the data available in the dV/dt_r and dV/dt_f fields. Some simulators ignore V/T tables since dV/dt_r and dV/dt_f are required. Some use only the first table found Some will attempt to regressively construct a driver model from all the tables provided under all the load conditions provided. I don't know of any simulator that does a perfect job of the later. The biggest problem is that getting all the rise/fall data and the tables to match is very complex and highly prone to error. Many routines will fall back to the simplest methods if they detect discrepancies with the complex methods. >4) Would the simulations be any less accurate if I simply didn't include >the V/T tables? Probably but it may not be a large difference, it is also possible to have more accurate simulations without V/T tables. There are conditions that could cause the smart algorithms that interpret the V/T data to create slew curves that are worse than the result provided with a simple dV/dt_r spec. The goal of V/T tables is two fold: 1) Provide a "specification waveform" for the output into a load. 2) Provide data to "improve" the output characteristics. Item 1 could be used by a model developer as a manual verification when testing models to insure that the dV/dt_r and dt_f data is working properly. Item 2 could be used to "tune" the simulation to achieve better matching for the specified load. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx Inc. kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Mon May 5 09:03:58 1997 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA15479 for ; Mon, 5 May 1997 09:03:58 -0700 (PDT) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.39]) id QQcofw02433; Mon, 5 May 1997 12:03:25 -0400 (EDT) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 5 May 1997 12:03:14 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00785; Mon, 5 May 97 08:49:09 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA13878; Mon, 5 May 97 08:49:09 PDT Sender: jonp@qdt.com Message-Id: <336E014C.59E2B600@qdt.com> Date: Mon, 05 May 1997 08:48:28 -0700 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: uunet!amd.com!jerry.isaac@uunet.uu.net Cc: ibis@vhdl.org Subject: Re: Questions re: [Rising Waveform], [Falling Waveform] References: <"ISOPRO::DH-EF::7CBC::336BC2F0"*/G=Jerry/S=Isaac/O=camta4/PRMD=AMD/ADMD=ATTMAIL/C=US@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My recommendations differ a little from Kelle's, no doubt they are simulator specific and you should seek a set that meet as many as possible: 1) VT tables are absolutely necessary if the part is RISE TIME CONTROL or SLEW RATE CONTROL 2) 1 VT table does not give much more information that simple rise time and fall time (except as a golden waveform standard). 3) The loads used to generate the VT tables are technology dependent. For most CMOS components the 50ohm to VCC, 50 ohm to GND are in the right range. 4) Whether or not the VT tables make the model more accurate is dependent on the technology of the driver. I suggest you try some simulations with some representative simulators and see if the accuracy meets your needs. regards and happy ibising Jon Powell Senior Scientist, Viewlogic/Quad Design From owner-ibis Tue May 6 13:10:07 1997 Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA11765 for ; Tue, 6 May 1997 13:10:06 -0700 (PDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id PAA04596 for ; Tue, 6 May 1997 15:08:54 -0500 (CDT) Date: Tue, 6 May 1997 15:08:54 -0500 (CDT) Message-Id: <199705062008.PAA04596@dfw-ix1.ix.netcom.com> Received: from tam-fl10-04.ix.netcom.com(207.93.39.68) by dfw-ix1.ix.netcom.com via smap (V1.3) id sma004572; Tue May 6 15:08:50 1997 From: jcimbak@ix.netcom.com (Joe J Cimbak) Subject: The Search is ON!! To: ibis@vhdl.org Good Day! I am a search recruiter and I am doing a MAJOR search for a very large US based company. I am trying to find 150 qualified ASIC engineers for this client. If you know of anyone who is interested in ASIC design employment please have them contact me via email at jcimbak@ix.netcom.com or directly at 813-659-2239 (ofc.), 813-719-3869 (fax), 813-289-1588 (fax, alternate). Skills sought are: Custom circuit design specification, architecture, behavioral modeling, synthesis, floor planning and layout. I am also interested in people skilled in wafer fabrication and packaging. Specific skills: Serial/parallel communication cores and chips FPGA's RF design environment Signal integrity issues A/D interface verification HDL/Verilog SONET physical layer technology Signal processing algorithms Simulation tools Test tools Timing analyis tools C/C++/Visual C UNIX Lan/Wan, Ethernet, ATM, ISDN, HDLC Any other ASIC specialties All interested parties with any experience are encouraged to apply. Applicants from outside of the US can be assured of being sponsored for an H1 visa if hired. Salary ranges from mid $50k (for only college laboratory e xperience) to $130k+ for very qualified and experienced candidates. All applicants should submit resumes which include a section that describes specific ASIC design projects that they participated in and what their role was in these projects. Please forward this email freely!!! Cordially...and at your service! Joe Cimbak From owner-ibis Tue May 6 14:42:48 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id OAA13960 for ; Tue, 6 May 1997 14:42:38 -0700 (PDT) Date: Tue, 6 May 1997 17:39:38 -0400 Message-Id: <199705062139.RAA24952@wile.nesa.com> Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma024950; Tue May 6 17:39:16 1997 X-Sender: esayre@mail.nesa.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jcimbak@ix.netcom.com (Joe J Cimbak) From: "Dr. Edward P. Sayre" Subject: Re: The Search is ON!! Cc: ibis@vhdl.org Don't use this forum for commercial recruiting purposes. I will complain to IBIS loud and clear!!!!! ed sayre At 03:08 PM 5/6/97 -0500, you wrote: >Good Day! > >I am a search recruiter and I am doing a MAJOR search for a very large US based company. I am trying to find 150 qualified ASIC engineers for this client. If you know of anyone who is interested in ASIC design employment > please have them contact me via email at jcimbak@ix.netcom.com or directly at 813-659-2239 (ofc.), 813-719-3869 (fax), 813-289-1588 (fax, alternate). > >Skills sought are: >Custom circuit design specification, architecture, behavioral modeling, synthesis, floor planning and layout. I am also interested in people skilled in wafer fabrication and packaging. > >Specific skills: >Serial/parallel communication cores and chips >FPGA's >RF design environment >Signal integrity issues >A/D interface verification >HDL/Verilog >SONET physical layer technology >Signal processing algorithms >Simulation tools >Test tools >Timing analyis tools >C/C++/Visual C >UNIX >Lan/Wan, Ethernet, ATM, ISDN, HDLC >Any other ASIC specialties > >All interested parties with any experience are encouraged to apply. Applicants from outside of the US can be assured of being sponsored for an H1 visa if hired. Salary ranges from mid $50k (for only college laboratory e >xperience) to $130k+ for very qualified and experienced candidates. All applicants should submit resumes which include a section that describes specific ASIC design projects that they participated in and what their role >was in these projects. > >Please forward this email freely!!! > >Cordially...and at your service! >Joe Cimbak > > +‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾+ From owner-ibis Wed May 7 09:36:08 1997 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA01745; Wed, 7 May 1997 09:36:07 -0700 (PDT) Received: from us8rmc.bb.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA14230; Wed, 7 May 1997 12:21:25 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA20126; Wed, 7 May 97 12:20:54 -0400 Message-Id: <9705071620.AA20126@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Wed, 7 May 97 12:21:06 EDT Date: Wed, 7 May 97 12:21:06 EDT From: Andy Ingraham 07-May-1997 1214 To: ibis@vhdl.org Cc: ibis-info@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis-info@vhdl.org, ibis@vhdl.org Subject: Interpretation of Minimum/Maximum data in IBIS This is a request for clarification. The IBIS spec is a very perplexing document. I have a ton of problems with it, and one of these days, when I can find the time, maybe I will list some of them. Regarding minimum/maximum data, is the following supposed to be correct? For the V/I data under the [Pulldown], [Pullup], [GND Clamp], and [POWER Clamp] keywords, the "min" column always represents the "slow, weak" extreme and the "max" column always represents the "fast, strong" extreme of device performance. Likewise, for the [Ramp], [Rising Waveform], and [Falling Waveform] sections, the "min" column always represents the same "slow, weak" extreme and the "max" column always represents the same "fast, strong" extreme of device performance. Thus, the computed dV/dt_* value in the "min" column ought to be the smallest (slowest) of the three, and the one in the "max" column should be the largest (fastest). Under [Rising Waveform] and [Falling Waveform] keywords, V_fixture_min always represents the fixture load voltage used to collect the data in the "min" column, and V_fixture_max always represents the voltage used for the data in the "max" column. The spec doesn't say this, but I think it is the only meaning that makes sense. For the [Package] keyword, the "min" column always represents minimum resistance, minimum inductance, and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Rgnd], [Rpower], [Rac], and [Cac] keywords, the "min" column always represents minimum resistance and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the C_comp sub-parameter under the [Model] keyword, the "min" column always represents minimum capacitance values; and the "max" column always represents maximum capacitance. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Temperature Range] keyword, the "min" column always represents the lowest junction temperature for device operation, and the "max" column always represents highest junction temperature. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Voltage Range] keyword, the "min" column always represents the lowest operating voltage for device operation, and the "max" column always represents the highest voltage. There is no implied relationship between these values and the device performance (fast/slow/strong/weak) (although I know of no device whose speed does not vary in the same direction as the voltage). For the [Pullup Reference], [Pulldown Reference], [POWER Clamp Reference], and [GND Clamp Reference] keywords, the "min" column always represents the values associated with the "min" columns in the [Rising Waveform], [Falling Waveform], and [Ramp] sections; and the "max" column always associates with the "max" columns in those sections. Thus, the values in the "min" columns must be the ones that cause the "slow, weak" extreme, and the values in the "max" columns must correspond to the "fast, strong" extreme. So, how well did I do? I know that one or two of these are likely to cause some discussion. I see, for example, that s2ibis2 apparently treats the [Temperature Range] keyword differently; but the way I wrote it above, is the way I read it in the spec. (I'm not sure that it matters in that case anyway, because as far as I can tell, [Temperature Range] is only there for reference ... what would a simulator ever do with it?) Regards, Andy Ingraham From owner-ibis Wed May 7 11:52:19 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA04194; Wed, 7 May 1997 11:52:13 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Wed, 7 May 1997 18:51:21 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id LAA20960; Wed, 7 May 1997 11:51:58 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 07 May 97 11:51:58 PDT Date: Wed, 07 May 97 11:44:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: ibis-info@vhdl.org, ingraham@wrksys.enet.dec.com Subject: Re: Interpretation of Minimum/Maximum data in IBIS Text item: Andy, and all IBIS gurus, If you read the spec carefully, you will find the following in the data derivations methods section: | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. So your statement below is not completely true (for CMOS). At the same time, I think the spec needs to be fixed, because there is no such thing as {Temperature] keyword, only [Temperature Range], yet the comments use the first one in several occasions. I don't have the time to comment on the rest of your message... Arpad Muranyi Intel Corporation ============================================================================== This is a request for clarification. The IBIS spec is a very perplexing document. I have a ton of problems with it, and one of these days, when I can find the time, maybe I will list some of them. Regarding minimum/maximum data, is the following supposed to be correct? For the V/I data under the [Pulldown], [Pullup], [GND Clamp], and [POWER Clamp] keywords, the "min" column always represents the "slow, weak" extreme and the "max" column always represents the "fast, strong" extreme of device performance. Likewise, for the [Ramp], [Rising Waveform], and [Falling Waveform] sections, the "min" column always represents the same "slow, weak" extreme and the "max" column always represents the same "fast, strong" extreme of device performance. Thus, the computed dV/dt_* value in the "min" column ought to be the smallest (slowest) of the three, and the one in the "max" column should be the largest (fastest). Under [Rising Waveform] and [Falling Waveform] keywords, V_fixture_min always represents the fixture load voltage used to collect the data in the "min" column, and V_fixture_max always represents the voltage used for the data in the "max" column. The spec doesn't say this, but I think it is the only meaning that makes sense. For the [Package] keyword, the "min" column always represents minimum resistance, minimum inductance, and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Rgnd], [Rpower], [Rac], and [Cac] keywords, the "min" column always represents minimum resistance and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the C_comp sub-parameter under the [Model] keyword, the "min" column always represents minimum capacitance values; and the "max" column always represents maximum capacitance. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Temperature Range] keyword, the "min" column always represents the lowest junction temperature for device operation, and the "max" column always represents highest junction temperature. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Voltage Range] keyword, the "min" column always represents the lowest operating voltage for device operation, and the "max" column always represents the highest voltage. There is no implied relationship between these values and the device performance (fast/slow/strong/weak) (although I know of no device whose speed does not vary in the same direction as the voltage). For the [Pullup Reference], [Pulldown Reference], [POWER Clamp Reference], and [GND Clamp Reference] keywords, the "min" column always represents the values associated with the "min" columns in the [Rising Waveform], [Falling Waveform], and [Ramp] sections; and the "max" column always associates with the "max" columns in those sections. Thus, the values in the "min" columns must be the ones that cause the "slow, weak" extreme, and the values in the "max" columns must correspond to the "fast, strong" extreme. So, how well did I do? I know that one or two of these are likely to cause some discussion. I see, for example, that s2ibis2 apparently treats the [Temperature Range] keyword differently; but the way I wrote it above, is the way I read it in the spec. (I'm not sure that it matters in that case anyway, because as far as I can tell, [Temperature Range] is only there for reference ... what would a simulator ever do with it?) Regards, Andy Ingraham Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Interpretation of Minimum/Maximum data in IBIS Apparently-To: ibis-info@vhdl.org, ibis@vhdl.org Cc: ibis-info@vhdl.org, ingraham@wrksys.ENET.dec.com To: ibis@vhdl.org From: Andy Ingraham 07-May-1997 1214 Date: Wed, 7 May 97 12:21:06 EDT Received: from wrksys.enet; by us8rmc.enet; Wed, 7 May 97 12:21:06 EDT Message-Id: <9705071620.AA20126@us8rmc.bb.dec.com> Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA20126; Wed, 7 May 97 12:20:54 -0400 Received: from us8rmc.bb.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA14230; Wed, 7 May 1997 12:21:25 -0400 (EDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by server .vhdl.org (8.8.5/8.8.3) with ESMTP id JAA01745; Wed, 7 May 1997 09:36:07 -0700 ( PDT) Received: from server.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id JAA06870; Wed, 7 May 1997 09:45:33 -0700 (PDT) Received: from ormail.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0wP9s9-000qDNC; Wed, 7 May 97 09:47 PDT From owner-ibis Wed May 7 11:56:42 1997 Received: from ferrari.sfu.ca (root@ferrari.sfu.ca [142.58.110.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA04202 for ; Wed, 7 May 1997 11:56:39 -0700 (PDT) Received: from fraser (fraser [192.168.0.101]) by ferrari.sfu.ca with SMTP (8.8.5/SFU-2.7H) id LAA12367 for (from roland@sfu.ca); Wed, 7 May 1997 11:55:49 -0700 (PDT) From: Roland James Chang Received: by fraser (950413.SGI.8.6.12/SFU-2.6C) id LAA20622 for ibis@vhdl.org (from roland@sfu.ca); Wed, 7 May 1997 11:55:48 -0700 Message-Id: <199705071855.LAA20622@fraser> Subject: help with S2IBIS utility To: ibis@vhdl.org Date: Wed, 7 May 1997 11:55:48 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I'm looking for any information on how to use the S2IBIS utility. I have looked through some application notes from CADENCE, as well as some of the syntatctical descriptions of IBIS files versions 1.0 to 2.1. In particular, I'm having trouble with the syntax of the input files that are fed into the S2IBIS utility. Input files are to consist of 3 parts: 1. Header 2. Modified IBIS pin list 3. Spice Input Deck I am having trouble formulating sections 2 and 3. I would be especially interested in any examples that could be provided showing complete input file/output file pairs that were applied to the S2IBIS conversion. Once again, any help would be greatly appreciated, as I have been assigned the task of SPICE to IBIS model conversion for many IC's at work. thanx in advance, roland please send replies to roland@sfu.ca From owner-ibis Wed May 7 13:11:25 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA05389; Wed, 7 May 1997 13:11:24 -0700 (PDT) Received: from us8rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA11368; Wed, 7 May 1997 16:02:25 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA05660; Wed, 7 May 97 15:57:13 -0400 Message-Id: <9705071957.AA05660@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Wed, 7 May 97 16:02:46 EDT Date: Wed, 7 May 97 16:02:46 EDT From: Andy Ingraham To: arpad_muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org, ibis-info@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis-info@vhdl.org, ibis@vhdl.org, arpad_muranyi@ccm.fm.intel.com Subject: Re: Interpretation of Minimum/Maximum data in IBIS Arpad, As long as you brought up the [Temperature] keyword, I might as well address that particular issue. That was one of the (many) things about the spec that bothers the heck out of me. There is no [Temperature] keyword! Yes I know [Temperature] is mentioned in that paragraph in the back of the spec that you quoted; but if [Temperature] ever was a keyword, it is not defined anywhere in the spec. Are you trying to tell me that [Temperature] and [Temperature Range] are supposed to be equivalent? If so, then {FLAME ON} this is no way to write a specification. They sure are not equivalent to me. Plus you can't define a keyword, saying simply that it has min and max values, thereby implying that they are the min and max temperatures, and giving no hint that they mean anything else ... and then 1050 lines later, at the bottom of the spec, explain that they really mean something entirely different. When I pick up a specification to check on some particular item, I don't want to have to read it front to back, and then go back and cross-reference everything that was "defined" over here but then "defined" some more over there, and so on and so forth. PUT IT ALL TOGETHER IN ONE PLACE. In my opinion, the IBIS Spec needs a major re-write from start to finish before it can be used. I cannot understand why it has taken IBIS four years to get to this point yet it still doesn't have a spec that hangs together. {flame off} Regards, Andy Ingraham From owner-ibis Wed May 7 14:00:43 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA06153; Wed, 7 May 1997 14:00:43 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Wed, 7 May 1997 20:57:17 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id NAA06418; Wed, 7 May 1997 13:57:55 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 07 May 97 13:57:54 PDT Date: Wed, 07 May 97 13:53:00 PDT From: Arpad Muranyi Message-ID: cc: ibis@vhdl.org, ibis-info@vhdl.org, ingraham@wrksys.enet.dec.com Subject: Re[2]: Interpretation of Minimum/Maximum data in IBIS Text item: Andy, You are actually repeating my words alsmost exactly between the flames on/off sections, including the flames... I brought this up in the times when the ver. 2.0 spec was formulating. That is when the keyword [Temperature Range] was added. IBIS 1.1 didn't have a keyword for it, it was only described in the data derivation section that slow and fast conditions were supposed to include temperature and voltage supply variations. When the keyword was discussed it was decided by the open forum attendees, that it was not necessary to describe the meaning of min and max under the keyword description section, because it was already written down in the data derivation section. I didn't like that at all for the same reason you don't... (By the way, I checked, and in my file it was 1048 lines later...) Regarding the two kinds of keywords, it was probably just an oversight. Usually before a keywords get approved, it goes through several iterations, and whoever wrote it must have not changed each occurance, and noone caught it. Arpad ================================================================================ Arpad, As long as you brought up the [Temperature] keyword, I might as well address that particular issue. That was one of the (many) things about the spec that bothers the heck out of me. There is no [Temperature] keyword! Yes I know [Temperature] is mentioned in that paragraph in the back of the spec that you quoted; but if [Temperature] ever was a keyword, it is not defined anywhere in the spec. Are you trying to tell me that [Temperature] and [Temperature Range] are supposed to be equivalent? If so, then {FLAME ON} this is no way to write a specification. They sure are not equivalent to me. Plus you can't define a keyword, saying simply that it has min and max values, thereby implying that they are the min and max temperatures, and giving no hint that they mean anything else ... and then 1050 lines later, at the bottom of the spec, explain that they really mean something entirely different. When I pick up a specification to check on some particular item, I don't want to have to read it front to back, and then go back and cross-reference everything that was "defined" over here but then "defined" some more over there, and so on and so forth. PUT IT ALL TOGETHER IN ONE PLACE. In my opinion, the IBIS Spec needs a major re-write from start to finish before it can be used. I cannot understand why it has taken IBIS four years to get to this point yet it still doesn't have a spec that hangs together. {flame off} Regards, Andy Ingraham Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Interpretation of Minimum/Maximum data in IBIS Apparently-To: ibis-info@vhdl.org, ibis@vhdl.org, arpad_muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org, ibis-info@vhdl.org, ingraham@wrksys.ENET.dec.com To: arpad_muranyi@ccm.fm.intel.com From: Andy Ingraham Date: Wed, 7 May 97 16:02:46 EDT Received: from wrksys.enet; by us8rmc.enet; Wed, 7 May 97 16:02:46 EDT Message-Id: <9705071957.AA05660@us8rmc.bb.dec.com> Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA05660; Wed, 7 May 97 15:57:13 -0400 Received: from us8rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA11368; Wed, 7 May 1997 16:02:25 -0400 (EDT) Received: from mail11.digital.com by thalia.fm.intel.com (8.8.4/10.0i); Wed, 7 M ay 1997 20:13:17 GMT Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id NAA00780 for ; Wed, 7 May 1997 13:13:56 -0700 (PDT) Return-Path: ingraham@wrksys.ENET.dec.com From owner-ibis Wed May 7 14:30:58 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA06600 for ; Wed, 7 May 1997 14:30:58 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id OAA14159; Wed, 7 May 1997 14:29:32 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id OAA06780; Wed, 7 May 1997 14:29:45 -0700 (PDT) Message-Id: <199705072129.OAA06780@ichips.intel.com> To: ibis@vhdl.org, ingraham@wrksys.enet.dec.com Subject: Interpretation of Minimum/Maximum data in IBIS Date: Wed, 07 May 1997 14:29:45 -0700 From: Stephen Peters Hello Andy: Judging by what you wrote below you have interpreted the relationship between device preformance and the min and max columns correctly. In fact, you have just demonstratated (despite your flames) that the spec *is* comprehensive and clear enough that a resonably intellegent person can interpret it sucsesfully. As Arpad pointed out there is a mistake in the DATA DERIVATION section of the document -- the "[Temperature]" phrase should read "[Temperature Range]". I would invite you to submit a BIRD correcting this. Instructions for submitting a BIRD (buffer issue resolution document) can be found on the IBIS website. Best Regards, Stephen Peters Intel Corp. --------------------------------------------------------------------- This is a request for clarification. The IBIS spec is a very perplexing document. I have a ton of problems with it, and one of these days, when I can find the time, maybe I will list some of them. Regarding minimum/maximum data, is the following supposed to be correct? For the V/I data under the [Pulldown], [Pullup], [GND Clamp], and [POWER Clamp] keywords, the "min" column always represents the "slow, weak" extreme and the "max" column always represents the "fast, strong" extreme of device performance. Likewise, for the [Ramp], [Rising Waveform], and [Falling Waveform] sections, the "min" column always represents the same "slow, weak" extreme and the "max" column always represents the same "fast, strong" extreme of device performance. Thus, the computed dV/dt_* value in the "min" column ought to be the smallest (slowest) of the three, and the one in the "max" column should be the largest (fastest). Under [Rising Waveform] and [Falling Waveform] keywords, V_fixture_min always represents the fixture load voltage used to collect the data in the "min" column, and V_fixture_max always represents the voltage used for the data in the "max" column. The spec doesn't say this, but I think it is the only meaning that makes sense. For the [Package] keyword, the "min" column always represents minimum resistance, minimum inductance, and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Rgnd], [Rpower], [Rac], and [Cac] keywords, the "min" column always represents minimum resistance and minimum capacitance values; and the "max" column always represents maximum values. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the C_comp sub-parameter under the [Model] keyword, the "min" column always represents minimum capacitance values; and the "max" column always represents maximum capacitance. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Temperature Range] keyword, the "min" column always represents the lowest junction temperature for device operation, and the "max" column always represents highest junction temperature. There is no implied relationship between these values and the device performance (fast/slow/strong/weak). For the [Voltage Range] keyword, the "min" column always represents the lowest operating voltage for device operation, and the "max" column always represents the highest voltage. There is no implied relationship between these values and the device performance (fast/slow/strong/weak) (although I know of no device whose speed does not vary in the same direction as the voltage). For the [Pullup Reference], [Pulldown Reference], [POWER Clamp Reference], and [GND Clamp Reference] keywords, the "min" column always represents the values associated with the "min" columns in the [Rising Waveform], [Falling Waveform], and [Ramp] sections; and the "max" column always associates with the "max" columns in those sections. Thus, the values in the "min" columns must be the ones that cause the "slow, weak" extreme, and the values in the "max" columns must correspond to the "fast, strong" extreme. So, how well did I do? I know that one or two of these are likely to cause some discussion. I see, for example, that s2ibis2 apparently treats the [Temperature Range] keyword differently; but the way I wrote it above, is the way I read it in the spec. (I'm not sure that it matters in that case anyway, because as far as I can tell, [Temperature Range] is only there for reference ... what would a simulator ever do with it?) Regards, Andy Ingraham From owner-ibis Wed May 7 14:42:10 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id OAA06731 for ; Wed, 7 May 1997 14:42:09 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id OAA01550; Wed, 7 May 1997 14:41:42 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma000998; Wed, 7 May 97 14:41:07 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA26130 for ibis@vhdl.org; Wed, 7 May 97 14:40:38 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11000; Wed, 7 May 97 14:44:11 PDT Date: Wed, 7 May 97 14:44:11 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9705072144.AA11000@rockie.nsc.com> To: ibis@vhdl.org, roland@sfu.ca Subject: Re: help with S2IBIS utility Roland, I would recommend downloading s2ibis2 v1.1 instead of using s2ibis. There are significant difference between the two. http://www.eia.org/EIG/IBIS/ibis.htm and select 'Tools' and point to NCSU to download the software. After you un'tar, look under the /examples dir for hints on your request for #2, and #3 If you still have problems with syntax, you can post a message (ibis-users@vhdl.org) describing the problem and any users of the tool can respond to you. Best Regards, Syed. National Semiconductor Corp. > From owner-ibis@server.vhdl.org Wed May 7 14:30:37 1997 > From: Roland James Chang > Subject: help with S2IBIS utility > To: ibis@vhdl.org > Date: Wed, 7 May 1997 11:55:48 -0700 (PDT) > X-Mailer: ELM [version 2.4 PL24] > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7bit > > Hello, I'm looking for any information on how to use the S2IBIS utility. > I have looked through some application notes from CADENCE, as well as some > of the syntatctical descriptions of IBIS files versions 1.0 to 2.1. > > In particular, I'm having trouble with the syntax of the input files that > are fed into the S2IBIS utility. Input files are to consist of 3 parts: > > 1. Header > 2. Modified IBIS pin list > 3. Spice Input Deck > > I am having trouble formulating sections 2 and 3. I would be especially > interested in any examples that could be provided showing complete input > file/output file pairs that were applied to the S2IBIS conversion. > > Once again, any help would be greatly appreciated, as I have been assigned > the task of SPICE to IBIS model conversion for many IC's at work. > > thanx in advance, > > roland > please send replies to roland@sfu.ca > From owner-ibis Thu May 8 04:56:49 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id EAA18312 for ; Thu, 8 May 1997 04:56:49 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id EAA04161; Thu, 8 May 1997 04:56:06 -0700 (PDT) X-Authentication-Warning: mailgate.cadence.com: smap set sender to using -f Received: from nakul.cadence.com(158.140.126.64) by mailgate.cadence.com via smap (V1.0mjr) id sma863092563.004146; Thu May 8 04:56:03 1997 Received: (from presi@localhost) by nakul.cadence.com (8.6.8/8.6.8) id RAA08041; Thu, 8 May 1997 17:21:44 +0531 Date: Thu, 8 May 1997 17:21:44 +0531 From: R Sanjeev Message-Id: <199705081150.RAA08041@nakul.cadence.com> To: Arpad_Muranyi@ccm.fm.intel.com Subject: Pulldown for ECL... Cc: ibis@vhdl.org X-Sun-Charset: US-ASCII Hello, The specs says that in case of ECL (VCC +ive voltage supply and VEE -ve voltage supply ) both the pullup and the pulldown are made with reference to VCC and we require to use: Vtable = VCC - Vout. in BOTH cases. This makes sense as in case of a differential pair the same stage will do the pullup and the pulldown. So from my understanding of the specs the Voltage values of the Pullup/Pulldown tables in case of Output_ECL should be the same.eg VCC = 0V and if I simulated Vout for 0 to -2.2V in both cases. The Table should look like: 2.2 x x x 2.1 x x x . . . 0.0 x x x Is this correct? I'm unable to cross check with s2ibis as s2ibis2.1 does not seem to be able to handle Output_ECL when it comes to the [Pulldown] it has put some wierd values. In case of pullup the voltage in the *spi files have been varied from VCC to VCC-2.2 volts and the output in Vtable also followes VCC-Vout. ( And also filled the ibis file with lines of 0.0 0.0 0.0 0.0 after that) The [Pulldown] has been simulated from VCC to VCC-2.2 volts but these values have not been used to fill the table. Voltage column is filled with 0 and -0.1 in the Voltage column. Could someone please comment on this too.(maybe Alan Glaser if he is free) Thanx in advance, regards, presi From owner-ibis Thu May 8 09:49:03 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA23584 for ; Thu, 8 May 1997 09:49:01 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 8 May 97 09:48 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 8 May 97 09:48 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 8 May 97 09:48 PDT Message-Id: Date: Thu, 8 May 97 09:48 PDT From: bob@icx.com ( Bob Ross) To: FYT46205@biglobe.ne.jp, ibis@vhdl.org Subject: Re:IBIS Tree Comments Ogawa-san and IBIS Committee: Thank you for your IBIS Tree Update to Pending Version 3.0, corrections and additions of subparameters. The [Model Selector] keyword is positioned correctly under [Component]. In the next DRAFT version of IBIS version 3.0, I will make the correction you noted on [Model Selector] and also correct three occurances of [Temperature] to [Temperature Range] noted by several people. I am sending you separately a draft of this version which includes a recently approved BIRD36.3 for package model extensions. Your work will be very helpful to us. Best Regards, Bob Ross Interconnectix > Date: Thu, 08 May 1997 11:54:45 +0900 > From: =?ISO-2022-JP?B?GyRCPi5AbiEhRkY7VhsoQg==?= > To: bob@icx.com > Subject: Re:IBIS Tree Comments > Dear Mr. Bob Ross > Thank you for your quick response. > I could understand all by your help. Thank you very much. > I obtained DRAFT OF IBIS VERSION 3.0 from Mr. Fukuda (A leader of > EIAJ I/O interfacemodel project group). > And I tried to write IBIS Tree (VERSION 3.0). > But I can't understand Where [Model Selector] was connected. > If it is in root hierarchy, a selection with [Model Selector] > influences all [Component]. I'm not able consider which is better. > Please teach me where it is connected. > IBIS Tree (DRAFT OF IBIS VERSION 3.0) > .ibs FILE > --------- > |-- File date section > | ----------------- > | |-- [IBIS Ver] > | |-- [Comment char] > | |-- [File name] > | |-- [File Rev] > | |-- [Date] > | |-- [Source] > | |-- [Notes] > | |-- [Disclaimer] > | |-- [Copyright] > | > |-- [Component] > | ----------- > | |-- [Manufacturer] > | |-- [Package] R_pkg, L_pkg, C_pkg > | |-- [Pin] signal_name, model_name, R_pin, L_pin, C_pin > | |-- [Package Model] > | |-- [Pin Mapping] pulldown_ref, pullup_ref, gnd_clamp_ref, > | | power_clamp_ref > | |-- [Diff Pin] inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max > | |-- [Model Selector] > | > |-- [Component] > | > | > |-- [Model] Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref, > | ------- Rref, Vref > | | > | |-- [Model Spec] Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, > | | S_overshoot_high, S_overshoot_low, D_overshoot_high > , > | | D_overshoot_low, D_overshoot_time, Pulse_high, > | | Pulse_low, Pulse_time > | |-- [Driver Schedule] > | |-- [Temperature Range] > | |-- [Voltage Range] > | |-- [Pullup Reference] > | |-- [Pulldown Reference] > | |-- [POWER Clamp Reference] > | |-- [GND Clamp Reference] > | |-- [TTgnd] > | |-- [TTpower] > | |-- [Pulldown] > | |-- [Pullup] > | |-- [GND Clamp] > | |-- [POWER Clamp] > | |-- [Rgnd] > | |-- [Rpower] > | |-- [Rac] > | |-- [Cac] > | |-- [Ramp] dV/dt_r, dV/dt_f, R_load > | |-- [Rising Waveform] R_fixture, V_fixture, V_fixture_min, > | | V_fixture_max,C_fixture, L_fixture, R_dut, > | | L_dut, C_dut > | |-- [Falling Waveform] R_fixture, V_fixture, V_fixture_min, > | | V_fixture_max,C_fixture, L_fixture, R_dut, > | | L_dut, C_dut > | > |-- [Model] > | > | > |-- [Component] > | > | > |-- [Define Package Model] > | ---------------------- > | |-- [Manufacturer] > | |-- [OEM] > | |-- [Description] > | |-- [Number of Sections] > | |-- [Number of Pins] > | |-- [Pin Numbers] Len, L, C, R, Fork, Endfork > | |-- [Model Data] > | | ------------ > | | |-- [Resistance Matrix] Banded_matrix, Sparse_matrix, > | | | ------------------- Full_matrix > | | | |-- [Bandwidth] > | | | |-- [Row] > | | | |-- [Row] > | | | | ｜ > | | |-- [Inductance Matrix] Banded_matrix, Sparse_matrix, > | | | ------------------- Full_matrix > | | | |-- [Bandwidth] > | | | |-- [Row] > | | | |-- [Row] > | | | | ｜ > | | |-- [Capacitance Matrix] Banded_matrix, Sparse_matrix, > | | | -------------------- Full_matrix > | | | |-- [Bandwidth] > | | | |-- [Row] > | | | |-- [Row] > | | | | ｜ > | | |-- [End Model Data] > | |-- [End Package Model] > | > |-- [Define Package Model] > | > |-- [End] > SHORTEST TYPE > .ibs FILE > --------- > |-- File date section > | ----------------- > | |-- [IBIS Ver], [Comment char], [File name], [File Rev], [Date] > | |-- [Source], [Notes], [Disclaimer], [Copyright] > | > |-- [Component] > | ----------- > | |-- [Manufacturer], [Package], [Pin], [Package Model], [Pin Mapping] > | |-- [Diff Pin], [Model Selector] > | > | > |-- [Component] > | > |-- [Model] > | ------- > | |-- [Model Spec], [Driver Schedule], [Temperature Range], > | |-- [Voltage Range], [Pullup Reference], [Pulldown Reference], > | |-- [POWER Clamp Reference], [GND Clamp Reference], [TTgnd], > | |-- [TTpower], [Pulldown], [Pullup], [GND Clamp], [POWER Clamp], > | |-- [Rgnd], [Rpower], [Rac], [Cac], [Ramp], [Rising Waveform], > | |-- [Falling Waveform] > | > |-- [Model] > | > | > |-- [Component] > | > | > |-- [Define Package Model] > | ---------------------- > | |-- [Manufacturer], [OEM], [Description], [Number of Sections] > | |-- [Number of Pins], [Pin Numbers] > | |-- [Model Data] > | | ------------ > | | |-- [Resistance Matrix] > | | | ------------------- > | | | |-- [Bandwidth], [Row], [Row],--- > | | | > | | |-- [Inductance Matrix] > | | | ------------------- > | | | |-- [Bandwidth], [Row], [Row],--- > | | | > | | |-- [Capacitance Matrix] > | | | -------------------- > | | | |-- [Bandwidth], [Row], [Row],--- > | | | > | | |-- [End Model Data] > | | > | |-- [End Package Model] > | > |-- [Define Package Model] > | > |-- [End] > Best Regards, > Atsushi Ogawa > Manager > Memory Engineering Department > Semiconductor Solution Engineering Division > NEC Corporation > e-mail FYT46205@pcvan.or.jp > P.S., I'd like to report new notice of the draft. > In the [Model selector] illustration, two different buffers use > an equal name "ABCD0123456789ABCDE3". > I think that the illustration as follows is easier to understand. > (Above problem is corrected.) > | > [Model selector] Progbuffer1 |"Progbuffer1"is model_selector_name > | model_name Description > ABCD0123456789ABCDE0 2 mA buffer without slew rate control > ABCD0123456789ABCDE1 4 mA buffer without slew rate control > ABCD0123456789ABCDE2 6 mA buffer without slew rate control > ABCD0123456789ABCDE3 4 mA buffer with slew rate control > ABCD0123456789ABCDE4 6 mA buffer with slew rate control > | > [Model selector] Progbuffer2 > | model_name Description > ABCD0123456789ABCDE0 2 mA buffer without slew rate control > ABCD0123456789ABCDE2 6 mA buffer without slew rate control > ABCD0123456789ABCDE4 6 mA buffer with slew rate control > ABCD0123456789ABCDE5 8 mA buffer with slew rate control > ABCD0123456789ABCDE6 10 mA buffer with slew rate control > ****************************************************************************** From owner-ibis Thu May 8 13:54:35 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA27810 for ; Thu, 8 May 1997 13:54:33 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 8 May 97 13:53 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 8 May 97 13:53 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 8 May 97 13:53 PDT Message-Id: Date: Thu, 8 May 97 13:53 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD41.1 Switch Model To IBIS Committee: One of the interesting problems associated with BIRD41.1 is the modeling of MOSFET series switches. I believe a behavioral model exists which can be extracted from measurements or Spice models. Below is an HSPICE Netlist for testing some ideas. Although I used a generic NMOS transistor, the setup and performance was based originally on the Texas Instruments 74CBT3383 Spice model without any package elements. Input and output capacitances are put into the models to mimic the performance, but these can be removed. The intent is to compare performance of the NMOS model (nodes 1 and 3) and the Behavioral model (nodes 11 and 13) for a given set of test loads including open transmission lines and for various pulse amplitudes. The main idea tested here is whether a series model can be derived from IV characteristics of a device. The models below are based on a turned on device with Vgate = 5 V. The IV tables are Ids through the device as a function of Vs, with Vds = (.5V, 1V and 2V). A "linear" model is based ONLY on the 1 V table and assumes a linear functional relationship between Ids and Vds. This is really an APPROXIMATION. Two other tests are developed taking TWO of the three tables. One test "G5" uses the 0.5 V and 1.0 V tables. The other test "G1" uses the 1.0 V and 2.0 V tables. The data from two tables is used to fit a second order function - as a better APPROXIMATION. In the region of interest, the Ids/Vds relationship follows a square law relationship, according to simple theory. Some additional code is put in so that the behavioral function works in BOTH directions - so the minimum of the S and D nodes are consider the Source for the purpose of table extraction, and the direction of current flow is defined by the polarity of Vds. The tables are very rough and could use more points. Even so, the reults show good comparison. Best Regards, Bob Ross Interconnectix * TEST CASE FOR SERIES SWITCH MOS MODEL USING NMOSFET ONLY * 1 3 * | | * ____________ * o---/¥/¥/¥---o o-----O____________)---o Open * 10 ohms |___| TD = 0.5 nS * | Z0 = 50 ohms * Vcc * Vh /----¥ * / ¥ * 0 --/ ¥----- 0.1ns Rise and Fall * * * * MODEL: Ids = K1 * Vds + K2 * Vds * Vds * = (K1 + K2 * Vds) * Vds * * Implemented as: Ids = (K1 + K2 * ABS(Vds)) * Vds * * Vds = Vd - Vs is used to change the sign of the current * if Vs > Vd * * Is * D ---> S * 11 o---o--/¥/¥/¥--o---o 13 * _|_ _|_ * C11 ___ ___ C13 * | | * GND GND * * * *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 0.5 V * .SUBCKT SER5 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 1.469e-01 + 1.0000e+00 1.191e-01 + 2.0000e+00 8.252e-02 + 3.0000e+00 2.843e-02 + 4.0000e+00 4.394e-11 + 5.0000e+00 0.0 .ENDS * *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 1 V * .SUBCKT SER1 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 2.579e-01 + 1.0000e+00 2.030e-01 + 2.0000e+00 1.298e-01 + 3.0000e+00 3.119e-02 + 4.0000e+00 5.272e-11 + 5.0000e+00 0.0 .ENDS * *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 2 V * .SUBCKT SER2 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 3.943e-01 + 1.0000e+00 2.866e-01 + 2.0000e+00 1.516e-01 + 3.0000e+00 3.534e-02 + 4.0000e+00 6.929e-11 + 5.0000e+00 0.0 .ENDS *-------------------------------------------------------------------------- * POWER AND GND V100 100 0 0 V199 199 100 5 *************************************************************************** * MOSFET FOR 1-3 CONNECTION USED FOR REF. V95 5 100 5 MOS 1 5 3 100 NMOSFET W=1440U L=0.64U C1 1 100 6P C3 3 100 6P .OPTIONS TNOM=40.00 .MODEL NMOSFET NMOS LEVEL=3 * SOURCE AND LOAD R1 91 1 10 * R3 3 100 50G TL 3 100 9 100 Z0=50 TD=.5N R9 9 100 1G *************************************************************************** * TABLE DRIVEN MODEL SIMULATION WITH 11-13 CONNECTION * DRAIN TO SOURCE VOLTAGE (SIGN CONTROLS CURRENT FLOW DIRECTION) EDS 34 100 VOLT='V(11)-V(13)' RDS 34 100 1G EABS 33 100 VOLT='ABS(V(11)-V(13))' RABS 33 100 1G * SELECT G5, G1, OR GLIN: * * Id = (K1 + K2 * Vds) * Vds * Using Vds = .05 V and 1 V Tables: * * K1 = 4 * I5(Vs) - I1(Vs) * K2 = 2 * I1(Vs) - 4 * I5(Vs) * G5 11 13 CUR='V(34)*(I(V5)*4-I(V1)+(2*I(V1)-4*I(V5))*V(33))' * Using Vds = 1 V and 2 V Tables: * * K1 = 2 * I1(Vs) - I2(Vs) / 2 * K2 = I2(Vs) / 2 - I1(Vs) * * G1 11 13 CUR='V(34)*(I(V1)*2-I(V2)/2+(I(V2)/2-I(V1))*V(33))' * Using Vds = 1 V and Linear Approximation * * K1 = I1(Vs) * K2 = 0 * * GLIN 11 13 CUR='V(34)*I(V1)' * MIN OF SOURCE OR DRAIN BECOMES "Vs" EMIN 38 100 VOLT='MIN(V(11), V(13))' * I1(Vs) X1 38 100 35 SER1 V1 100 35 0 * I2(Vs) X2 38 100 36 SER2 V2 100 36 0 * I5(Vs) X5 38 100 37 SER5 V5 100 37 0 * INPUT AND OUTPUT CAPACITANCE WHICH MATCHES SPICE MODEL C13 13 100 6P C11 11 100 6P * MODEL SOURCE AND LOAD R11 91 11 10 * R13 13 100 50G TL1 13 100 19 100 Z0=50 TD=.5N R19 19 100 1G *************************************************************************** * INPUT PULSE VIN 91 100 PULSE 0 3 0 .1N .1N 2N 4N .TEMP 50. .TRAN .1N 4N .PRINT TRAN V(3) V(13) .OPTIONS POST INGOLD=2 .END From owner-ibis Thu May 8 20:21:07 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id UAA04308 for ; Thu, 8 May 1997 20:21:07 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id UAA26088 for ; Thu, 8 May 1997 20:20:23 -0700 (PDT) X-Authentication-Warning: mailgate.cadence.com: smap set sender to using -f Received: from nakul.cadence.com(158.140.126.64) by mailgate.cadence.com via smap (V1.0mjr) id sma863148020.026079; Thu May 8 20:20:21 1997 Received: (from presi@localhost) by nakul.cadence.com (8.6.8/8.6.8) id IAA12638 for ibis@vhdl.org; Fri, 9 May 1997 08:46:04 +0531 Date: Fri, 9 May 1997 08:46:04 +0531 From: R Sanjeev Message-Id: <199705090315.IAA12638@nakul.cadence.com> To: ibis@vhdl.org X-Sun-Charset: US-ASCII Hello, The specs says that in case of ECL (VCC +ive voltage supply and VEE -ve voltage supply ) both the pullup and the pulldown are made with reference to VCC and we require to use: Vtable = VCC - Vout. in BOTH cases. This makes sense as in case of a differential pair the same stage will do the pullup and the pulldown. So from my understanding of the specs the Voltage values of the Pullup/Pulldown tables in case of Output_ECL should be the same.eg VCC = 0V and if I simulated Vout for 0 to -2.2V in both cases. The Table should look like: 2.2 x x x 2.1 x x x . . . 0.0 x x x Is this correct? I'm unable to cross check with s2ibis as s2ibis2.1 does not seem to be able to handle Output_ECL when it comes to the [Pulldown] it has put some wierd values. In case of pullup the voltage in the *spi files have been varied from VCC to VCC-2.2 volts and the output in Vtable also followes VCC-Vout. ( And also filled the ibis file with lines of 0.0 0.0 0.0 0.0 after that) The [Pulldown] has been simulated from VCC to VCC-2.2 volts but these values have not been used to fill the table. Voltage column is filled with 0 and -0.1 in the Voltage column. Could someone please comment on this too.(maybe Alan Glaser if he is free) Thanx in advance, regards, presi From owner-ibis Fri May 9 06:36:52 1997 Received: from usr.com (mailgate.usr.com [149.112.20.2]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA13669 for ; Fri, 9 May 1997 06:36:51 -0700 (PDT) From: mohali@usr.com Received: from robogate2.usr.com by usr.com (8.7.5/3.1.090690-US Robotics) id IAA22662; Fri, 9 May 1997 08:27:15 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 3732B100; Fri, 9 May 97 08:48:00 -0500 Mime-Version: 1.0 Date: Thu, 8 May 1997 08:30:58 -0500 Message-ID: <3732B100.3000@usr.com> Subject: subscribe To: ibis@vhdl.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part subscribe From owner-ibis Fri May 9 08:03:06 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA15000 for ; Fri, 9 May 1997 08:03:06 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA00463 for ; Fri, 9 May 1997 08:02:09 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA04988; Fri, 9 May 1997 08:02:23 -0700 (PDT) Message-Id: <199705091502.IAA04988@ichips.intel.com> To: ibis@vhdl.org Subject: Passcode for todays meeting Date: Fri, 09 May 1997 08:02:22 -0700 From: Stephen Peters Hi All: The passcode for todays meeting is incorrect -- try 8111263 (There is one to many '1's in the original) regards, Stephen From owner-ibis Fri May 9 08:28:39 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA15280 for ; Fri, 9 May 1997 08:28:38 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA05486 for ; Fri, 9 May 1997 08:27:42 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA07036; Fri, 9 May 1997 08:27:55 -0700 (PDT) Message-Id: <199705091527.IAA07036@ichips.intel.com> To: ibis@vhdl.org Subject: Pullup ECL tables Date: Fri, 09 May 1997 08:27:55 -0700 From: Stephen Peters Hello Presi: I can't speak to the s2ibis2 question, but the table you show in your example below is correct. Be sure that you include the [Pullup Reference] keyword in ibis file, and set the pullup reference to zero volts. Regards, Stephen Peters Intel Corp. Hello, The specs says that in case of ECL (VCC +ive voltage supply and VEE -ve voltage supply ) both the pullup and the pulldown are made with reference to VCC and we require to use: Vtable = VCC - Vout. in BOTH cases. This makes sense as in case of a differential pair the same stage will do the pullup and the pulldown. So from my understanding of the specs the Voltage values of the Pullup/Pulldown tables in case of Output_ECL should be the same.eg VCC = 0V and if I simulated Vout for 0 to -2.2V in both cases. The Table should look like: 2.2 x x x 2.1 x x x . . . 0.0 x x x Is this correct? I'm unable to cross check with s2ibis as s2ibis2.1 does not seem to be able to handle Output_ECL when it comes to the [Pulldown] it has put some wierd values. In case of pullup the voltage in the *spi files have been varied from VCC to VCC-2.2 volts and the output in Vtable also followes VCC-Vout. ( And also filled the ibis file with lines of 0.0 0.0 0.0 0.0 after that) The [Pulldown] has been simulated from VCC to VCC-2.2 volts but these values have not been used to fill the table. Voltage column is filled with 0 and -0.1 in the Voltage column. Could someone please comment on this too.(maybe Alan Glaser if he is free) Thanx in advance, regards, presi From owner-ibis Tue May 13 11:15:25 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA00170 for ; Tue, 13 May 1997 11:15:22 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Tue, 13 May 97 11:14 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Tue, 13 May 97 11:14 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Tue, 13 May 97 11:14 PDT Message-Id: Date: Tue, 13 May 97 11:14 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINTUTES 5/9/97 DATE: May 13, 1997 SUBJECT: 5/9/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology Dileep Divekar*, Norio Matsui, Raj Raghuram Cadence Design C. Kumar*, Don Telian Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu* Hewlett Packard, EEsof Karl Kachigan, Henry Wu High Design Technology (Razvan Ene) HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier Intel Corporation Stephen Peters*, Arpad Muranyi, Henry Maramis* Interconnectix Bob Ross* Mitsubushi Tam Cao Motorola Ahmed Omer National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, Peter Laflamme, Kevin Smith NCR Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto) Quad Design/Viewlogic Jon Powell, Chris Rokusek* Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. (Celso Faia) VeriBest Ian Dodd, William Bell VLSI Technology Harish Patel, D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1997: 3M Fran Hart Actel Scott Schlachter Acuson & Free Model Foundation Richard Munden Alcatel John Fitzpatrick Ansoft Eric Bogatin Apteq Design Systems Dan FitzPatrick Compaq Weston Beal EIA Patti Rusher* EMC Fabrizio Zanella Micron Technology Brian Johnson Molex Gus Panella North Carolina State U. (Michael Steer) S3, Inc. Porsh Shih, Sarathy Sribhashyam Ultratest International Charles Im Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 5/30/97 (916) 356-9200 1-137662 1259125 6/12/97 FACE-TO-FACE at Anaheim, CA - No Telephone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Henry Maramis from Intel called in for Arpad Muranyi. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher estimated about $12,000, up from the previously reported figure of $10,129 in the EIA/IBIS account based on High Design Technology joining and purchasing the Golden Parser. Patti will have the current information available by the next meeting. She plans to check with accounting to find out who still owes money. This concerns only four members. They will be sent new invoices to be paid by the June meeting to avoid being dropped from EIA/IBIS membership. REVIEW OF MINUTES AND AR'S No corrections. Bob Ross stated that the AR's to issue BIRDs were still pending. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Patti Rusher reported that Dr. Howard Johnson of "Black Magic" fame wrote an article, "The I/O Buffer Information Specification (IBIS), A Standard for Chip/Receiver Modeling" in Printed Circuit Design, May 1997, pp. 17-20. Bob Ross mentioned that the main concern was lack of IBIS models, and he responded privately that commercial vendors were now providing many IBIS models. Patti also mentioned that the issue included several articles concerning EDIF 4 0 0 and also a useful article concerning the national/international standards body organizational structures. This PCB issue is usually available at the Design Automation Conference. Syed Huq mentioned that he will present a paper "Understanding and Using IBIS Models for Signal Integrity Analysis" at the High-Level Electronic System Design Conference (HESDC97) in October in Santa Clara, California. Syed reported on Web page updates: a new Interconnectix logo and the High Design Technology addition to the roster. NEW MODELS AVAILABLE, LIBRARY UPDATE None. OPENS FOR NEW ISSUES Stephen Peters for job posting policy on the IBIS reflectors. C. Kumar on a new technical proposal for SSO. JOB POSTING ON THE IBIS REFLECTORS Stephen Peters raised the question regarding a policy concerning positing jobs on the IBIS reflectors. This was based on a recent posting on many reflectors. Patti Rusher indicated that standards body reflectors are used for company supported standards related business and are not to be used for recruitment. Bob Ross indicated that this shall be the policy for the IBIS reflectors. The SI reflector could be used for brief, informational job postings directly by the organization (not by recruiting companies) according to the SI reflector policy because this is a private, non-standards based reflector. Bob will add a statement at the end of the Minutes stating job posting messages are not permitted. However, unless we go to moderated refectors, we cannot prevent any such posting. DESIGN AUTOMATION CONFERENCE (DAC) 1997 IBIS MEETING PLANNING Patti Rusher reported that she has scheduled a meeting room for the EIA/IBIS Summit meeting on Thursday, June 12, 1997 in Anaheim, California at the Marriott Hotel next door to the Convention Center. She plans for 25 people. A continental breakfast will be available, and the room is scheduled from 9 AM to 5 PM for the meeting. She will provide an overhead projector and chart board. Bob suggested that lunch also be provided. Bob asked for a telephone so that people could call in for the business segment, but Patti stated that the cost was very high - in excess of $500. So we decided not to have teleconferencing available for this meeting. Syed Huq is still seeking presentations for the IBIS DAC meeting. Saburo Hohjo from Hitachi will report on the EIAJ I/O Interface Model status. He is one of the authors. Syed would like the final agenda firmed up by May 30. AR - Presenters send to Syed Huq presentation topics and time estimates for presentation topics at the IBIS Summit meeting. Patti offered local copy service for presentations. Electronic copies will be put on vhdl.org. Otherwise, bring copies for distribution. Activities will also include election of EIA/IBIS officers for 1997-1998 and discussions leading to the approval of the final BIRDs and to the ratification of Version 3.0. VERSION 3.0 RATIFICATION Bob Ross asked what should be accomplished at the IBIS Summit meeting regarding ratification of Version 3.0. Enough BIRDs have been approved to issue a new Version. However, Bob felt it would be nice to include the Series Switch functionality. In any case, the Version 3.0 available at the June 12 meeting will not have gone through a good editorial review. The sense of the Committee was to put it forward for a vote, even in its rough stage to endorse the new functions. This would allow moving forward with contracting parser development and also to do an editorial cleanup as part of the Version 3.1 release. The parser development process itself leads to editorial changes to resolve ambiguity. Other sources including reflector comments and "IBIS Tree" contributions from Atsushi Ogawa of NEC in Japan are providing valuable input and motivation for a cleanup and perhaps organizational revision for clarity. The standard is becoming quite large. Many of us who have been participating in its development from Version 1.1 are able to track the additions, but someone unfamiliar with IBIS will find that IBIS Version 3.0 contains an intimidating amount of information. Patti Rusher suggested hiring a documentation person to help re-write IBIS. This suggestion will be considered. The conclusion of this discussion is that the Committee is willing to proceed with ratifying IBIS Version 3.0 in its rough stage and defer the detailed editorial review and revisions to IBIS Version 3.1. INTERNATIONAL PROGRESS Patti Rusher reported no further progress on IBIS Version 2.1 international ratification, but that the USTAG group had considered combining IBIS with another proposal in response to a concern that the IBIS scope was too narrow. Patti expects IBIS to move forward, without change, based on its existing wide-spread usage. Patti will be meeting with the USTAG group and will give us a report at the next EIA/IBIS meeting. Bob Ross reported that the EIAJ I/O Interface Modeling subgroup has formed three internal subgroups to address comments, to provide examples and demonstrations, and to provide information on activities. Several EIAJ members needed more time to determine their internal corporate support of the EIAJ proposal. IBIS COOKBOOK PROGRESS Stephen Peters reported only slight progress. FAQ UPDATE Syed Huq has updated the FAQs by removing modem references, providing updated parser and librarian information. He has also added a s2ibis FAQ section taken from the original s2ibis for Version 1.1 document. S2IBIS2 ISSUES AND NT Bob Ross reported continued s2ibis2 questions and comments. He has provided information to NCSU for a possible fix. He also plans to post an interim fix to the resolution problem to change the printout to 4 decimal digits to overcome the resolution problem so that s2ibis2 can be used. BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Bob Ross reported that he sent out a netlist to test an approach to model series switches. John Fitzpatrick has been too busy or on vacation to move forward with BIRD41.1. In response to a question by Stephen Peters, Bob expected BIRD41.1 to still cover discrete and diode models and also series MOSFET switches. There is still some possibility of a combined syntax for series diode tables and series switches. Also covered is a logic table for stating the allowable combinations of "on" and "off" states of a component. Bob plans to see that BIRD41.2 is issued next week to capture the progress made so far. CONNECTOR MODELING Stephen Peters reported no further work. The correlation with matrix format still needs to be done, but no one has time. Bob Ross felt that this proposal may not be part of IBIS Version 3.0. He may still be willing to publish an existing implementation in BIRD format. There already exists vendor specific implementations on how to use the data that is provided. It would take a lot of time and effort to come to a common agreement. MODELING EARLY CLAMPS IN IBIS No report. CURRENT VERSUS TIME TABLE (IT) C. Kumar described a proposal where the currents at the ground and power nodes would also be tabulated for the associated VT table tabulations to give better predictions for ground and power bounce. These currents are easily available from Spice deck extractions (and also from measurements). Kumar stressed that the voltage needed was at the buffer itself. Bob Ross questioned whether one or two tables was needed, since the fixture load already defines the output current. Kumar will work with Bob to organize a proposal. NEXT MEETING: The next meeting is on Friday, May 30, 1997, 8:00 A.M. to 9:55 A.M. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design/Viewlogic 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Wed May 14 12:12:22 1997 Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA22420 for ; Wed, 14 May 1997 12:12:21 -0700 (PDT) Received: from ee.umr.edu (ee.umr.edu [131.151.100.20]) via SMTP by hermes.cc.umr.edu (8.8.5/R.4.20) id OAA27132; Wed, 14 May 1997 14:10:57 -0500 (CDT) Received: by ee.umr.edu (SMI-8.6/SMI-SVR4-kaw-30-jun-94) id OAA06624; Wed, 14 May 1997 14:10:53 -0500 From: ali@ee.umr.edu (Mohammad Ali) Message-Id: <199705141910.OAA06624@ee.umr.edu> Subject: unsubscribe... To: ibis@vhdl.org Date: Wed, 14 May 1997 14:10:47 -0500 (CDT) Cc: mohali@usr.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit please unsubscribe From owner-ibis Wed May 14 18:13:47 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA28908 for ; Wed, 14 May 1997 18:13:39 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Wed, 14 May 97 18:12 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 14 May 97 18:12 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 14 May 97 18:12 PDT Message-Id: Date: Wed, 14 May 97 18:12 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.2 Modelling Series Switchable Devices Cc: john.fitzpatrick@ln.cit.alcatel.fr John Fitzpatrick and IBIS Committee: I have taken BIRD41.1 and a number of comments documented in the IBIS meeting minutes of 4/18/97 and 5/9/97 along with a Spice simulation example that was distributed to produce BIRD41.2. BIRD41.2 adds some details to the discussion and takes out some of the details in other areas. It new keywords under [Model]s for: Discrete Series Elements: Series R, L, C combinations: [R_series], [L_series], [R_l_series], [C_series], [L_c_series], {R_c_series] Series IV tables: Series Diodes, etc.: [Series Current] Series MOSFET Models Series MOSFET switches: [Series MOSFET} Each of these devices can be classified according to Model_type as: Series: Fixed Series Elements Series_switch: Series Elements with 'On' and 'Off' states that contain series electrical descriptions for both states under the keywords" [On] [Off] The series connections and logic need to be described for the [Component] set of pins by: Series Function Table: Describes the allowable combinations of groups of switches that have synchronized switching: [Series Function Table] Series Pin Mapping: Describes the pin connectivity and series model and function table group association of switches whose switching is synchronized: [Series Pin Mapping] This document is issued for the purpose of raising questions and generating discussion on the reflector and at the next IBIS meeting. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.2 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: Feb. 12, 1997, Feb. 17, 1997, May 14, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Pin Table] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type values are allowed under the [Model] keyword: Series, Series_Switch Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Pin Table] | Required: No | Description: Used to define allowable switching combinations of series | switches described in the [Series Pin Table]. | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the Function Table Group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Pin Table] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 On 1 2 4 On 1 3 4 On 2 3 4 | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Usage Rules: Entries follow these rules: Only series pin pairs | are entered. The Pin 1 column contains the pin number for | which input impedances are measured. The Pin 2 column contains | the pin name of the other end of the series device. The | Model_name column names of the model corresponding to the | Series or Series_switch device. | | The Function Table Group column contains an alphanumeric | designator string to associate those sets of Series_switch | pins which are switched together. One possible application | is to model crossbar switches where the straight through | On switches are indicated by one designator and the cross over | paths are indicated by another designator. If the model | referenced is a Series model, then the Function Table | Group entry is required, but ignored. | | Column length limits are: | Pin 1 5 characters max | Pin 2 5 characters max | Model_name 20 characters max | Function Table Group 20 characters max | | Other Notes: If the Model_name is for a non-symmetrical series device, | then the order of the pins is important. Pin 1 and Pin 2 | must be consistent with the referenced model. | |------------------------------------------------------------------------------ [Series Pin Mapping] | Pin 1 Pin 2 Model_name Function Table Group | 2 3 CBTSeries 1 | Four Independent Groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight Through Path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross Over Path 25 23 CBTSeries 6 Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [Rseries], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The | three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioural model | from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioural model | from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings itself provide the assumed gate | voltages. If the [POWER Clamp Reference] exists, it overrides | the [Voltage Range] value. The table entries are actually | the Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be view as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) that is used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | The model data is used to approximate the On state relationship | between Ids, Vds for a given Vgs: Ids = f(Vds) for a given Vgs. | This relationship is used as a series element to solve for the | voltages on each side of the switch during analysis. | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be Ids = (Itable) * Vds / Vgs. In practice, the Ids | value will be less than the the value predicted when Vds > Vgs. | | If two [Series MOSFET] tables are supplied, a quadratic | approximation can be used: | | Ids = k1 * Vds + k2 * Vds * Vds, for Vds < -k1 /2 * K2, | | and the maximum Ids value | | Ids = -k1 * k1 / k2, for Vds => -k1 / 2 * k2. | | The values of k1 and k2 are derived for current value of Vs | by solving the equations given the two Ids values for the two | Vds subparameter values. | | If more than two [Series MOSFET] tables are supplied, the | analysis is simulator dependent. A simulator may still use | only the first two tables or may use some interpolation and | extrapolation algorithm to predict Ids. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 0.5 | Voltage I(typ) I(min) I(max) | 5.0V 146.9m 87.4m 226.4m | Defines the Ids current as a 4.0V 119.1m 70.0m 185.3m | function of Vgs, for Vds = 0.5 3.0V 82.5m 47.7m 130.1m 2.0V 28.4m 15.2m 46.4m | Normally, more data points would 1.0V 43.9p 37.1p 47.8p | be provide than shown here 0.0V 0.0p 0.0p 0.0p | [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | +-------+ | + | Fixed | - | +------| Vds |-------+ | | +-------+ | | | Ids = Table Current | | | ---> | | +---<---| |--->----+-----+ | d |_____| - s | + | --+-- Vgs +---+---+ | | g + | Sweep | | | Vs | | +---+---+ | | - | GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Pin Table] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 42.1 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes From owner-ibis Thu May 15 02:13:26 1997 Received: from alcatel.fr (ns.alcatel.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id CAA05948 for ; Thu, 15 May 1997 02:13:23 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.8.5/8.8.5) with ESMTP id LAA18747; Thu, 15 May 1997 11:12:44 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id LAA06736; Thu, 15 May 1997 11:12:32 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA03369; Thu, 15 May 97 11:11:43 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01239; Thu, 15 May 97 11:11:30 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <337AD341.41C67EA6@ln.cit.alcatel.fr> Date: Thu, 15 May 1997 11:11:29 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Bob Ross Cc: ibis@vhdl.org Subject: Re: IBIS BIRD41.2 Modelling Series Switchable Devices References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Excellent work! The new Bird seems to cover all important issues, especially how to model those infamous FET switches. I'm not competent enough to give detailed comment on your HSpice model: just happy that the model is derived from simple tables. (Bench measurements of a FET device will be trickier than for simple I/V measurements with a fixed load, but I can live with that). I hope that, before voting tales place, at least one other simulator company will confirm to the reflector that they will use this model. Comments on some minor points are included below. Once again, thanks agin for pushing though this Bird. All the best, John _________________________________________________________________ Comments: 1) Voltage ranges | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER Ok for [Series Current]. This is exactly as for [GND Clamp], with the same problems of excessively large current values. (Would it be useful in IBIS 3 to introduce the notion of a maximum current, possibly set by the model creator?) However, for [Series MOSFET], the limits should be from GND-POWER to POWER+POWER. The upper range is important, because a series MOSFET is often used to clip signals e.g. in 5V to 3.3V conversion. 2) Parallel elements The Bird does not explain how to treat parallel elements e.g. C_comp, GND and POWER clamps, RC terminations. In fact, it would appear to disallow the combination of series and parallel elements (with the exception of C_comp?). I think that parallel elements should be allowed, and be defined to exist at Pin 1: -+- POWER | +-+-+ | | clamp or RC termination | | | | +-+-+ Pin 1 | +-----------+ Pin 2 ------+---------------+--+ Series +--------- +-+-+ | +-----------+ | | Clamp or | | | RC term- --+-- | | ination --+-- C_comp +-+-+ | | | -+- GND -+- GND Aside: I think it would be complicated to allow parallel elements on both sides of the series element. There would be however one potential application for this: the simple connector model we all use: +--------+ ------+--+ L, R +-----+------- | +--------+ | | | --+-- --+-- --+-- C --+-- | | | | -+- GND -+- GND 3) Function table Two names are used for the function table: [Series Function Table] and [Series Pin Table] I think the first name is the better, but because the defined states are ON or OFF, the name should include the word "switch" e.g. [Series Switch Groups] 4) RLC model In the example, it is clear that, if not defined, R_c_series, L_c_series and R_l_series are short-circuits. Perhaps this should also be explained in the text? 5) [On] and [Off] State that keywords common to both [On] and [Off] should appear before the keywords [On] and [Off]. Example: If a switch has a constant [C_series] part, must it appear twice (after each of the [On] and [Off] keywords) or once (before the [On] and [Off] keywords)? -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Thu May 15 18:06:46 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA20489 for ; Thu, 15 May 1997 18:06:44 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 15 May 97 18:05 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 15 May 97 18:05 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 15 May 97 18:05 PDT Message-Id: Date: Thu, 15 May 97 18:05 PDT From: bob@icx.com ( Bob Ross) To: John.Fitzpatrick@ln.cit.alcatel.fr Subject: Re: IBIS BIRD41.2 Modelling Series Switchable Devices Cc: ibis@vhdl.org John: Thank you for reviewing BIRD41.2. As a consequence of your comments, I am issuing BIRD41.3 seperately. Some detailed feedback is embedded in your comments. To summarize here: 1. I plan to keep the voltages ranges as defined. It is expected that extrapolation of data will be done when physical (or even simulation) current limits are reached. There is some justification for keeping the [Series MOSFET] as defined - given below. 2. The intent was to allow any of the defined parallel elements through the existing [Pin] keyword model allocation. It is necessary to allow defining INDEPENDENTLY parallel elements on EACH side of a series device. [Series MOSFET] switches have capacitance on each side and may have Schottky diodes on each side. A note will be made in the [Series Pin Mapping] keyword rules. 3. I have changed the [Series Pin Table] (and [Series Function Table]) keywords to [Series Switch Groups] as you suggested. 4. I have added clarification concerning certain series resitive and inductive elements are considered shorted, if not entered. 5. You made a suggestion regarding Series_switch models having a provision for common keywords such as [C_series] positioned above the [On] and [Off] keywords. I disagree and believe this should be flagged as an error. I would rather force the keyword to be repeated. That avoids the confusion of, for example, [C_series] appearing both above [On] and below [On]. A whole set of rules which no-one would remember would have to be developed as to which prevails, or how they are added, etc. In addition, I have added statements that C_comp is ignored for the Series models. C_comp is documented as a capacitance two ground, I prefer not to introduce a dual meaning. Best Regards, Bob Ross Interconnectix > Date: Thu, 15 May 1997 11:11:29 +0200 > From: John V Fitzpatrick > Organization: Alcatel Telecom, Lannion, France > To: Bob Ross > Cc: ibis@vhdl.org > Subject: Re: IBIS BIRD41.2 Modelling Series Switchable Devices > Bob, > Excellent work! The new Bird seems to cover all important issues, > especially how to model those infamous FET switches. > I'm not competent enough to give detailed comment on your > HSpice model: just happy that the model is derived from simple > tables. (Bench measurements of a FET device will be trickier > than for simple I/V measurements with a fixed load, but I can live > with that). > I hope that, before voting tales place, at least one other > simulator company will confirm to the reflector that they will > use this model. > Comments on some minor points are included below. > Once again, thanks agin for pushing though this Bird. > All the best, > John > _________________________________________________________________ > Comments: > 1) Voltage ranges > | [Series Current] GND - POWER GND + POWER > | [Series MOSFET] GND GND + POWER > Ok for [Series Current]. This is exactly as for [GND Clamp], with > the same problems of excessively large current values. > (Would it be useful in IBIS 3 to introduce the notion of a maximum > current, possibly set by the model creator?) Good idea. However, I believe that if data is not measurable or simulated, it still can be extrapolated. So I have not added any current limit statement at this time. > However, for [Series MOSFET], the limits should be from > GND-POWER to POWER+POWER. The upper range is important, > because a series MOSFET is often used to clip signals > e.g. in 5V to 3.3V conversion. For On state Series MOSFET models, when the source voltage (Vs) reaches the POWER rail, the switch is in a very high impedance state. Extending the table beyond the POWER rail will not significantly increase the accuracy. The drain side actually extends beyond the POWER real by a large amount because the table is not used directly. It is used to generate an equation relating any Vds value to any Ids. So the table is used to generate data that really goes further than POWER. Regarding the GND limit, the Series MOSFET switch is in the lowest impedance state. There may be cases where undershoots may exist on both sides of the switch. Even if the equation for Vds and Ids is not based on extrapolated data, the accuracy will still be very good at the low state. These limits represent minimum range limits. Based on specific situations, the model supplier is allowed to provide data beyond the limits. One practical issue, however, is that some of the clamping actions may prevent getting good data beyond the limits. > 2) Parallel elements > The Bird does not explain how to treat parallel elements e.g. > C_comp, GND and POWER clamps, RC terminations. In fact, it would > appear to disallow the combination of series and parallel elements > (with the exception of C_comp?). > I think that parallel elements should be allowed, and be defined > to exist at Pin 1: > -+- POWER > | > +-+-+ > | | clamp or RC termination > | | > | | > +-+-+ > Pin 1 | +-----------+ Pin 2 > ------+---------------+--+ Series +--------- > +-+-+ | +-----------+ > | | Clamp or | > | | RC term- --+-- > | | ination --+-- C_comp > +-+-+ | > | | > -+- GND -+- GND > > Aside: > I think it would be complicated to allow parallel elements on > both sides of the series element. There would be however one > potential application for this: the simple connector model we > all use: > +--------+ > ------+--+ L, R +-----+------- > | +--------+ | > | | > --+-- --+-- > --+-- C --+-- > | | > | | > -+- GND -+- GND > The intention is to allow all of the parallel elements you suggest, an more to be assigned on EACH pin using the existing [Pin] keyword list of pins simutaneouly with the [Series Pin Mapping] keyword. This represents a real situation associated with [Series MOSFET] devices with capacitances on both pins and also clamps on both pins. A note is made in the [Series Pin Mapping] keyword t state this. > 3) Function table > Two names are used for the function table: > [Series Function Table] and [Series Pin Table] > I think the first name is the better, but because the defined > states are ON or OFF, the name should include the word "switch" > e.g. [Series Switch Groups] I have made the change to [Series Switch Groups] per your suggestion. > 4) RLC model > In the example, it is clear that, if not defined, R_c_series, > L_c_series and R_l_series are short-circuits. Perhaps this should > also be explained in the text? I have added notes, per your suggestion. > 5) [On] and [Off] > > State that keywords common to both [On] and [Off] should > appear before the keywords [On] and [Off]. > Example: > If a switch has a constant [C_series] part, must it appear twice > (after each of the [On] and [Off] keywords) or once (before the > [On] and [Off] keywords)? I disagree with this interpretation and suggestion because it can cause confusion and complication if the same keyword is defined both above and below [On] or [Off]. It is easier to require [On] or [Off] to be first. I have added a statement in the [On], [Off] keyword preventing certain keyword to be above [On] and [Off]. [C_series] will be required twice, if needed, but it can contain different values for the On and Off states. > > > -- > John Fitzpatrick > Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France > Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Thu May 15 18:09:34 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA20505 for ; Thu, 15 May 1997 18:09:26 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 15 May 97 18:08 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 15 May 97 18:08 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 15 May 97 18:08 PDT Message-Id: Date: Thu, 15 May 97 18:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.3 Modelling Series Switchable Devices Cc: john.fitzpatrick@ln.cit.alcatel.fr John Fitzpatrick and IBIS Committee: BIRD41.3 is issued in response to some of John's valuable comments and suggestions. A summary of the changes and reasons are listed in the ANALYSIS PATH/DATA ... section of BIRD41.3 Best Regards, Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.3 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: Feb. 12, 1997, Feb. 17, 1997, May 14, 1997, May 15, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type values are allowed under the [Model] keyword: Series, Series_Switch Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described in the [Series Switch Groups]. | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the Function Table Group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 On 1 2 4 On 1 3 4 On 2 3 4 | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Usage Rules: Entries follow these rules: Only series pin pairs | are entered. The Pin 1 column contains the pin number for | which input impedances are measured. The Pin 2 column contains | the pin name of the other end of the series device. The | Model_name column names of the model corresponding to the | Series or Series_switch device. | | The Function Table Group column contains an alphanumeric | designator string to associate those sets of Series_switch | pins which are switched together. One possible application | is to model crossbar switches where the straight through | On switches are indicated by one designator and the cross over | paths are indicated by another designator. If the model | referenced is a Series model, then the Function Table | Group entry is required, but ignored. | | Column length limits are: | Pin 1 5 characters max | Pin 2 5 characters max | Model_name 20 characters max | Function Table Group 20 characters max | | Other Notes: If the Model_name is for a non-symmetrical series device, | then the order of the pins is important. Pin 1 and Pin 2 | must be consistent with the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any additonal elements such as additonal | capacitance or clamping circuitry are defined by the Model_name | that is referenced in the [Pin] keyword. Thus a Series_switch | model may contain Terminator models on EACH of the pins to | describe both the capacitance on each pin and some clamping | circuitry that may exist on pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] | Pin 1 Pin 2 Model_name Function Table Group | 2 3 CBTSeries 1 | Four Independent Groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight Through Path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross Over Path 25 23 CBTSeries 6 Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R_series], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R_series], [L_series], [R_l_series], | [C_series], [L_c_series], [R_c_series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The | three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | [R_l_series] is 0 ohms if it is not defined in the path. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. [R_c_series] is 0 ohms if it is not | defined in the path. [L_c_series is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings itself provide the assumed gate | voltages. If the [POWER Clamp Reference] exists, it overrides | the [Voltage Range] value. The table entries are actually | the Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be view as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) that is used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | The model data is used to approximate the On state relationship | between Ids, Vds for a given Vgs: Ids = f(Vds) for a given Vgs. | This relationship is used as a series element to solve for the | voltages on each side of the switch during analysis. | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be Ids = (Itable) * Vds / Vgs. In practice, the Ids | value will be less than the the value predicted when Vds > Vgs. | | If two [Series MOSFET] tables are supplied, a quadratic | approximation can be used: | | Ids = k1 * Vds + k2 * Vds * Vds, for Vds < -k1 /2 * K2, | | and the maximum Ids value | | Ids = -k1 * k1 / k2, for Vds => -k1 / 2 * k2. | | The values of k1 and k2 are derived for current value of Vs | by solving the equations given the two Ids values for the two | Vds subparameter values. | | If more than two [Series MOSFET] tables are supplied, the | analysis is simulator dependent. A simulator may still use | only the first two tables or may use some interpolation and | extrapolation algorithm to predict Ids. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 0.5 | Voltage I(typ) I(min) I(max) | 5.0V 146.9m 87.4m 226.4m | Defines the Ids current as a 4.0V 119.1m 70.0m 185.3m | function of Vgs, for Vds = 0.5 3.0V 82.5m 47.7m 130.1m 2.0V 28.4m 15.2m 46.4m | Normally, more data points would 1.0V 43.9p 37.1p 47.8p | be provide than shown here 0.0V 0.0p 0.0p 0.0p | [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | +-------+ | + | Fixed | - | +------| Vds |-------+ | | +-------+ | | | Ids = Table Current | | | ---> | | +---<---| |--->----+-----+ | d |_____| - s | + | --+-- Vgs +---+---+ | | g + | Sweep | | | Vs | | +---+---+ | | - | GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C_series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments From owner-ibis Fri May 16 13:26:59 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA08183 for ; Fri, 16 May 1997 13:26:52 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 16 May 97 13:25 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 16 May 97 13:25 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 16 May 97 13:25 PDT Message-Id: Date: Fri, 16 May 97 13:25 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.4 Modelling Series Switchable Devices Cc: john.fitzpatrick@ln.cit.alcatel.fr John Fitzpatrick and IBIS Committee: BIRD41.4 is issued in response to some additional private comments and suggestions. A summary of the changes and reasons are listed in the ANALYSIS PATH/DATA ... section of BIRD41.4 Best Regards, Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.4 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: 2/12/97, 2/17/9797, 5/14/97, 5/15/97, 5/16/97 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type values are allowed under the [Model] keyword: Series, Series_Switch Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described in the [Series Switch Groups]. | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the Function Table Group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 On 1 2 4 On 1 3 4 On 2 3 4 | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Usage Rules: Entries follow these rules: Only series pin pairs | are entered. The Pin 1 column contains the pin number for | which input impedances are measured. The Pin 2 column contains | the pin name of the other end of the series device. The | Model_name column names of the model corresponding to the | Series or Series_switch device. | | The Function Table Group column contains an alphanumeric | designator string to associate those sets of Series_switch | pins which are switched together. One possible application | is to model crossbar switches where the straight through | On switches are indicated by one designator and the cross over | paths are indicated by another designator. If the model | referenced is a Series model, then the Function Table | Group entry is required, but ignored. | | Column length limits are: | Pin 1 5 characters max | Pin 2 5 characters max | Model_name 20 characters max | Function Table Group 20 characters max | | Other Notes: If the Model_name is for a non-symmetrical series device, | then the order of the pins is important. Pin 1 and Pin 2 | must be consistent with the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any additonal elements such as additonal | capacitance or clamping circuitry are defined by the Model_name | that is referenced in the [Pin] keyword. Series_switch and | Series pins listed under Pin 1 and Pin 2 must be also be | listed under the [Pin] keyword and the Model_names under the | [Pin] keyword must be for either Terminator Model_types or | 'NC'. Thus a Series_switch model may contain Terminator models | on EACH of the pins to describe both the capacitance on each | pin and some clamping circuitry that may exist on pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] | Pin 1 Pin 2 Model_name Function Table Group | 2 3 CBTSeries 1 | Four Independent Groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight Through Path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross Over Path 25 23 CBTSeries 6 Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R_series], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R_series], [L_series], [R_l_series], | [C_series], [L_c_series], [R_c_series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The | three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | [R_l_series] is 0 ohms if it is not defined in the path. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. [R_c_series] is 0 ohms if it is not | defined in the path. [L_c_series is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings itself provide the assumed gate | voltages. If the [POWER Clamp Reference] exists, it overrides | the [Voltage Range] value. The table entries are actually | the Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be view as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) that is used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | The model data is used to approximate the On state relationship | between Ids, Vds for a given Vgs: Ids = f(Vds) for a given Vgs. | This relationship is used as a series element to solve for the | voltages on each side of the switch during analysis. | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be Ids = (Itable) * Vds / Vgs. In practice, the Ids | value will be less than the the value predicted when Vds > Vgs. | | If two [Series MOSFET] tables are supplied, a quadratic | approximation can be used: | | Ids = k1 * Vds + k2 * Vds * Vds, for Vds < -k1 /2 * K2, | | and the maximum Ids value | | Ids = -k1 * k1 / k2, for Vds => -k1 / 2 * k2. | | The values of k1 and k2 are derived for current value of Vs | by solving the equations given the two Ids values for the two | Vds subparameter values. | | If more than two [Series MOSFET] tables are supplied, the | analysis is simulator dependent. A simulator may still use | only the first two tables or may use some interpolation and | extrapolation algorithm to predict Ids. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 0.5 | Voltage I(typ) I(min) I(max) | 5.0V 146.9m 87.4m 226.4m | Defines the Ids current as a 4.0V 119.1m 70.0m 185.3m | function of Vgs, for Vds = 0.5 3.0V 82.5m 47.7m 130.1m 2.0V 28.4m 15.2m 46.4m | Normally, more data points would 1.0V 43.9p 37.1p 47.8p | be provide than shown here 0.0V 0.0p 0.0p 0.0p | [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the [Model Selector] keyword associated with approved BIRD30.2, change the first paragraph of 'Usage Rules:' as follows so that each occurance of "[Pin] keyword" is changed to "[Pin] or [Series Pin Mapping] keywords": | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keywords | and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] or [Series Pin Mapping] keywords. | In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | +-------+ | + | Fixed | - | +------| Vds |-------+ | | +-------+ | | | Ids = Table Current | | | ---> | | +---<---| |--->----+-----+ | d |_____| - s | + | --+-- Vgs +---+---+ | | g + | Sweep | | | Vs | | +---+---+ | | - | GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C_series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. BIRD41.4: John Fitzpatrick suggested in a private note that models that can be attached to Series or Series_switch models under the [Pin] table be Terminator models. Text is put in Other Notes under [Series Pin Mapping] stating this restriction (and also including 'NC'). It is a complication to allow Input or I/O models, and if the pin is connected to a power rail, this can be done in a simulator dependent manner. John also suggested expanding approved BIRD30.2 to include [Series Pin Mapping] models to be included in the [Model Selector] keyword. This could be used for selecting Series_switch models for Vcc = 5 V or Vcc = 4.3 V when used in 3.3 to 5 V logic interface applications. An additional modification is included to make this change. It makes sense to capture within [Model Selector] all of the Model_names that can be selected. The [Series Pin Mapping] keyword defines new models that are not listed under the [Pin] keyword. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments 41.4 Submitted May 16, 1997 - [Pin] model Terminator or NC restriction for series pins - [Model Selector] keyword addition to include [Series Pin Mapping] models. From owner-ibis Fri May 16 18:08:30 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA12840 for ; Fri, 16 May 1997 18:08:20 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 16 May 97 18:07 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 16 May 97 18:07 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 16 May 97 18:07 PDT Message-Id: Date: Fri, 16 May 97 18:07 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD42 Modeling Current Waveforms Cc: cpk@cadence.com To IBIS Committee: Based on the discussions at the May 9, 1997 IBIS Meeting I am issuing BIRD42. Kumar and I may not agree yet entirely on the format, but I feel it is important to get the proposal on the table to raise any questions and comments. The data in the examples is taken from a Spice extraction of a real device. However, I am suspicious of the initial (0.000nS) current values which may be wrong before the first time step. How this data is to be used needs to be discussed. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 42 ISSUE TITLE: Modeling Current Waveforms REQUESTER: C. Kumar, Cadence, Bob Ross, Interconnectix DATE SUBMITTED: May 16, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Current into the power and ground rails are needed to give a more accurate analysis for ground and power bounce analysis associated with simutaneous switching. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Four current Waveform tables in sync. with [Rising Waveform] and [Falling Waveform] are added. Also some of the data associated with [Rising Waveform] and [Falling Waveform] is modified to reflect a real situation. The existing data in the specification was not realistic and gave incorrect guidance. The waveform tables in the examples were generated from a real sample. (I am suspicious of the 0.000nS current values. I think something is lost in the initial Spice time step.) Replace this section: |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. 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. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | Insert this new [Rising Waveform] and [Fallling Waveform] section and new examples and text changes noted by "|*" lines. Add the new keyword section and examples. |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. 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. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | |* NOTE: The use of L_dut, R_dut, and C_dut is strongly |* discouraged in developing Waveform data from Simulation |* models. Some simulators may ignore these parameters |* because they may introduce numerical time constant |* artifacts. |* | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |* |* NOTE: Test fixtures with R_fixture and V_fixture, |* V_fixture_min, and V_fixture_max only are strongly |* encouraged because they provide the BEST set of data |* needed to produce the best model for simulation. C_fixture |* and L_fixture can be used to produce waveforms which |* describe the |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000S 25.2100mV 15.2200mV 43.5700mV 0.2000nS 2.3325mV -8.5090mV 23.4150mV 0.4000nS 0.1484V 15.9375mV 0.3944V 0.6000nS 0.7799V 0.2673V 1.3400V 0.8000nS 1.2960V 0.6042V 1.9490V 1.0000nS 1.6603V 0.9256V 2.4233V 1.2000nS 1.9460V 1.2050V 2.8130V 1.4000nS 2.1285V 1.3725V 3.0095V 1.6000nS 2.3415V 1.5560V 3.1265V 1.8000nS 2.5135V 1.7015V 3.1600V 2.0000nS 2.6460V 1.8085V 3.1695V | ... 10.0000nS 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000S 5.0000V 4.5000V 5.5000V 0.2000nS 4.7470V 4.4695V 4.8815V 0.4000nS 3.9030V 4.0955V 3.5355V 0.6000nS 2.7313V 3.4533V 1.7770V 0.8000nS 1.8150V 2.8570V 0.8629V 1.0000nS 1.1697V 2.3270V 0.5364V 1.2000nS 0.7539V 1.8470V 0.4524V 1.4000nS 0.5905V 1.5430V 0.4368V 1.6000nS 0.4923V 1.2290V 0.4266V 1.8000nS 0.4639V 0.9906V 0.4207V 2.0000nS 0.4489V 0.8349V 0.4169V | ... 10.0000nS 0.3950V 0.4935V 0.3841V | |============================================================================== | Keywords: [GND Rising Waveform], [GND Falling Waveform], | [POWER Rising Waveform], [GND Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | current waveforms of a GND and POWER nodes, respectively. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture | Usage Rules: Each [GND Rising Waveform] and [GND Falling Waveform], | [POWER Rising Waveform] and [POWER Falling Waveform] | keyword | introduces a table of time vs. current points that | describe the shape of a current waveform. These | time/current points are taken under the conditions | specified in the R/L/C/V_fixture | subparameters. The table itself consists of | one column of time points, then three columns of | current 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. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a current column | must be the DC current before switching | and the last entry (or entries) of the column must be | the final DC value after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters 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. | | NOTE: For computation purposes, the effect of the | L_dut, R_dut, and C_dut subparameters will be ignored. | It is strongly recommmended that they not be used, if | possible. Furthermore, it is strongly recommended that | the 'fixture' not use any L_fixture or C_fixture | component. L_dut, R_dut, and C_dut are not permitted | for the [GND Rising Waveform], [POWER Rising Waveform], | [GND Falling Waveform], and [POWER Falling Waveform] | keywords. | | The current into the ground is shown as I_GND, and the | current into the POWER node is shown as I_POWER. | | Each [GND Rising Waveform] and [POWER Rising Waveform] | tables must correlate with an existing [Rising Waveform] | table. The correlation is done by specifying identical | fixture subparameter values: R_fixture, V_fixture, | V_fixture_min, V_fixture_max, L_fixture, and C_fixture. | Similarly [GND Falling Waveform] and [POWER Falling | Waveform] must correlate with an existing [Falling | Waveform] table. | | Because of the assumption that the currents into the | GND, POWER, and output nodes must sum to zero, only GND | Waveform or POWER waveform tables are needed. The output | node current is available from the test fixture and | output waveform data. However, both GND and POWER | waveform tables are permitted. Similarly, an Open model | device such as Open_drain or and ECL device such as | Output_ECL may not need any GND or POWER waveform tables. | However, each or both are still permitted. It is | simulator dependent which set of data takes precedence | in case of redundant information. | | | POWER | | | | | | I_POWER | | | v | PACKAGE | TEST FIXTURE | ____|____ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | ^ | | | | | I_GND | | C_dut === | === C_fixture | | | | | | | | | | | | GND GND | GND | | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [GND Rising Waveform] R_fixture = 50 V_fixture = 0.0 | Time I(typ) I(min) I(max) 0.0000S -338.4000uA -188.6000uA -635.9000uA 0.2000nS -2.0160mA -123.4000uA -6.2360mA 0.4000nS -2.3650mA -3.5670mA -11.0600mA 0.6000nS -7.2070mA -5.1150mA -12.0600mA 0.8000nS -7.4570mA -4.9160mA -17.1600mA 1.0000nS -8.2950mA -3.9180mA -19.7900mA 1.2000nS -9.5720mA -3.5720mA -8.2330mA 1.4000nS -10.5400mA -3.5850mA -2.9600mA 1.6000nS -7.8290mA -3.8150mA -1.4140mA 1.8000nS -4.6260mA -3.9860mA -1.1420mA 2.0000nS -2.3870mA -4.1520mA -1.1250mA | ... 10.0000nS -388.4000uA -135.3000uA -964.2000uA | [POWER Rising Waveform] R_fixture = 50 V_fixture = 0.0 | Time I(typ) I(min) I(max) 0.0000S 842.5000uA 493.0000uA 1.5070mA 0.2000nS 6.6700mA 3.2490mA 9.7430mA 0.4000nS 12.9000mA 4.6150mA 26.3100mA 0.6000nS 25.9800mA 11.3000mA 42.5700mA 0.8000nS 35.3200mA 19.0900mA 58.4600mA 1.0000nS 43.2400mA 24.2100mA 70.4200mA 1.2000nS 49.7700mA 28.9700mA 64.7800mA 1.4000nS 55.3400mA 32.9800mA 64.7600mA 1.6000nS 56.4000mA 36.3800mA 64.3900mA 1.8000nS 56.3100mA 39.1500mA 64.4500mA 2.0000nS 56.2000mA 41.3300mA 64.5700mA | ... 10.0000nS 55.9500mA 47.3500mA 64.3200mA | [GND Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time I(typ) I(min) I(max) 0.0000S -157.4000uA -86.9600uA -291.0000uA 0.2000nS -34.6000mA -17.1000mA -48.6100mA 0.4000nS -41.5400mA -20.8600mA -70.7200mA 0.6000nS -60.5500mA -30.4800mA -96.8400mA 0.8000nS -77.7500mA -41.5500mA -107.4000mA 1.0000nS -88.1500mA -52.0000mA -115.5000mA 1.2000nS -92.9400mA -60.9400mA -110.6000mA 1.4000nS -96.9700mA -68.0800mA -107.1000mA 1.6000nS -98.1100mA -72.7800mA -106.4000mA 1.8000nS -96.5100mA -75.9600mA -106.0000mA 2.0000nS -95.1600mA -77.7100mA -105.9000mA | ... 10.0000nS -94.3700mA -81.4700mA -106.3000mA [POWER Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time I(typ) I(min) I(max) 0.0000S 157.4000uA 86.8500uA 291.0000uA 0.2000nS 17.4600mA 10.0440mA 22.5200mA 0.4000nS 11.7300mA 8.2320mA 18.0200mA 0.6000nS 11.0800mA 6.8680mA 15.2900mA 0.8000nS 10.1700mA 6.2700mA 11.1900mA 1.0000nS 8.3370mA 6.2160mA 14.7000mA 1.2000nS 6.2100mA 5.7840mA 9.4580mA 1.4000nS 6.9920mA 5.3040mA 5.7280mA 1.6000nS 8.2280mA 4.6130mA 4.8490mA 1.8000nS 5.5850mA 3.8730mA 4.3310mA 2.0000nS 4.0180mA 3.2190mA 4.1990mA | ... 10.0000nS 2.2710mA 1.3390mA 3.9900mA | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Some additonal clarification information is needed in the original [Rising Waveform] and [Falling Waveform] keyword. A better example needs to be supplied because the existing example illustrates some bad practices. The current waveform specification is needed to better define the currents in the GND and POWER nodes during switching. Currently the allocation of currents into these nodes is simulator-algorithm dependent. There is no information regarding paths directly from POWER to GND as might occur in a make-before-break transition implementation that exists in some CMOS devices. The L_dut, R_dut, and C_dut fixture parameters are deleted from the new keywords. While actual package electrical characteristic may exist, there effects are negligible for current waveforms. Moreover, this level of detail has proven in many case to actually reduce accuracy in simulation because of numerical time constant considerations. Suggestions encouraging resistive-only fixture loads are embedded in this proposal to encourage generating data that is most suitable for developing models that may be used by most simulators. The new examples reflect this practice. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on discussion initiated by C. Kumar at the IBIS Open Forum Meeting on May 9, 1997 From owner-ibis Fri May 16 19:17:53 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id TAA13811 for ; Fri, 16 May 1997 19:17:46 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 16 May 97 19:16 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 16 May 97 19:16 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.16) id ; Fri, 16 May 97 19:16 PDT Message-Id: Date: Fri, 16 May 97 19:16 PDT From: scottmc@icx.com (Scott McMorrow) To: ibis@vhdl.org, owner-ibis@server.vhdl.org Subject: Re: BIRD42 Modeling Current Waveforms Cc: cpk@cadence.com To IBIS Committee: It is not sufficient to model only the effects of output switching on package currents. In addition, the effects of input switching on package currents must be modeled (e.g. - the internal clock switching effects within a modern processor, or the asynchronous turn-on characteristics of a memory device.) These additional effects are oftentimes orders of magnitude larger than those of the output buffers, and are often only loosely correlated in time with the switching of device outputs. To correctly model the total current switching behavior of a modern device it is necessary to couple a high level behavorial model of the switching characteristics of the device, with the current attack and decay profiles of the I/O buffers and associated logic, input buffers and clamp logic, along with the substantial core logic of most devices. Then, the device must be simulated simulatneously in a board environment with all other devices modeled in the same manner. Anything less ain't even close, leading to gross underpredictions of the power transient currents on boards and devices. Scott McMorrow Stramond Corporation > To IBIS Committee: > Based on the discussions at the May 9, 1997 IBIS Meeting I am > issuing BIRD42. Kumar and I may not agree yet entirely on the > format, but I feel it is important to get the proposal on the > table to raise any questions and comments. > The data in the examples is taken from a Spice extraction of a > real device. However, I am suspicious of the initial (0.000nS) > current values which may be wrong before the first time step. > How this data is to be used needs to be discussed. > Bob Ross > Interconnectix > ****************************************************************************** > ****************************************************************************** > BIRD ID#: 42 > ISSUE TITLE: Modeling Current Waveforms > REQUESTER: C. Kumar, Cadence, Bob Ross, Interconnectix > DATE SUBMITTED: May 16, 1997 > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > ****************************************************************************** > ****************************************************************************** > STATEMENT OF THE ISSUE: > Current into the power and ground rails are needed to give a more accurate > analysis for ground and power bounce analysis associated with simutaneous > switching. > > ****************************************************************************** > STATEMENT OF THE RESOLVED SPECIFICATIONS: > Four current Waveform tables in sync. with [Rising Waveform] and > [Falling Waveform] are added. > Also some of the data associated with [Rising Waveform] and [Falling Waveform] > is modified to reflect a real situation. The existing data in the > specification was not realistic and gave incorrect guidance. > The waveform tables in the examples were generated from a real sample. > (I am suspicious of the 0.000nS current values. I think something is > lost in the initial Spice time step.) > Replace this section: > |============================================================================== > | Keywords: [Rising Waveform], [Falling Waveform] > | Required: No > | Description: Describes the shape of the rising and falling edge > | waveforms of a driver. > | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, > | C_fixture, L_fixture, R_dut, L_dut, C_dut > | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword > | introduces a table of time vs. voltage points that > | describe the shape of an output waveform. These > | time/voltage points are taken under the conditions > | specified in the R/L/C/V_fixture and R/L/C_dut > | subparameters. 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. The data in the waveform > | table is taken with the effects of the C_comp parameter > | included. > | > | A waveform table must include the entire waveform; > | i.e., the first entry (or entries) in a voltage column > | must be the DC voltage of the output before switching > | and the last entry (or entries) of the column must be > | the final DC value of the output after switching. Each > | table must contain at least two entries. Thus, numerical > | values are required for the first and last entries of any > | column containing numerical data. > | > | A [Model] specification can contain more than one rising > | edge or falling edge waveform table. However, each new > | table must begin with the appropriate keyword and sub- > | parameter list as shown below. If more than one rising or > | falling edge waveform table is present, then the data in > | each of the respective tables must be time correlated. > | In other words, the rising (falling) edge data in each > | of the rising (falling) edge waveform tables must be > | entered with respect to a common reference point on the > | input stimulus waveform. > | > | The 'fixture' subparameters specify the loading > | conditions under which the waveform is taken. The R_dut, > | C_dut, and L_dut subparameters are analogous to the > | package parameters R_pkg, C_pkg, and L_pkg and are used > | if the waveform includes the effects of pin > | inductance/capacitance. The diagram below shows the > | interconnection of these elements. > | > | PACKAGE | TEST FIXTURE > | _________ | > | | DUT | L_dut R_dut | L_fixture R_fixture > | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture > | |_________| | | | > | | | | > | | | | > | C_dut === | === C_fixture > | | | | > | | | | > | GND | GND > | > | Only the R_fixture and V_fixture subparameters are > | required, the rest of the subparameters are optional. > | If a subparameter is not used, its value defaults to > | zero. The subparameters must appear in the text after > | the keyword and before the first row of the waveform > | table. > | > | V_fixture defines the voltage for typ, min, and max > | supply conditions. However, when the fixture voltage > | is related to the power supply voltages, then the > | subparameters V_fixture_min and V_fixture_max can > | be used to further specify the fixture voltage for > | min and max supply voltages. > |------------------------------------------------------------------------------ > [Rising Waveform] > R_fixture = 500 > V_fixture = 5.0 > V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc > V_fixture_max = 5.5 |Specified, but not used in this example > C_fixture = 50p > L_fixture = 2n > C_dut = 7p > R_dut = 1m > L_dut = 1n > |Time V(typ) V(min) V(max) > 0.0ns 0.3 0.5 NA > 0.5ns 0.3 0.5 NA > 1.0ns 0.6 0.7 NA > 1.5ns 0.9 0.9 NA > 2.0ns 1.5 1.3 NA > 2.5ns 2.1 1.7 NA > 3.0ns 3.0 2.7 NA > 3.5ns 3.2 3.0 NA > | > [Falling Waveform] > R_fixture = 50 > V_fixture = 0 > |Time V(typ) V(min) V(max) > 10.0ns 3.2 3.0 NA > 10.5ns 3.0 2.7 NA > 11.0ns 2.1 1.7 NA > 11.5ns 1.5 1.3 NA > 12.0ns 0.9 0.9 NA > 12.5ns 0.6 0.7 NA > 13.0ns 0.3 0.5 NA > 13.5ns 0.3 0.5 NA > | > Insert this new [Rising Waveform] and [Fallling Waveform] section and new > examples and text changes noted by "|*" lines. Add the new keyword > section and examples. > |============================================================================== > | Keywords: [Rising Waveform], [Falling Waveform] > | Required: No > | Description: Describes the shape of the rising and falling edge > | waveforms of a driver. > | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, > | C_fixture, L_fixture, R_dut, L_dut, C_dut > | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword > | introduces a table of time vs. voltage points that > | describe the shape of an output waveform. These > | time/voltage points are taken under the conditions > | specified in the R/L/C/V_fixture and R/L/C_dut > | subparameters. 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. The data in the waveform > | table is taken with the effects of the C_comp parameter > | included. > | > | A waveform table must include the entire waveform; > | i.e., the first entry (or entries) in a voltage column > | must be the DC voltage of the output before switching > | and the last entry (or entries) of the column must be > | the final DC value of the output after switching. Each > | table must contain at least two entries. Thus, numerical > | values are required for the first and last entries of any > | column containing numerical data. > | > | A [Model] specification can contain more than one rising > | edge or falling edge waveform table. However, each new > | table must begin with the appropriate keyword and sub- > | parameter list as shown below. If more than one rising or > | falling edge waveform table is present, then the data in > | each of the respective tables must be time correlated. > | In other words, the rising (falling) edge data in each > | of the rising (falling) edge waveform tables must be > | entered with respect to a common reference point on the > | input stimulus waveform. > | > | The 'fixture' subparameters specify the loading > | conditions under which the waveform is taken. The R_dut, > | C_dut, and L_dut subparameters are analogous to the > | package parameters R_pkg, C_pkg, and L_pkg and are used > | if the waveform includes the effects of pin > | inductance/capacitance. The diagram below shows the > | interconnection of these elements. > | > | PACKAGE | TEST FIXTURE > | _________ | > | | DUT | L_dut R_dut | L_fixture R_fixture > | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture > | |_________| | | | > | | | | > | | | | > | C_dut === | === C_fixture > | | | | > | | | | > | GND | GND > | > |* NOTE: The use of L_dut, R_dut, and C_dut is strongly > |* discouraged in developing Waveform data from Simulation > |* models. Some simulators may ignore these parameters > |* because they may introduce numerical time constant > |* artifacts. > |* > | Only the R_fixture and V_fixture subparameters are > | required, the rest of the subparameters are optional. > | If a subparameter is not used, its value defaults to > | zero. The subparameters must appear in the text after > | the keyword and before the first row of the waveform > | table. > | > | V_fixture defines the voltage for typ, min, and max > | supply conditions. However, when the fixture voltage > | is related to the power supply voltages, then the > | subparameters V_fixture_min and V_fixture_max can > | be used to further specify the fixture voltage for > | min and max supply voltages. > |* > |* NOTE: Test fixtures with R_fixture and V_fixture, > |* V_fixture_min, and V_fixture_max only are strongly > |* encouraged because they provide the BEST set of data > |* needed to produce the best model for simulation. C_fixture > |* and L_fixture can be used to produce waveforms which > |* describe the > |------------------------------------------------------------------------------ > [Rising Waveform] > R_fixture = 50 > V_fixture = 0.0 > | C_fixture = 50p | These are shown, but are generally not recommended > | L_fixture = 2n > | C_dut = 7p > | R_dut = 1m > | L_dut = 1n > | Time V(typ) V(min) V(max) > 0.0000S 25.2100mV 15.2200mV 43.5700mV > 0.2000nS 2.3325mV -8.5090mV 23.4150mV > 0.4000nS 0.1484V 15.9375mV 0.3944V > 0.6000nS 0.7799V 0.2673V 1.3400V > 0.8000nS 1.2960V 0.6042V 1.9490V > 1.0000nS 1.6603V 0.9256V 2.4233V > 1.2000nS 1.9460V 1.2050V 2.8130V > 1.4000nS 2.1285V 1.3725V 3.0095V > 1.6000nS 2.3415V 1.5560V 3.1265V > 1.8000nS 2.5135V 1.7015V 3.1600V > 2.0000nS 2.6460V 1.8085V 3.1695V > | ... > 10.0000nS 2.7780V 2.3600V 3.1670V > | > [Falling Waveform] > R_fixture = 50 > V_fixture = 5.5 > V_fixture_min = 4.5 > V_fixture_max = 5.5 > | Time V(typ) V(min) V(max) > 0.0000S 5.0000V 4.5000V 5.5000V > 0.2000nS 4.7470V 4.4695V 4.8815V > 0.4000nS 3.9030V 4.0955V 3.5355V > 0.6000nS 2.7313V 3.4533V 1.7770V > 0.8000nS 1.8150V 2.8570V 0.8629V > 1.0000nS 1.1697V 2.3270V 0.5364V > 1.2000nS 0.7539V 1.8470V 0.4524V > 1.4000nS 0.5905V 1.5430V 0.4368V > 1.6000nS 0.4923V 1.2290V 0.4266V > 1.8000nS 0.4639V 0.9906V 0.4207V > 2.0000nS 0.4489V 0.8349V 0.4169V > | ... > 10.0000nS 0.3950V 0.4935V 0.3841V > | > |============================================================================== > | Keywords: [GND Rising Waveform], [GND Falling Waveform], > | [POWER Rising Waveform], [GND Falling Waveform] > | Required: No > | Description: Describes the shape of the rising and falling edge > | current waveforms of a GND and POWER nodes, respectively. > | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, > | C_fixture, L_fixture > | Usage Rules: Each [GND Rising Waveform] and [GND Falling Waveform], > | [POWER Rising Waveform] and [POWER Falling Waveform] > | keyword > | introduces a table of time vs. current points that > | describe the shape of a current waveform. These > | time/current points are taken under the conditions > | specified in the R/L/C/V_fixture > | subparameters. The table itself consists of > | one column of time points, then three columns of > | current 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. > | > | A waveform table must include the entire waveform; > | i.e., the first entry (or entries) in a current column > | must be the DC current before switching > | and the last entry (or entries) of the column must be > | the final DC value after switching. Each > | table must contain at least two entries. Thus, numerical > | values are required for the first and last entries of any > | column containing numerical data. > | > | A [Model] specification can contain more than one rising > | edge or falling edge waveform table. However, each new > | table must begin with the appropriate keyword and sub- > | parameter list as shown below. If more than one rising or > | falling edge waveform table is present, then the data in > | each of the respective tables must be time correlated. > | In other words, the rising (falling) edge data in each > | of the rising (falling) edge waveform tables must be > | entered with respect to a common reference point on the > | input stimulus waveform. > | > | The 'fixture' subparameters specify the loading > | conditions under which the waveform is taken. The R_dut, > | C_dut, and L_dut subparameters 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. > | > | NOTE: For computation purposes, the effect of the > | L_dut, R_dut, and C_dut subparameters will be ignored. > | It is strongly recommmended that they not be used, if > | possible. Furthermore, it is strongly recommended that > | the 'fixture' not use any L_fixture or C_fixture > | component. L_dut, R_dut, and C_dut are not permitted > | for the [GND Rising Waveform], [POWER Rising Waveform], > | [GND Falling Waveform], and [POWER Falling Waveform] > | keywords. > | > | The current into the ground is shown as I_GND, and the > | current into the POWER node is shown as I_POWER. > | > | Each [GND Rising Waveform] and [POWER Rising Waveform] > | tables must correlate with an existing [Rising Waveform] > | table. The correlation is done by specifying identical > | fixture subparameter values: R_fixture, V_fixture, > | V_fixture_min, V_fixture_max, L_fixture, and C_fixture. > | Similarly [GND Falling Waveform] and [POWER Falling > | Waveform] must correlate with an existing [Falling > | Waveform] table. > | > | Because of the assumption that the currents into the > | GND, POWER, and output nodes must sum to zero, only GND > | Waveform or POWER waveform tables are needed. The output > | node current is available from the test fixture and > | output waveform data. However, both GND and POWER > | waveform tables are permitted. Similarly, an Open model > | device such as Open_drain or and ECL device such as > | Output_ECL may not need any GND or POWER waveform tables. > | However, each or both are still permitted. It is > | simulator dependent which set of data takes precedence > | in case of redundant information. > | > | > | POWER > | | > | | | > | I_POWER | | > | v | PACKAGE | TEST FIXTURE > | ____|____ | > | | DUT | L_dut R_dut | L_fixture R_fixture > | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture > | |_________| | | | > | | | | | > | ^ | | | | > | I_GND | | C_dut === | === C_fixture > | | | | | | > | | | | | > | GND GND | GND > | > | Only the R_fixture and V_fixture subparameters are > | required, the rest of the subparameters are optional. > | If a subparameter is not used, its value defaults to > | zero. The subparameters must appear in the text after > | the keyword and before the first row of the waveform > | table. > | > | V_fixture defines the voltage for typ, min, and max > | supply conditions. However, when the fixture voltage > | is related to the power supply voltages, then the > | subparameters V_fixture_min and V_fixture_max can > | be used to further specify the fixture voltage for > | min and max supply voltages. > |------------------------------------------------------------------------------ > [GND Rising Waveform] > R_fixture = 50 > V_fixture = 0.0 > | Time I(typ) I(min) I(max) > 0.0000S -338.4000uA -188.6000uA -635.9000uA > 0.2000nS -2.0160mA -123.4000uA -6.2360mA > 0.4000nS -2.3650mA -3.5670mA -11.0600mA > 0.6000nS -7.2070mA -5.1150mA -12.0600mA > 0.8000nS -7.4570mA -4.9160mA -17.1600mA > 1.0000nS -8.2950mA -3.9180mA -19.7900mA > 1.2000nS -9.5720mA -3.5720mA -8.2330mA > 1.4000nS -10.5400mA -3.5850mA -2.9600mA > 1.6000nS -7.8290mA -3.8150mA -1.4140mA > 1.8000nS -4.6260mA -3.9860mA -1.1420mA > 2.0000nS -2.3870mA -4.1520mA -1.1250mA > | ... > 10.0000nS -388.4000uA -135.3000uA -964.2000uA > | > [POWER Rising Waveform] > R_fixture = 50 > V_fixture = 0.0 > | Time I(typ) I(min) I(max) > 0.0000S 842.5000uA 493.0000uA 1.5070mA > 0.2000nS 6.6700mA 3.2490mA 9.7430mA > 0.4000nS 12.9000mA 4.6150mA 26.3100mA > 0.6000nS 25.9800mA 11.3000mA 42.5700mA > 0.8000nS 35.3200mA 19.0900mA 58.4600mA > 1.0000nS 43.2400mA 24.2100mA 70.4200mA > 1.2000nS 49.7700mA 28.9700mA 64.7800mA > 1.4000nS 55.3400mA 32.9800mA 64.7600mA > 1.6000nS 56.4000mA 36.3800mA 64.3900mA > 1.8000nS 56.3100mA 39.1500mA 64.4500mA > 2.0000nS 56.2000mA 41.3300mA 64.5700mA > | ... > 10.0000nS 55.9500mA 47.3500mA 64.3200mA > | > [GND Falling Waveform] > R_fixture = 50 > V_fixture = 5.5 > V_fixture_min = 4.5 > V_fixture_max = 5.5 > | Time I(typ) I(min) I(max) > 0.0000S -157.4000uA -86.9600uA -291.0000uA > 0.2000nS -34.6000mA -17.1000mA -48.6100mA > 0.4000nS -41.5400mA -20.8600mA -70.7200mA > 0.6000nS -60.5500mA -30.4800mA -96.8400mA > 0.8000nS -77.7500mA -41.5500mA -107.4000mA > 1.0000nS -88.1500mA -52.0000mA -115.5000mA > 1.2000nS -92.9400mA -60.9400mA -110.6000mA > 1.4000nS -96.9700mA -68.0800mA -107.1000mA > 1.6000nS -98.1100mA -72.7800mA -106.4000mA > 1.8000nS -96.5100mA -75.9600mA -106.0000mA > 2.0000nS -95.1600mA -77.7100mA -105.9000mA > | ... > 10.0000nS -94.3700mA -81.4700mA -106.3000mA > [POWER Falling Waveform] > R_fixture = 50 > V_fixture = 5.5 > V_fixture_min = 4.5 > V_fixture_max = 5.5 > | Time I(typ) I(min) I(max) > 0.0000S 157.4000uA 86.8500uA 291.0000uA > 0.2000nS 17.4600mA 10.0440mA 22.5200mA > 0.4000nS 11.7300mA 8.2320mA 18.0200mA > 0.6000nS 11.0800mA 6.8680mA 15.2900mA > 0.8000nS 10.1700mA 6.2700mA 11.1900mA > 1.0000nS 8.3370mA 6.2160mA 14.7000mA > 1.2000nS 6.2100mA 5.7840mA 9.4580mA > 1.4000nS 6.9920mA 5.3040mA 5.7280mA > 1.6000nS 8.2280mA 4.6130mA 4.8490mA > 1.8000nS 5.5850mA 3.8730mA 4.3310mA > 2.0000nS 4.0180mA 3.2190mA 4.1990mA > | ... > 10.0000nS 2.2710mA 1.3390mA 3.9900mA > | > ****************************************************************************** > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: > Some additonal clarification information is needed in the original [Rising > Waveform] and [Falling Waveform] keyword. A better example needs to > be supplied because the existing example illustrates some bad practices. > The current waveform specification is needed to better define the > currents in the GND and POWER nodes during switching. Currently the > allocation of currents into these nodes is simulator-algorithm dependent. > There is no information regarding paths directly from POWER to GND as > might occur in a make-before-break transition implementation that exists > in some CMOS devices. > The L_dut, R_dut, and C_dut fixture parameters are deleted from the > new keywords. While actual package electrical characteristic may exist, > there effects are negligible for current waveforms. Moreover, this > level of detail has proven in many case to actually reduce accuracy in > simulation because of numerical time constant considerations. > Suggestions encouraging resistive-only fixture loads are embedded in this > proposal to encourage generating data that is most suitable for developing > models that may be used by most simulators. The new examples reflect this > practice. > ****************************************************************************** > ANY OTHER BACKGROUND INFORMATION: > This proposal is based on discussion initiated by C. Kumar at the IBIS > Open Forum Meeting on May 9, 1997 From owner-ibis Sun May 18 09:33:29 1997 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA15234 for ; Sun, 18 May 1997 09:33:28 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id JAA29144; Sun, 18 May 1997 09:32:41 -0700 (PDT) Message-Id: <3.0.32.19970518093245.00735594@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 18 May 1997 09:32:46 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Re: BIRD42 Modeling Current Waveforms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Scott, IBIS At 07:16 PM 5/16/97 PDT, you wrote: >It is not sufficient to model only the effects of output switching >on package currents. >.... >Anything less ain't even close, leading to gross underpredictions >of the power transient currents on boards and devices. >Scott McMorrow >Stramond Corporation You make a valid point that IBIS can be improved to include internal effects of devices during switching intervals to better predict power transients. However to say "that anything else is not close" or that these effects "must be modeled" is at the very least quite ridiculous. There are numerous types of simulations using IBIS models e.g. analysis of transmission line effects in propagating signals which was the original goal of IBIS. To say that IBIS is not acceptable in general because it is not perfect for some devices at doing power transient analysis is simply not true. Additionally there are numerous classes of components for which modeling the output buffers does give a very good indication of the power transients. Obviously as the internal complexity increase relative to the current switching magnitude of the outputs the accuracy decreases as you correctly pointed out. Perhaps I am taking your statement out of context. If so would you consider being more specific about the context you had in mind for your comments. For example if you intended your comments to reflect only modeling power transients I would prefer that you preface your opening with such. Kellee ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx Inc. kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Sun May 18 18:14:15 1997 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.29.70]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA23311 for ; Sun, 18 May 1997 18:14:14 -0700 (PDT) Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA07958; Mon, 19 May 1997 01:19:27 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400003091498; Sun, 18 May 1997 21:16:14 -0400 From: Joe Cahill To: Subject: Re: BIRD42 Modeling Current Waveforms Message-Id: <5010400003091498000002L082*@MHS> Date: Sun, 18 May 1997 21:16:14 -0400 Mime-Version: 1.0 Content-Type: text/plain I think that if you intend to model the effect of power supply disturbances on the switching waveforms at other chip receivers you would like a way to specify the ground and power supply disturbances themselves. Probably a companion proposal to bird42. The proposal in question provides a way to determine part of the disturbance, along with the appropriate simulator modelling for the package inductance and capacitance. Determining the rest of the disturbance isn't addressed by this proposal, but knowing a little bit more about a devices' characteristics never hurt anyone. As they say, it's a start. Although the two purposes are inter-related, they are distinctly different, and should not be confused when judging the merits of any proposal to address either problem. Joe From owner-ibis Mon May 19 17:46:42 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id RAA14148 for ; Mon, 19 May 1997 17:46:36 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Mon, 19 May 97 17:45 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Mon, 19 May 97 17:45 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Mon, 19 May 97 17:45 PDT Message-Id: Date: Mon, 19 May 97 17:45 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD42.1 MODELING CURRENT WAVEFORMS To IBIS Committee BIRD42.1 has exactly the same functionality as BIRD42, but with a format restriction and simplification. The major change is: Elimate [GND Rising Waveform], [GND Falling Waveform], [POWER Rising Waveform], [POWER Falling Waveform] Instead, add as a result, [GND Current] and [POWER Current]. These keywords are restricted to directly under their corresponding [Rising Waveform] and [Falling Waveform] tables for the particular waveform of interest. Eliminate all references to subparameters - The current tables are based on the [Rising Waveform] and [Falling Waveform] table Subparameters. This change is documented below. Also, I acknowledge that even with this more detailed set of data, REAL power and bounce analsis may be influenced by factors BEYOND Output buffer switching. Scott McMorrow correctly points out that some internal circuitry such as internal clock drivers are already internally loaded and may not have external connections. There may be significant movement of currents due to these internal elements that can interact and affect the internal bounce of common internal ground and power busses. So beware that bounce analysis may be more dependent on (undocumented) internal construction (sharing of common busses) and undocumented internal switching effects. The IBIS Model may UNDERESTIMATE the true bounce effects. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 42.1 ISSUE TITLE: Modeling Current Waveforms REQUESTER: C. Kumar, Cadence, Bob Ross, Interconnectix DATE SUBMITTED: May 16, 1997, May 19, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Current into the power and ground rails are needed to give a more accurate analysis for ground and power bounce analysis associated with simutaneous switching. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Four current Waveform tables in sync. with [Rising Waveform] and [Falling Waveform] are added. Also some of the data associated with [Rising Waveform] and [Falling Waveform] is modified to reflect a real situation. The existing data in the specification was not realistic and gave incorrect guidance. The waveform tables in the examples were generated from a real sample. (I am suspicious of the 0.000nS current values. I think something is lost in the initial Spice time step.) Replace this section: |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. 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. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | Insert this new [Rising Waveform] and [Fallling Waveform] section and new examples and text changes noted by "|*" lines. Add the new keyword section and examples. |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. 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. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | |* NOTE: The use of L_dut, R_dut, and C_dut is strongly |* discouraged in developing Waveform data from Simulation |* models. Some simulators may ignore these parameters |* because they may introduce numerical time constant |* artifacts. |* | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |* |* NOTE: Test fixtures with R_fixture and V_fixture, |* V_fixture_min, and V_fixture_max only are strongly |* encouraged because they provide the BEST set of data |* needed to produce the best model for simulation. C_fixture |* and L_fixture can be used to produce waveforms which |* describe the |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000S 25.2100mV 15.2200mV 43.5700mV 0.2000nS 2.3325mV -8.5090mV 23.4150mV 0.4000nS 0.1484V 15.9375mV 0.3944V 0.6000nS 0.7799V 0.2673V 1.3400V 0.8000nS 1.2960V 0.6042V 1.9490V 1.0000nS 1.6603V 0.9256V 2.4233V 1.2000nS 1.9460V 1.2050V 2.8130V 1.4000nS 2.1285V 1.3725V 3.0095V 1.6000nS 2.3415V 1.5560V 3.1265V 1.8000nS 2.5135V 1.7015V 3.1600V 2.0000nS 2.6460V 1.8085V 3.1695V | ... 10.0000nS 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000S 5.0000V 4.5000V 5.5000V 0.2000nS 4.7470V 4.4695V 4.8815V 0.4000nS 3.9030V 4.0955V 3.5355V 0.6000nS 2.7313V 3.4533V 1.7770V 0.8000nS 1.8150V 2.8570V 0.8629V 1.0000nS 1.1697V 2.3270V 0.5364V 1.2000nS 0.7539V 1.8470V 0.4524V 1.4000nS 0.5905V 1.5430V 0.4368V 1.6000nS 0.4923V 1.2290V 0.4266V 1.8000nS 0.4639V 0.9906V 0.4207V 2.0000nS 0.4489V 0.8349V 0.4169V | ... 10.0000nS 0.3950V 0.4935V 0.3841V | |============================================================================== | Keywords: [GND Current], [POWER Current], | Required: No | Description: Describes the shape of the rising and falling edge | current waveforms of a GND and POWER nodes, respectively. | Usage Rules: Each [GND Current] and [POWER Current] keyword is | positioned under the [Rising Waveform] (for rising | waveform currents) and [Fallling Waveform (for falling | waveform currents. The keywords are followed by a table | of time vs. current points that | describe the shape of a current waveform. These | time/current points are taken under the conditions | specified in the R/L/C/V_fixture | subparameters. The table itself consists of | one column of time points, then three columns of | current 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. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a current column | must be the DC current before switching | and the last entry (or entries) of the column must be | the final DC value after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The diagram below illustrates the complete model with | respect to the [Rising Waveform] and [Falling Waveform] | subparameters. The diagram also illustrates the direction | of positive [GND Waveform] and [POWER Waveform] current | flow by the notation I_GND and I_POWER. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters 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. | | NOTE: For computation purposes, the effect of the | L_dut, R_dut, and C_dut subparameters will be ignored. | It is strongly recommmended that they not be used, if | possible. Furthermore, it is strongly recommended that | the 'fixture' not use any L_fixture or C_fixture | component. | | Each [GND Current] and [POWER Current] | table must correlate with an existing [Rising Waveform] | table or [Falling Waveform] table. | | Because of the assumption that the currents into the | GND, POWER, and output nodes must sum to zero, only GND | Waveform or POWER waveform tables are needed. The output | node current is available from the test fixture and | output waveform data. However, both GND and POWER | waveform tables are permitted. Similarly, an Open model | device such as Open_drain or and ECL device such as | Output_ECL may not need any GND or POWER waveform tables. | However, each or both are still permitted. It is | simulator dependent which set of data takes precedence | in case of redundant information. | | | POWER | | | | | | I_POWER | | | v | PACKAGE | TEST FIXTURE | ____|____ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/¥/¥/¥--o-----|--@@@@---o---/¥/¥/¥----- V_fixture | |_________| | | | | | | | | | ^ | | | | | I_GND | | C_dut === | === C_fixture | | | | | | | | | | | | GND GND | GND | | |------------------------------------------------------------------------------ [Rising Waveform] | ... | ... | Rising Waveform subparameters and table | ... [GND Current] | Time I(typ) I(min) I(max) 0.0000S -338.4000uA -188.6000uA -635.9000uA 0.2000nS -2.0160mA -123.4000uA -6.2360mA 0.4000nS -2.3650mA -3.5670mA -11.0600mA 0.6000nS -7.2070mA -5.1150mA -12.0600mA 0.8000nS -7.4570mA -4.9160mA -17.1600mA 1.0000nS -8.2950mA -3.9180mA -19.7900mA 1.2000nS -9.5720mA -3.5720mA -8.2330mA 1.4000nS -10.5400mA -3.5850mA -2.9600mA 1.6000nS -7.8290mA -3.8150mA -1.4140mA 1.8000nS -4.6260mA -3.9860mA -1.1420mA 2.0000nS -2.3870mA -4.1520mA -1.1250mA | ... 10.0000nS -388.4000uA -135.3000uA -964.2000uA | [POWER Current] | Time I(typ) I(min) I(max) 0.0000S 842.5000uA 493.0000uA 1.5070mA 0.2000nS 6.6700mA 3.2490mA 9.7430mA 0.4000nS 12.9000mA 4.6150mA 26.3100mA 0.6000nS 25.9800mA 11.3000mA 42.5700mA 0.8000nS 35.3200mA 19.0900mA 58.4600mA 1.0000nS 43.2400mA 24.2100mA 70.4200mA 1.2000nS 49.7700mA 28.9700mA 64.7800mA 1.4000nS 55.3400mA 32.9800mA 64.7600mA 1.6000nS 56.4000mA 36.3800mA 64.3900mA 1.8000nS 56.3100mA 39.1500mA 64.4500mA 2.0000nS 56.2000mA 41.3300mA 64.5700mA | ... 10.0000nS 55.9500mA 47.3500mA 64.3200mA | [Falling Waveform] | ... | ... | Falling Waveform subparameters and table | ... [GND Current] | Time I(typ) I(min) I(max) 0.0000S -157.4000uA -86.9600uA -291.0000uA 0.2000nS -34.6000mA -17.1000mA -48.6100mA 0.4000nS -41.5400mA -20.8600mA -70.7200mA 0.6000nS -60.5500mA -30.4800mA -96.8400mA 0.8000nS -77.7500mA -41.5500mA -107.4000mA 1.0000nS -88.1500mA -52.0000mA -115.5000mA 1.2000nS -92.9400mA -60.9400mA -110.6000mA 1.4000nS -96.9700mA -68.0800mA -107.1000mA 1.6000nS -98.1100mA -72.7800mA -106.4000mA 1.8000nS -96.5100mA -75.9600mA -106.0000mA 2.0000nS -95.1600mA -77.7100mA -105.9000mA | ... 10.0000nS -94.3700mA -81.4700mA -106.3000mA [POWER Current] | Time I(typ) I(min) I(max) 0.0000S 157.4000uA 86.8500uA 291.0000uA 0.2000nS 17.4600mA 10.0440mA 22.5200mA 0.4000nS 11.7300mA 8.2320mA 18.0200mA 0.6000nS 11.0800mA 6.8680mA 15.2900mA 0.8000nS 10.1700mA 6.2700mA 11.1900mA 1.0000nS 8.3370mA 6.2160mA 14.7000mA 1.2000nS 6.2100mA 5.7840mA 9.4580mA 1.4000nS 6.9920mA 5.3040mA 5.7280mA 1.6000nS 8.2280mA 4.6130mA 4.8490mA 1.8000nS 5.5850mA 3.8730mA 4.3310mA 2.0000nS 4.0180mA 3.2190mA 4.1990mA | ... 10.0000nS 2.2710mA 1.3390mA 3.9900mA | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Some additonal clarification information is needed in the original [Rising Waveform] and [Falling Waveform] keyword. A better example needs to be supplied because the existing example illustrates some bad practices. The current waveform specification is needed to better define the currents in the GND and POWER nodes during switching. Currently the allocation of currents into these nodes is simulator-algorithm dependent. There is no information regarding paths directly from POWER to GND as might occur in a make-before-break transition implementation that exists in some CMOS devices. The L_dut, R_dut, and C_dut fixture parameters are deleted from the new keywords. While actual package electrical characteristic may exist, there effects are negligible for current waveforms. Moreover, this level of detail has proven in many case to actually reduce accuracy in simulation because of numerical time constant considerations. Suggestions encouraging resistive-only fixture loads are embedded in this proposal to encourage generating data that is most suitable for developing models that may be used by most simulators. The new examples reflect this practice. BIRD42.1: By restricting the already correlated current waveforms to be under the current keyword, several simplifications can be made: Elimate [GND Rising Waveform], [GND Falling Waveform], [POWER Rising Waveform], [POWER Falling Waveform] Instead, add as a result, [GND Current] and [POWER Current]. These keywords are restricted to directly under their corresponding [Rising Waveform] and [Falling Waveform] tables for the particular waveform of interest. Eliminate all references to subparameters - The current tables are based on the [Rising Waveform] and [Falling Waveform] table Subparameters. All of the proposed functionality remains. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on discussion initiated by C. Kumar at the IBIS Open Forum Meeting on May 9, 1997 Part of the introduction material for BIRD42.1 includes this statement: "Also, I acknowledge that even with this more detailed set of data, REAL power and bounce analsis may be influenced by factors BEYOND Output buffer switching. Scott McMorrow correctly points out that some internal circuitry such as internal clock drivers are already internally loaded and may not have external connections. There may be significant movement of currents due to these internal elements that can interact and affect the internal bounce of common internal ground and power busses. So beware that bounce analysis may be more dependent on (undocumented) internal construction (sharing of common busses) and undocumented internal switching effects. The IBIS Model may UNDERESTIMATE the true bounce effects." From owner-ibis Tue May 20 08:36:43 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA27203 for ; Tue, 20 May 1997 08:36:40 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA25678 for ; Tue, 20 May 1997 08:35:32 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA27353; Tue, 20 May 1997 08:35:46 -0700 (PDT) Message-Id: <199705201535.IAA27353@ichips.intel.com> To: ibis@vhdl.org Subject: Question on BIRD42.1 intent Date: Tue, 20 May 1997 08:35:46 -0700 From: Stephen Peters Hello All: I've been following the discussion on including the power and ground current 'waveforms' in the IBIS file, and I have a question. I thought (based on the original phone discussion at the last IBIS teleconference) that the purpose of including the power and ground current info was to make it eaiser to model the turnon/turnoff charactoristics of a driver -- NOT to enable better ground bounce simulations (although I realize that this info does help). What, exactly, is the intent of including this info? Should the bird include some words stating that the power supply waveforms may not give a complete picture of ground bounce? Should it not say anything? Just wondering..... Regards, Stephen Peters Intel Corp. From owner-ibis Tue May 20 09:11:22 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA27960 for ; Tue, 20 May 1997 09:11:22 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id JAA01195; Tue, 20 May 1997 09:09:19 -0700 (PDT) Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma864144558.001186; Tue May 20 09:09:18 1997 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id MAA08952; Tue, 20 May 1997 12:09:17 -0400 Date: Tue, 20 May 1997 12:09:17 -0400 From: "C. Kumar" Message-Id: <199705201609.MAA08952@hot> To: ibis@vhdl.org, sjpeters@ichips.intel.com Subject: Re: Question on BIRD42.1 intent X-Sun-Charset: US-ASCII the inclusion of currents should give you more accurate info on turn on and turn off. It also is necessary for more accurate modelling of ground bounce. > From owner-ibis@server.vhdl.org Tue May 20 11:53 EDT 1997 > Received-Date: Tue, 20 May 1997 11:53:54 -0400 > To: ibis@vhdl.org > Subject: Question on BIRD42.1 intent > From: Stephen Peters > Content-Type: text > Content-Length: 778 > X-Lines: 25 > > > Hello All: > > I've been following the discussion on > including the power and ground current 'waveforms' > in the IBIS file, and I have a question. I > thought (based on the original phone discussion > at the last IBIS teleconference) that the purpose > of including the power and ground current info > was to make it eaiser to model the turnon/turnoff > charactoristics of a driver -- NOT to enable better > ground bounce simulations (although I realize that > this info does help). What, exactly, is the intent > of including this info? Should the bird include > some words stating that the power supply waveforms > may not give a complete picture of ground bounce? > Should it not say anything? Just wondering..... > > > > Regards, > Stephen Peters > Intel Corp. > > > From owner-ibis Wed May 21 10:05:49 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA22318 for ; Wed, 21 May 1997 10:05:48 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id KAA02606 for ; Wed, 21 May 1997 10:04:29 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma001973; Wed, 21 May 97 10:03:44 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA05570 for ibis@vhdl.org; Wed, 21 May 97 10:04:00 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA10411; Wed, 21 May 97 10:07:48 PDT Date: Wed, 21 May 97 10:07:48 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9705211707.AA10411@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS at DAC Hi, If you are still planning to present a paper at the IBIS summit at DAC, pls forward a topic name and amount of time you need as soon as possible. We are trying to finalise an agenda by next week's telconf. Best Regards, Syed. National Semiconductor Corp. From owner-ibis Thu May 22 16:03:49 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id QAA20722 for ; Thu, 22 May 1997 16:03:42 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 22 May 97 16:02 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 22 May 97 16:02 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 22 May 97 16:02 PDT Message-Id: Date: Thu, 22 May 97 16:02 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.5 MODELLING SERIES SWITCHABLE DEVICES John Fitzpatrick and IBIS Committee: BIRD41.5 is issued after doing some more experimental work with MOSFET and bus switch simulations. I found that an idea embedded in BIRDs 41.1 through 41.4 involving two or more tables and quadratic fitting did no yield any improvement, and more often was a source of other problems. With more accurate table data, the linear fits provide very good correlation with the Spice models. So the major change is to simplify the proposal. Also the measurement setup for getting sweep information is modified. Best Regards, Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.5 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: 2/12/97, 2/17/9797, 5/14/97, 5/15/97, 5/16/97, 5/22/97 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type values are allowed under the [Model] keyword: Series, Series_Switch Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described in the [Series Switch Groups]. | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the Function Table Group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 On 1 2 4 On 1 3 4 On 2 3 4 | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Usage Rules: Entries follow these rules: Only series pin pairs | are entered. The Pin 1 column contains the pin number for | which input impedances are measured. The Pin 2 column contains | the pin name of the other end of the series device. The | Model_name column names of the model corresponding to the | Series or Series_switch device. | | The Function Table Group column contains an alphanumeric | designator string to associate those sets of Series_switch | pins which are switched together. One possible application | is to model crossbar switches where the straight through | On switches are indicated by one designator and the cross over | paths are indicated by another designator. If the model | referenced is a Series model, then the Function Table | Group entry is required, but ignored. | | Column length limits are: | Pin 1 5 characters max | Pin 2 5 characters max | Model_name 20 characters max | Function Table Group 20 characters max | | Other Notes: If the Model_name is for a non-symmetrical series device, | then the order of the pins is important. Pin 1 and Pin 2 | must be consistent with the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any additonal elements such as additonal | capacitance or clamping circuitry are defined by the Model_name | that is referenced in the [Pin] keyword. Series_switch and | Series pins listed under Pin 1 and Pin 2 must be also be | listed under the [Pin] keyword and the Model_names under the | [Pin] keyword must be for either Terminator Model_types or | 'NC'. Thus a Series_switch model may contain Terminator models | on EACH of the pins to describe both the capacitance on each | pin and some clamping circuitry that may exist on pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] | Pin 1 Pin 2 Model_name Function Table Group | 2 3 CBTSeries 1 | Four Independent Groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight Through Path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross Over Path 25 23 CBTSeries 6 Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R_series], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R_series], [L_series], [R_l_series], | [C_series], [L_c_series], [R_c_series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The | three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | [R_l_series] is 0 ohms if it is not defined in the path. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. [R_c_series] is 0 ohms if it is not | defined in the path. [L_c_series is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However | the model supplier should realise that it may | not be possible to derive a behavioral model | from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings itself provide the assumed gate | voltages. If the [POWER Clamp Reference] exists, it overrides | the [Voltage Range] value. The table entries are actually | the Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be view as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) that is used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | The model data is used to approximate the On state relationship | between Ids, Vds for a given Vgs: Ids = f(Vds) for a given Vgs. | This relationship is used as a series element to solve for the | voltages on each side of the switch during analysis. | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be Ids = (Itable) * Vds / Vgs. In practice, this serves | as a reasonably accurate approximation.. | | If more than one [Series MOSFET] tables are supplied, it is | simulator dependent who the data will be used. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the [Model Selector] keyword associated with approved BIRD30.2, change the first paragraph of 'Usage Rules:' as follows so that each occurance of "[Pin] keyword" is changed to "[Pin] or [Series Pin Mapping] keywords": | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keywords | and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] or [Series Pin Mapping] keywords. | In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | | +----------------------------------------+ | | | | | Ids = Table Current | | | ---> | | +---<---| |--->----------+ | | d |_____| - s | + | | --+-- Vgs +---+---+ +----+----+ | | g + | Sweep | | Vs + | | | Vs | |Fixed Vds| | +---+---+ +----+----+ | | - | | GND GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS 41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C_series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. BIRD41.4: John Fitzpatrick suggested in a private note that models that can be attached to Series or Series_switch models under the [Pin] table be Terminator models. Text is put in Other Notes under [Series Pin Mapping] stating this restriction (and also including 'NC'). It is a complication to allow Input or I/O models, and if the pin is connected to a power rail, this can be done in a simulator dependent manner. John also suggested expanding approved BIRD30.2 to include [Series Pin Mapping] models to be included in the [Model Selector] keyword. This could be used for selecting Series_switch models for Vcc = 5 V or Vcc = 4.3 V when used in 3.3 to 5 V logic interface applications. An additional modification is included to make this change. It makes sense to capture within [Model Selector] all of the Model_names that can be selected. The [Series Pin Mapping] keyword defines new models that are not listed under the [Pin] keyword. BIRD41.5: References to quadradic fitting for [Series MOSFET} based on two tables are removed because the algorithms did not yield significant improvement and usually caused other problems. Also there was some extreme data sensitivity issues when the data was near zero mA which would cause much additional complexity. The linear algorithm provided good correlation when more data points were taken. The table extraction circuit is modified so that current through the device is sensed on the source side so that a leakage current to the substrate does not cause non-monotonic increasing values for higher source voltages. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments 41.4 Submitted May 16, 1997 - [Pin] model Terminator or NC restriction for series pins - [Model Selector] keyword addition to include [Series Pin Mapping] models. 41.5 Submitted May 22, 1997 - Removed references to Quadradric fitting for [Series MOSFET] table - Changed VI extraction setup to prevent non-monotonic currents From owner-ibis Thu May 22 16:07:44 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id QAA20774 for ; Thu, 22 May 1997 16:07:41 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Thu, 22 May 97 16:06 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 22 May 97 16:06 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Thu, 22 May 97 16:06 PDT Message-Id: Date: Thu, 22 May 97 16:06 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.5 SPICE TEST NETLIST To IBIS Committee: Here is a revised HSPICE netlist regarding BIRD41.5 which compares a linear, table driven model with series MOSFET device. The correlation is excellent since the table contains more data points. The [Series MOSFET] tables are now Vcc relative, reversed polarity voltage per BIRD41.5. Changing the V199 Power value shifts both the Vs voltage, and the simulation tables track this shift. The intent is to compare performance of the MOSFET model (nodes 1 and 3) and the Behavioral model (nodes 11 and 13) for a given set of test loads including open transmission lines and for various pulse amplitudes. The main idea tested here is whether a series model can be derived from IV characteristics of a device. The models below are based on a turned on device with Vgate = 5 V. The IV tables are Ids through the device as a function of Vs, with Vds = (.5V, 1V and 2V). The "linear" model assumes a linear functional relationship between Ids and Vds. Best Regards, Bob Ross Interconnectix * TEST CASE FOR SERIES SWITCH MOS MODEL USING NMOSFET ONLY * 1 3 * | | * ____________ * o---/¥/¥/¥---o o-----O____________)---o Open * 10 ohms |___| TD = 0.5 nS * | Z0 = 50 ohms * Vcc * Vh /----¥ * / ¥ * 0 --/ ¥----- 0.1ns Rise and Fall * * * * Vds = Vd - Vs is used to change the sign of the current * if Vs > Vd * * Is * D ---> S * 11 o---o--/¥/¥/¥--o---o 13 * _|_ _|_ * C11 ___ ___ C13 * | | * GND GND * * * *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 0.5 V * .SUBCKT SER5 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 0 + 8.0000e-01 0 + 9.0000e-01 1.433e-04 + 1.0000e+00 1.116e-03 + 1.1000e+00 2.698e-03 + 1.2000e+00 4.548e-03 + 1.3000e+00 6.117e-03 + 1.4000e+00 7.862e-03 + 1.5000e+00 1.037e-02 + 1.6000e+00 1.288e-02 + 1.7000e+00 1.540e-02 + 1.8000e+00 1.792e-02 + 1.9000e+00 2.045e-02 + 2.0000e+00 2.297e-02 + 2.1000e+00 2.551e-02 + 2.2000e+00 2.804e-02 + 2.3000e+00 3.059e-02 + 2.4000e+00 3.313e-02 + 2.5000e+00 3.568e-02 + 2.6000e+00 3.824e-02 + 2.7000e+00 4.080e-02 + 2.8000e+00 4.337e-02 + 2.9000e+00 4.594e-02 + 3.0000e+00 4.852e-02 + 3.1000e+00 5.111e-02 + 3.2000e+00 5.370e-02 + 3.3000e+00 5.631e-02 + 3.4000e+00 5.892e-02 + 3.5000e+00 6.153e-02 + 3.6000e+00 6.416e-02 + 3.7000e+00 6.680e-02 + 3.8000e+00 6.945e-02 + 3.9000e+00 7.211e-02 + 4.0000e+00 7.478e-02 + 4.1000e+00 7.747e-02 + 4.2000e+00 8.017e-02 + 4.3000e+00 8.288e-02 + 4.4000e+00 8.562e-02 + 4.5000e+00 8.838e-02 + 4.6000e+00 9.116e-02 + 4.7000e+00 9.396e-02 + 4.8000e+00 9.680e-02 + 4.9000e+00 9.967e-02 + 5.0000e+00 1.026e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 1 V * .SUBCKT SER1 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 0 + 8.0000e-01 0 + 9.0000e-01 2.086e-04 + 1.0000e+00 1.744e-03 + 1.1000e+00 4.520e-03 + 1.2000e+00 8.191e-03 + 1.3000e+00 1.235e-02 + 1.4000e+00 1.648e-02 + 1.5000e+00 2.016e-02 + 1.6000e+00 2.337e-02 * + 1.7000e+00 2.566e-02 Non-Monotonic Point + 1.8000e+00 2.397e-02 + 1.9000e+00 2.900e-02 + 2.0000e+00 3.405e-02 + 2.1000e+00 3.910e-02 + 2.2000e+00 4.417e-02 + 2.3000e+00 4.924e-02 + 2.4000e+00 5.432e-02 + 2.5000e+00 5.940e-02 + 2.6000e+00 6.450e-02 + 2.7000e+00 6.961e-02 + 2.8000e+00 7.473e-02 + 2.9000e+00 7.986e-02 + 3.0000e+00 8.501e-02 + 3.1000e+00 9.016e-02 + 3.2000e+00 9.533e-02 + 3.3000e+00 1.005e-01 + 3.4000e+00 1.057e-01 + 3.5000e+00 1.109e-01 + 3.6000e+00 1.161e-01 + 3.7000e+00 1.214e-01 + 3.8000e+00 1.267e-01 + 3.9000e+00 1.319e-01 + 4.0000e+00 1.373e-01 + 4.1000e+00 1.426e-01 + 4.2000e+00 1.479e-01 + 4.3000e+00 1.533e-01 + 4.4000e+00 1.587e-01 + 4.5000e+00 1.642e-01 + 4.6000e+00 1.697e-01 + 4.7000e+00 1.752e-01 + 4.8000e+00 1.808e-01 + 4.9000e+00 1.864e-01 + 5.0000e+00 1.920e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 2 V * .SUBCKT SER2 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 + 0. 0 + 8.0000e-01 0 + 9.0000e-01 2.991e-04 + 1.0000e+00 2.581e-03 + 1.1000e+00 6.944e-03 + 1.2000e+00 1.318e-02 + 1.3000e+00 2.107e-02 + 1.4000e+00 3.036e-02 + 1.5000e+00 4.080e-02 + 1.6000e+00 5.211e-02 + 1.7000e+00 6.397e-02 + 1.8000e+00 7.601e-02 + 1.9000e+00 8.784e-02 + 2.0000e+00 9.897e-02 + 2.1000e+00 1.089e-01 + 2.2000e+00 1.168e-01 + 2.3000e+00 1.218e-01 + 2.4000e+00 1.228e-01 + 2.5000e+00 1.217e-01 + 2.6000e+00 1.186e-01 + 2.7000e+00 1.107e-01 + 2.8000e+00 1.014e-01 + 2.9000e+00 1.116e-01 + 3.0000e+00 1.218e-01 + 3.1000e+00 1.321e-01 + 3.2000e+00 1.423e-01 + 3.3000e+00 1.526e-01 + 3.4000e+00 1.629e-01 + 3.5000e+00 1.732e-01 + 3.6000e+00 1.836e-01 + 3.7000e+00 1.940e-01 + 3.8000e+00 2.044e-01 + 3.9000e+00 2.148e-01 + 4.0000e+00 2.253e-01 + 4.1000e+00 2.358e-01 + 4.2000e+00 2.463e-01 + 4.3000e+00 2.569e-01 + 4.4000e+00 2.675e-01 + 4.5000e+00 2.781e-01 + 4.6000e+00 2.888e-01 + 4.7000e+00 2.995e-01 + 4.8000e+00 3.102e-01 + 4.9000e+00 3.208e-01 + 5.0000e+00 3.315e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF DIODE * .SUBCKT DIODE 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 PWL(1) 1 100 +-2.0000e+00 -6.158e+17 +-1.9000e+00 -1.697e+16 +-1.8000e+00 -4.679e+14 +-1.7000e+00 -1.290e+13 +-1.6000e+00 -3.556e+11 +-1.5000e+00 -9.802e+09 +-1.4000e+00 -2.702e+08 +-1.3000e+00 -7.449e+06 +-1.2000e+00 -2.053e+05 +-1.1000e+00 -5.660e+03 +-1.0000e+00 -1.560e+02 +-9.0000e-01 -4.308e+00 +-8.0000e-01 -1.221e-01 +-7.0000e-01 -4.315e-03 +-6.0000e-01 -1.715e-04 +-5.0000e-01 -4.959e-06 +-4.0000e-01 -1.373e-07 +-3.0000e-01 -4.075e-09 +-2.0000e-01 -3.044e-10 +-1.0000e-01 -1.030e-10 + 0. 0 + 5 0 .ENDS *-------------------------------------------------------------------------- * POWER AND GND V100 100 0 0 V199 199 100 5 *************************************************************************** * MOSFET FOR 1-3 CONNECTION USED FOR REF. V95 5 199 0 MOS 1 5 3 100 NMOSFET W=1440U L=0.64U * ADDITIONAL EFFECTIVE CAPACITANCE IN ACTUAL SWITCH MODEL * C1 1 100 6P * C3 3 100 6P .OPTIONS TNOM=40.00 .MODEL NMOSFET NMOS LEVEL=3 * SOURCE AND LOAD FOR EDITING R1 91 1 10 * R3 3 100 50G TL 3 100 9 100 Z0=50 TD=0.5N R9 9 100 1G *************************************************************************** * TABLE DRIVEN MODEL SIMULATION WITH 11-13 CONNECTION * DRAIN TO SOURCE VOLTAGE (SIGN CONTROLS CURRENT FLOW DIRECTION) EDS 34 100 VOLT='V(11)-V(13)' RDS 34 100 1G * MIN OF SOURCE OR DRAIN BECOMES "Vs" EMIN 38 100 VOLT='MIN(V(11), V(13))' RMIN 38 100 1G EREL 39 100 VOLT='V(199)-V(38)' * I1(Vs) X1 39 100 35 SER1 V1 100 35 0 * I2(Vs) X2 39 100 36 SER2 V2 100 36 0 * I5(Vs) X5 39 100 37 SER5 V5 100 37 0 * SELECT G5LIN, G1LIN, OR G2LIN: *** Using Vds = 0.5 V Linear Approximation G5LIN 11 13 CUR='V(34)*I(V5)*2' *** Using Vds = 1 V Linear Approximation * G1LIN 11 13 CUR='V(34)*I(V1)' *** Using Vds = 2 V Linear Approximation * G2LIN 11 13 CUR='V(34)*I(V2)/2' * INPUT AND OUTPUT CAPACITANCE WHICH MATCHES SPICE MODEL * C11 11 100 6P * C13 13 100 6P * DRAIN/SOURCE TO SUBSTRATE PATHS (FROM MOSFET EXTRACTION) XDIODE1 11 100 11 DIODE XDIODE2 13 100 13 DIODE * MODEL SOURCE AND LOAD FOR EDITING R11 91 11 10 * R13 13 100 50G TL1 13 100 19 100 Z0=50 TD=.5N R19 19 100 1G *************************************************************************** * COMMON INPUT PULSE VIN 91 100 PULSE 0 5 0 .1N .1N 2N 4N .TEMP 50. .TRAN .1N 4N 0 .01N .PRINT TRAN V(1) V(11) V(3) V(13) .OPTIONS POST INGOLD=2 .END From owner-ibis Fri May 23 00:25:33 1997 Received: from eux100 ([164.129.225.7]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA27982; Fri, 23 May 1997 00:25:31 -0700 (PDT) From: Peter.HIRT@st.com Received: from by eux100 with SMTP (1.40.112.8/16.2) id AA022852293; Fri, 23 May 1997 09:24:53 +0200 X-Openmail-Hops: 2 Date: Fri, 23 May 97 09:26:43 +0200 Message-Id: Subject: un_subscribe Mime-Version: 1.0 To: ibis@vhdl.org, ibis-request@vhdl.org Content-Type: text/plain; charset=US-ASCII; name="Text" Content-Transfer-Encoding: 7bit please un_subsribe me from the IBIS mail reflector thank you Peter Hirt SGS-Thomson Microelectronics From owner-ibis Fri May 23 07:26:06 1997 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA04814 for ; Fri, 23 May 1997 07:26:06 -0700 (PDT) Received: from pyrodactyl.or.pyramid.com by gossip.pyramid.com (8.6.13/OSx5.1a Pyramid-Internet-Gateway) id HAA27250; Fri, 23 May 1997 07:24:48 -0700 Received: by pyrodactyl.or.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id HAA10971; Fri, 23 May 1997 07:24:52 -0700 From: jmoll@pyramid.com (Jeff Moll) Message-Id: <199705231424.HAA10971@pyrodactyl.or.pyramid.com> Subject: unsubscribe To: ibis@vhdl.org Date: Fri, 23 May 1997 07:24:52 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit unsubcribe -- Jeffery L. Moll email: jmoll@pyramid.com Senior Member Technical Staff Siemens Pyramid Information Systems (503) 690-6208 15400 NW Greenbrier Pkwy Suite 200 Fax: (503) 690-7704 Beaverton OR 97006-5783 From owner-ibis Fri May 23 12:34:17 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA10031 for ; Fri, 23 May 1997 12:34:16 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 23 May 97 12:33 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 23 May 97 12:33 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 23 May 97 12:33 PDT Message-Id: Date: Fri, 23 May 97 12:33 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING AGENDA 5/30/97 IBIS Open Forum Meeting Agenda for 5/30/97 Bridge Number Reservation # Passcode (916) 356-9200 1-137662 1259125 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions DAC97 IBIS Meeting Planning Agenda Huq International Progress Rusher/Ross IBISCHK2+ Fix Rokusek Cookbook Rokusek/Peters s2ibis2 Issues (& NT) Dodd New Administrative Issues All 8:50 Technical Discussion BIRD41.5 - MODELING SERIES SWITCHABLE DEVICES Fitzpatrick BIRD42.1 - MODELING CURRENT WAVEFORMS Kumar Connector Status Peters Switched Terminators Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri May 23 16:11:52 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id QAA13911 for ; Fri, 23 May 1997 16:11:51 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 23 May 97 16:11 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 23 May 97 16:10 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 23 May 97 16:10 PDT Message-Id: Date: Fri, 23 May 97 16:10 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD43 COMPONENT TEST POINT SUBPARAMETERS To IBIS Committee: BIRD43 specifies the measurement location of Signal Integrity and Timing measurements for the Component. Historically, the measurement location has been ASSUMED to be at the external Pin location. However, some ASIC buffers and other parts have their specification at the Die since the package information can be a big variable. BIRD43 adds two optional subparameters to [Component] so that the signal integrity and timing specifications can applied at the intended location. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 43 ISSUE TITLE: Component Test Point Subparameters REQUESTER: Bob Ross, Interconnectix DATE SUBMITTED: May 23, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Signal Integrity and Timing measurement locations have been assumed to be at the external pin location of the part where physical measurements are available. Some parts, such as ASICs specify these parameters for the Die itself. So the measurement locations need to be stated to be consistent with the specified data. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Add to the [Component] keyword two optional subparameters 'Si_location' and 'Timing_location' as shown by the |* lines. |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. |* Sub-Params: Si_location, Timing_location | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. | | NOTE: Blank characters are not recommended due to usability | issues. | |* Si_location and Timing_location are optional and specify |* where the Signal Integity and Timing measurements are made |* for the component. The default location is at the 'Pin'. |* However, the 'Die' location is also available for either or |* and both subparameters. |* |------------------------------------------------------------------------------ [Component] 7403398 MC452 | Si_location Pin | Optional subparameters to give measurement Timing_locaton Die | location positions | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The Threshold values Vinl and Vinh and the timing test load values based on Vmeas, Rref, Cref, and Vref have historically been ASSUMED to be at the Pin location of the part because these are associated with external, measureable specifications. Some ASICs specify these parameters at the die. Therefore, optional subparameters to [Component] are proposed to provide this specification flexability so that the measurement location is consistent with the source data. The easiest way is to include this detail on a Component-wide basis so that simulators can detect automatically where measurements are to be taken. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: From owner-ibis Fri May 23 20:15:13 1997 Received: from pimaia4w.prodigy.com (pimaia4w.prodigy.com [198.83.18.139]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id UAA18042 for ; Fri, 23 May 1997 20:15:12 -0700 (PDT) Received: from mime4.prodigy.com (mime4.prodigy.com [192.168.254.43]) by pimaia4w.prodigy.com (8.8.5/8.8.5) with ESMTP id XAA32698 for ; Fri, 23 May 1997 23:14:18 -0400 Received: (from root@localhost) by mime4.prodigy.com (8.6.10/8.6.9) id XAA60164 for ibis@vhdl.org; Fri, 23 May 1997 23:12:00 -0400 Message-Id: <199705240312.XAA60164@mime4.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae02dm02sc06 From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Fri, 23 May 1997 23:12:00, -0500 To: ibis@vhdl.org Subject: Unsubscribe MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii -- [ From: Ron Christopher * EMC.Ver #2.5.3 ] -- Unsubscribe From owner-ibis Wed May 28 11:08:18 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA07276 for ; Wed, 28 May 1997 11:08:05 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Wed, 28 May 97 11:07 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 28 May 97 11:06 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 28 May 97 11:06 PDT Message-Id: Date: Wed, 28 May 97 11:06 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, john.fitzpatrick@ln.cit.alcatel.fr Subject: IBIS BIRD41.6 Modelling Series Switchable Devices John Fitzpatrick and IBIS Committee: BIRD41.6 is a refinement of BIRD41.5. Its major change is to modify the syntax of [Series Pin Mapping] so that the columns are defined by subparameter names. This is done to make the [Series Pin Mapping] keyword syntax consistent with the [Pin], [Pin Mapping] and [Diff Pin] keywords. Other text is changed throughout to be consistent with this change. Also editorial changes and corrections are made. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.6 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: 2/12/97, 2/17/9797, 5/14/97, 5/15/97, 5/16/97, 5/22/97, 5/28/97 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type values are allowed under the [Model] keyword: Series, Series_switch Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described using the names of the groups in the | [Series Pin Mapping] keyword function_table_group column | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the function_table_group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 / On 1 2 4 / On 1 3 4 / On 2 3 4 / | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | On 5 / | Cross over Switch Straight thru connection On 6 / | Cross over connection Off 5 6 / | No connections | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Sub-Params: pin_2, model_name, function_table_group | Usage Rules: Enter only series pin pairs. The first column, [Series Pin | Mapping], contains the series pin for which input impedances | are measured. The second column, pin_2, contains the other | connection of the series model. Each pin must match the | pin numbers declared previously in the [Pin] section of the | IBIS file. The third column, model_name, associates the | Series or Series_switch model for the pair of pins in the | first two columns. The fourth column, function_table_group, | contains an alphanumeric designator string to associate those | sets of of Series_switch pins that are switched together. | | Each line must contain either three or four columns. When | using four columns, the header function_table_group must be | listed. | | One possible application is to model crossbar switches where | the straight through On paths are indicated by one designator | and the cross over On paths are indicated by another | designator. If the model referenced is a Series model, then | the function_table_group entry is omitted. | | Column length limits are: | [Series Pin Mapping] 5 characters max | pin_2 5 characters max | model_name 20 characters max | function_table_group 20 characters max | | Other Notes: If the model_name is for a non-symmetrical series device, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword must be either 'NC' or | reference a [Model] whose Model_type is 'Terminator'. Thus. | for example, a Series_switch model may contain Terminator | models on EACH of the pins to describe both the capacitance | on each pin and some clamping circuitry that may exist on | each pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] pin_2 model_name function_table_group | 2 3 CBTSeries 1 | Four independent groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight through path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross over path 25 23 CBTSeries 6 | 32 33 Fixed_series | No group needed Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R_series], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R_series], [L_series], [R_l_series], | [C_series], [L_c_series], [R_c_series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the typical, | minimum, and maximum resistance values. The three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | [R_l_series] is 0 ohms if it is not defined in the path. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. [R_c_series] is 0 ohms if it is not | defined in the path. [L_c_series is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | columns [Series Pin Mapping] and pin_2, respectively. Three | Usage Rules: The first column contains the voltage value, and the | 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: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | [Series Pin Mapping] and pin_2 columns, respectively. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings itself provide the assumed gate | voltages. If the [POWER Clamp Reference] exists, it overrides | the [Voltage Range] value. The table entries are actually | the Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be view as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) that is used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | The model data is used to approximate the On state relationship | between Ids, Vds for a given Vgs: Ids = f(Vds) for a given Vgs. | This relationship is used as a series element to solve for the | voltages on each side of the switch during analysis. | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be Ids = (Itable) * Vds / Vgs. In practice, this serves | as a reasonably accurate approximation.. | | If more than one [Series MOSFET] tables are supplied, it is | simulator dependent how the data will be used. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the [Model Selector] keyword associated with approved BIRD30.2, change the first paragraph of 'Usage Rules:' as follows so that each occurance of "[Pin] keyword" is changed to "[Pin] or [Series Pin Mapping] keywords": | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keywords | and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] or [Series Pin Mapping] keywords. | In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD, section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | | +----------------------------------------+ | | | | | Ids = Table Current | | | ---> | | +---<---| |--->----------+ | | d |_____| - s | + | | --+-- Vgs +---+---+ +----+----+ | | g + | Sweep | | Vs + | | | Vs | |Fixed Vds| | +---+---+ +----+----+ | | - | | GND GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS 41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C_series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. BIRD41.4: John Fitzpatrick suggested in a private note that models that can be attached to Series or Series_switch models under the [Pin] table be Terminator models. Text is put in Other Notes under [Series Pin Mapping] stating this restriction (and also including 'NC'). It is a complication to allow Input or I/O models, and if the pin is connected to a power rail, this can be done in a simulator dependent manner. John also suggested expanding approved BIRD30.2 to include [Series Pin Mapping] models to be included in the [Model Selector] keyword. This could be used for selecting Series_switch models for Vcc = 5 V or Vcc = 4.3 V when used in 3.3 to 5 V logic interface applications. An additional modification is included to make this change. It makes sense to capture within [Model Selector] all of the Model_names that can be selected. The [Series Pin Mapping] keyword defines new models that are not listed under the [Pin] keyword. BIRD41.5: References to quadradic fitting for [Series MOSFET} based on two tables are removed because the algorithms did not yield significant improvement and usually caused other problems. Also there was some extreme data sensitivity issues when the data was near zero mA which would cause much additional complexity. The linear algorithm provided good correlation when more data points were taken. The table extraction circuit is modified so that current through the device is sensed on the source side so that a leakage current to the substrate does not cause non-monotonic increasing values for higher source voltages. BIRD41.6: [Series Pin Mapping] syntax is revised to define the columns in terms of subparameters. This is consistent with the [Pin], [Pin Mapping] and [Diff Pin] keywords. It also allows entering only three columns for Series models and four columns for Series_switch models. All of the other keywords allow two selections for number of columns. Parser development effort should be reduced by maintaining consistency with other similarly formatted keywords. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments 41.4 Submitted May 16, 1997 - [Pin] model Terminator or NC restriction for series pins - [Model Selector] keyword addition to include [Series Pin Mapping] models. 41.5 Submitted May 22, 1997 - Removed references to Quadradric fitting for [Series MOSFET] table - Changed VI extraction setup to prevent non-monotonic currents 41.6 Submitted May 28, 1997 - Changed [Series Pin Mapping] syntax to conform with [Pin], [Pin Mapping] and [Diff Pin] syntax by including column headings as subparameters. - Added to [Series Switch Groups] the example for Bus Switch in the [Series Pin Mapping] keyword - Made other miscellaneous editorial changes for consistency. From owner-ibis Wed May 28 11:12:35 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA07310 for ; Wed, 28 May 1997 11:12:33 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Wed, 28 May 97 11:11 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 28 May 97 11:11 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Wed, 28 May 97 11:11 PDT Message-Id: Date: Wed, 28 May 97 11:11 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, john.fitzpatrick@ln.cit.alcatel.fr Subject: IBIS BIRD41.6 Series Switch Test Circuit To IBIS Committee: Below is a PSpice version of the Series Switch Model test circuit sent out previously. Bob Ross Interconnectix * TEST CASE FOR SERIES SWITCH MOS MODEL USING NMOSFET ONLY * 1 3 * | | * ____________ * o---/¥/¥/¥---o o-----O____________)---o Open * 10 ohms |___| TD = 0.5 nS * | Z0 = 50 ohms * Vcc * Vh /----¥ * / ¥ * 0 --/ ¥----- 0.1ns Rise and Fall * * * * Vds = Vd - Vs is used to change the sign of the current * if Vs > Vd * * Is * D ---> S * 11 o---o--/¥/¥/¥--o---o 13 * _|_ _|_ * C11 ___ ___ C13 * | | * GND GND * * * *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 0.5 V * .SUBCKT SER5 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 TABLE {V(1)-V(100)} = + 0. 0 + 8.0000e-01 0 + 9.0000e-01 1.433e-04 + 1.0000e+00 1.116e-03 + 1.1000e+00 2.698e-03 + 1.2000e+00 4.548e-03 + 1.3000e+00 6.117e-03 + 1.4000e+00 7.862e-03 + 1.5000e+00 1.037e-02 + 1.6000e+00 1.288e-02 + 1.7000e+00 1.540e-02 + 1.8000e+00 1.792e-02 + 1.9000e+00 2.045e-02 + 2.0000e+00 2.297e-02 + 2.1000e+00 2.551e-02 + 2.2000e+00 2.804e-02 + 2.3000e+00 3.059e-02 + 2.4000e+00 3.313e-02 + 2.5000e+00 3.568e-02 + 2.6000e+00 3.824e-02 + 2.7000e+00 4.080e-02 + 2.8000e+00 4.337e-02 + 2.9000e+00 4.594e-02 + 3.0000e+00 4.852e-02 + 3.1000e+00 5.111e-02 + 3.2000e+00 5.370e-02 + 3.3000e+00 5.631e-02 + 3.4000e+00 5.892e-02 + 3.5000e+00 6.153e-02 + 3.6000e+00 6.416e-02 + 3.7000e+00 6.680e-02 + 3.8000e+00 6.945e-02 + 3.9000e+00 7.211e-02 + 4.0000e+00 7.478e-02 + 4.1000e+00 7.747e-02 + 4.2000e+00 8.017e-02 + 4.3000e+00 8.288e-02 + 4.4000e+00 8.562e-02 + 4.5000e+00 8.838e-02 + 4.6000e+00 9.116e-02 + 4.7000e+00 9.396e-02 + 4.8000e+00 9.680e-02 + 4.9000e+00 9.967e-02 + 5.0000e+00 1.026e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 1 V * .SUBCKT SER1 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 TABLE {V(1)-V(100)} = + 0. 0 + 8.0000e-01 0 + 9.0000e-01 2.086e-04 + 1.0000e+00 1.744e-03 + 1.1000e+00 4.520e-03 + 1.2000e+00 8.191e-03 + 1.3000e+00 1.235e-02 + 1.4000e+00 1.648e-02 + 1.5000e+00 2.016e-02 + 1.6000e+00 2.337e-02 * + 1.7000e+00 2.566e-02 Non-Monotonic Point + 1.8000e+00 2.397e-02 + 1.9000e+00 2.900e-02 + 2.0000e+00 3.405e-02 + 2.1000e+00 3.910e-02 + 2.2000e+00 4.417e-02 + 2.3000e+00 4.924e-02 + 2.4000e+00 5.432e-02 + 2.5000e+00 5.940e-02 + 2.6000e+00 6.450e-02 + 2.7000e+00 6.961e-02 + 2.8000e+00 7.473e-02 + 2.9000e+00 7.986e-02 + 3.0000e+00 8.501e-02 + 3.1000e+00 9.016e-02 + 3.2000e+00 9.533e-02 + 3.3000e+00 1.005e-01 + 3.4000e+00 1.057e-01 + 3.5000e+00 1.109e-01 + 3.6000e+00 1.161e-01 + 3.7000e+00 1.214e-01 + 3.8000e+00 1.267e-01 + 3.9000e+00 1.319e-01 + 4.0000e+00 1.373e-01 + 4.1000e+00 1.426e-01 + 4.2000e+00 1.479e-01 + 4.3000e+00 1.533e-01 + 4.4000e+00 1.587e-01 + 4.5000e+00 1.642e-01 + 4.6000e+00 1.697e-01 + 4.7000e+00 1.752e-01 + 4.8000e+00 1.808e-01 + 4.9000e+00 1.864e-01 + 5.0000e+00 1.920e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF Ids (2) vs Vs (1) for Vds = 2 V * .SUBCKT SER2 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 TABLE {V(1)-V(100)} = + 0. 0 + 8.0000e-01 0 + 9.0000e-01 2.991e-04 + 1.0000e+00 2.581e-03 + 1.1000e+00 6.944e-03 + 1.2000e+00 1.318e-02 + 1.3000e+00 2.107e-02 + 1.4000e+00 3.036e-02 + 1.5000e+00 4.080e-02 + 1.6000e+00 5.211e-02 + 1.7000e+00 6.397e-02 + 1.8000e+00 7.601e-02 + 1.9000e+00 8.784e-02 + 2.0000e+00 9.897e-02 + 2.1000e+00 1.089e-01 + 2.2000e+00 1.168e-01 + 2.3000e+00 1.218e-01 + 2.4000e+00 1.228e-01 + 2.5000e+00 1.217e-01 + 2.6000e+00 1.186e-01 + 2.7000e+00 1.107e-01 + 2.8000e+00 1.014e-01 + 2.9000e+00 1.116e-01 + 3.0000e+00 1.218e-01 + 3.1000e+00 1.321e-01 + 3.2000e+00 1.423e-01 + 3.3000e+00 1.526e-01 + 3.4000e+00 1.629e-01 + 3.5000e+00 1.732e-01 + 3.6000e+00 1.836e-01 + 3.7000e+00 1.940e-01 + 3.8000e+00 2.044e-01 + 3.9000e+00 2.148e-01 + 4.0000e+00 2.253e-01 + 4.1000e+00 2.358e-01 + 4.2000e+00 2.463e-01 + 4.3000e+00 2.569e-01 + 4.4000e+00 2.675e-01 + 4.5000e+00 2.781e-01 + 4.6000e+00 2.888e-01 + 4.7000e+00 2.995e-01 + 4.8000e+00 3.102e-01 + 4.9000e+00 3.208e-01 + 5.0000e+00 3.315e-01 .ENDS *-------------------------------------------------------------------------- * TABLE OF DIODE * .SUBCKT DIODE 1 100 2 * | | | * | | Current Source Output * | Reference Voltage * Output Sense Voltage *-------------------------------------------------------------------------- GSW 2 100 TABLE {V(1)-V(100)} = +-2.0000e+00 -6.158e+17 +-1.9000e+00 -1.697e+16 +-1.8000e+00 -4.679e+14 +-1.7000e+00 -1.290e+13 +-1.6000e+00 -3.556e+11 +-1.5000e+00 -9.802e+09 +-1.4000e+00 -2.702e+08 +-1.3000e+00 -7.449e+06 +-1.2000e+00 -2.053e+05 +-1.1000e+00 -5.660e+03 +-1.0000e+00 -1.560e+02 +-9.0000e-01 -4.308e+00 +-8.0000e-01 -1.221e-01 +-7.0000e-01 -4.315e-03 +-6.0000e-01 -1.715e-04 +-5.0000e-01 -4.959e-06 +-4.0000e-01 -1.373e-07 +-3.0000e-01 -4.075e-09 +-2.0000e-01 -3.044e-10 +-1.0000e-01 -1.030e-10 + 0. 0 + 5 0 .ENDS *-------------------------------------------------------------------------- * POWER AND GND V100 100 0 0 V199 199 100 5 *************************************************************************** * MOSFET FOR 1-3 CONNECTION USED FOR REF. V95 5 199 0 MOS 1 5 3 100 NMOSFET W=1440U L=0.64U * ADDITIONAL EFFECTIVE CAPACITANCE IN ACTUAL SWITCH MODEL * C1 1 100 6P * C3 3 100 6P .OPTIONS TNOM=40.00 .MODEL NMOSFET NMOS LEVEL=3 * SOURCE AND LOAD FOR EDITING R1 91 1 10 * R3 3 100 50G TL 3 100 9 100 Z0=50 TD=0.5N R9 9 100 1G *************************************************************************** * TABLE DRIVEN MODEL SIMULATION WITH 11-13 CONNECTION * DRAIN TO SOURCE VOLTAGE (SIGN CONTROLS CURRENT FLOW DIRECTION) EDS 34 100 VALUE = {V(11)-V(13)} RDS 34 100 1G * MIN OF SOURCE OR DRAIN BECOMES "Vs" EMIN 38 100 VALUE = {(V(11)+V(13)-ABS(V(34)))/2} RMIN 38 100 1G EREL 39 100 VALUE = {V(199)-V(38)} RREL 39 100 1G * I1(Vs) X1 39 100 35 SER1 V1 100 35 0 * I2(Vs) X2 39 100 36 SER2 V2 100 36 0 * I5(Vs) X5 39 100 37 SER5 V5 100 37 0 * SELECT G5LIN, G1LIN, OR G2LIN: *** Using Vds = 0.5 V Linear Approximation G5LIN 11 13 VALUE = {V(34)*I(V5)*2} *** Using Vds = 1 V Linear Approximation * G1LIN 11 13 VALUE = {V(34)*I(V1)} *** Using Vds = 2 V Linear Approximation * G2LIN 11 13 VALUE = {V(34)*I(V2)/2} * INPUT AND OUTPUT CAPACITANCE WHICH MATCHES SPICE MODEL * C11 11 100 6P * C13 13 100 6P * DRAIN/SOURCE TO SUBSTRATE PATHS (FROM MOSFET EXTRACTION) XDIODE1 11 100 11 DIODE XDIODE2 13 100 13 DIODE * MODEL SOURCE AND LOAD FOR EDITING R11 91 11 10 * R13 13 100 50G TL1 13 100 19 100 Z0=50 TD=.5N R19 19 100 1G *************************************************************************** * COMMON INPUT PULSE VIN 91 100 PULSE 0 5 0 .1N .1N 2N 4N .TEMP 50. .TRAN .1N 4N 0 .01N .PRINT TRAN V(1) V(11) V(3) V(13) .PROBE .END From owner-ibis Wed May 28 19:46:50 1997 Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id TAA16576 for ; Wed, 28 May 1997 19:46:49 -0700 (PDT) Received: from chicago.UUCP by hustle.rahul.net with UUCP id AA19043 (5.67b8/IDA-1.5 for ibis@vhdl.org); Wed, 28 May 1997 19:45:54 -0700 Received: from pcchuck by neomagic.us.com (4.1/SMI-4.1) id AA29270; Wed, 28 May 97 19:37:21 PDT Message-Id: <2.2.32.19970529023717.006fd548@chicago> X-Sender: kluz@chicago X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 19:37:17 -0700 To: ibis@vhdl.org From: Chuck Kluz Subject: IBIS Consultant Wanted Cc: clement@neomagic.com We are looking for an engineer willing to work as a consultant to create IBIS models for our ICs. Work would involve taking IC buffer data and creating IBIS file and verifying using PCB simulation tool which uses IBIS (such as LineSim from HyperLynx). Please contact me if you are interested and available to work on flexible part-time basis. Thanks, CHUCK KLUZ ------------------------------------------------------------------------------ Chuck Kluz email: kluz@neomagic.com Senior Applications Engineer http://www.neomagic.com NeoMagic Corporation phone: (408)988-7020 x239 3260 Jay Street, Santa Clara, CA 95054 fax: (408)988-7032 ------------------- Differentiation Through Integration --------------------- From owner-ibis Fri May 30 07:59:59 1997 Received: from tcemail.indy.tce.com (inet-gw.indy.tce.com [157.254.232.6]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA03226 for ; Fri, 30 May 1997 07:59:58 -0700 (PDT) Received: (from uucp@localhost) by tcemail.indy.tce.com (8.8.4/8.8.3) id JAA06364 for ; Fri, 30 May 1997 09:58:27 -0500 (EST) Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma006356; Fri May 30 09:58:01 1997 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <338EF92C@MSMAIL.INDY.TCE.COM>; Fri, 30 May 97 09:58:36 CST From: Girma Nebiyou To: "'ibis@vhdl.org'" Subject: unsubscribe Date: Fri, 30 May 97 09:56:00 CST Message-ID: <338EF92C@MSMAIL.INDY.TCE.COM> Encoding: 3 TEXT X-Mailer: Microsoft Mail V3.0 please unsubscribe From owner-ibis Fri May 30 11:09:27 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA04000 for ; Fri, 30 May 1997 11:09:26 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA29147 for ; Fri, 30 May 1997 11:07:32 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma028971; Fri, 30 May 97 11:07:22 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07560 for ibis@vhdl.org; Fri, 30 May 97 11:08:22 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA26988; Fri, 30 May 97 11:12:04 PDT Date: Fri, 30 May 97 11:12:04 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9705301812.AA26988@rockie.nsc.com> To: ibis@vhdl.org Subject: Agenda for DAC/IBIS 1997 Summit meeting Cc: huq@rockie.nsc.com Agenda DAC 1997 IBIS Summit ------------------------------------- Place: Anaheim Marriott, Los Angeles Room: Suite# 312 (EIA/IBIS) Date: June12th Thursday(one day) Time: 8:30am - 5pm Time Topic Presentor --------------------------------------------------------------------- 8:30 Continental Breakfast All 9:00 - Sign-In All - Intros of Officers/Attendees Ross/Huq 9:15 IBIS yearly review Bob Ross 9:30 The IBIS experience Hoang Nguyen (Mitsubishi) 9:40 IMIC data Mr.Saburo Hohjo (Hitachi, Japan) 10:00 Break(10mins) - 10:10 Simulator algorithms Bob Ross (Interconnectix) 10:30 EIAJ IC Package Model Dr.Norio Matsui Standardization Activities (Applied Simulation Technology, Ltd., Japan) 11:00 Next generation IBIS Cookbook Stephen Peters (Intel) 11:15 Election of New officers All 12:00 Lunch( to be provided ) All 1:00 Technical discussions: All ---------------------- BIRD41.7: Modeling Series Switchable Devices Series Switch modeling tests Bob Ross (Interconnectix) BIRD42.2: Modeling Current Waveforms BIRD43 : Component Test Point Subparams 2:00 Break(10mins) - IBISv3.0 Ratification discussions All Recap, Action items, Next Meeting 5:00 Meeting adjourned Note: Pls download copies of the BIRDs as hard copies may not be available at the meeting From owner-ibis Fri May 30 17:04:34 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id RAA06768 for ; Fri, 30 May 1997 17:04:11 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Fri, 30 May 97 16:58 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 30 May 97 16:58 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Fri, 30 May 97 16:58 PDT Message-Id: Date: Fri, 30 May 97 16:58 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.7 Modelling Series Switchable Devices IBIS Committee: BIRD41.7 is issued as an editorial refinement of BIRD41.6. It also contains a corrected and more rigorous presentation of the current/voltage functional relationship associated with [Series MOSFET] tables. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.7 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: 2/12/97, 2/17/97, 5/14/97, 5/15/97, 5/16/97, 5/22/97, 5/28/97, 5/30/97 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] Two additional Model_type subparameter values are allowed under the [Model] keyword: Series, Series_switch Two new keywords are defined under [Model] keyword so that the two electrical states of Series_switch models can be described: [On] [Off] Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described using the names of the groups in the | [Series Pin Mapping] keyword function_table_group column | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the function_table_group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 / On 1 2 4 / On 1 3 4 / On 2 3 4 / | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | On 5 / | Crossbar switch straight thru connection On 6 / | Crossbar cross over connection Off 5 6 / | Crossbar open switches | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Sub-Params: pin_2, model_name, function_table_group | Usage Rules: Enter only series pin pairs. The first column, [Series Pin | Mapping], contains the series pin for which input impedances | are measured. The second column, pin_2, contains the other | connection of the series model. Each pin must match the | pin numbers declared previously in the [Pin] section of the | IBIS file. The third column, model_name, associates the | Series or Series_switch model for the pair of pins in the | first two columns. The fourth column, function_table_group, | contains an alphanumeric designator string to associate those | sets of of Series_switch pins that are switched together. | | Each line must contain either three or four columns. When | using four columns, the header function_table_group must be | listed. | | One possible application is to model crossbar switches where | the straight through On paths are indicated by one designator | and the cross over On paths are indicated by another | designator. If the model referenced is a Series model, then | the function_table_group entry is omitted. | | Column length limits are: | [Series Pin Mapping] 5 characters max | pin_2 5 characters max | model_name 20 characters max | function_table_group 20 characters max | | Other Notes: If the model_name is for a non-symmetrical series device, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword must be either 'NC' or | reference a [Model] whose Model_type is 'Terminator'. Thus. | for example, a Series_switch model may contain Terminator | models on EACH of the pins to describe both the capacitance | on each pin and some clamping circuitry that may exist on | each pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] pin_2 model_name function_table_group | 2 3 CBTSeries 1 | Four independent groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight through path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross over path 25 23 CBTSeries 6 | 32 33 Fixed_series | No group needed Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R_series], | [L_series], [R_l_series], [C_series], | [L_c_series], [R_c_series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R_series], [L_series], | [R_l_series], [C_series], [L_c_series], | [R_c_series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R_series], [L_series], [R_l_series], | [C_series], [L_c_series], [R_c_series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R_series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R_series], [Series Current] |============================================================================== | Keywords: [R_series], [L_series], [R_l_series], [C_series]. [L_c_series], | [R_c_series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the typical, | minimum, and maximum resistance values. The three entries 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. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R_series | +---/¥/¥/¥/¥--------------------+ | | | | Pin 1 | L_series R_l_series | Pin 2 | <---+---@@@@@@@@-/¥/¥/¥/¥-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/¥/¥/¥/¥---+ | | | L_c_series R_c_series | C_series | | [R_l_series] shall be defined only if [L_series] exists. | [R_l_series] is 0 ohms if it is not defined in the path. | | [R_c_series] and [L_c_series] shall be defined only if | [C_series] exists. [R_c_series] is 0 ohms if it is not | defined in the path. [L_c_series is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R_series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L_series] 5nH NA NA | variable R(typ) R(min) R(max) [R_l_series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C_series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | columns [Series Pin Mapping] and pin_2, respectively. | Usage Rules: The first column contains the voltage value, and the | 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: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | 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 |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | [Series Pin Mapping] and pin_2 columns, respectively. | Sub-Params: Vds | Usage Rules: 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: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings provide the assumed gate voltages. | If the [POWER Clamp Reference] exists, it overrides the | [Voltage Range] value. The table entries are actually the | Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be viewed as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | The model data is used to create an On state relationship | between the actual drain to source current, ids, and the | actual drain to source voltage, vds: | | ids = f(vds). | | This functional relationship depends on the actual source | voltage Vs and can be expressed in terms of the corresponding | table currents associated with Vs (and expressed as a function | of Vgs). | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be linearly related to the table drain to source current, | Ids, for the given Vds subparameter value and located at the | existing gate to source voltage value Vgs. This table current | is denoted as Ids(Vgs, Vds). The functional relationship | becomes: | | ids = Ids(Vgs, Vds) * vds / Vds. | | More than one [Series MOSFET] table is permitted, but it is | simulator dependent how the data will be used. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the [Model Selector] keyword associated with approved BIRD30.2, change the first paragraph of 'Usage Rules:' as follows so that each occurance of "[Pin] keyword" is changed to "[Pin] or [Series Pin Mapping] keywords": | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keywords | and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] or [Series Pin Mapping] keywords. | In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 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 | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD, section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | | +----------------------------------------+ | | | | | Ids = Table Current | | | ---> | | +---<---| |--->----------+ | | d |_____| - s | + | | --+-- Vgs +---+---+ +----+----+ | | g + | Sweep | | Vs + | | | Vs | |Fixed Vds| | +---+---+ +----+----+ | | - | | GND GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS 41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C_series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. BIRD41.4: John Fitzpatrick suggested in a private note that models that can be attached to Series or Series_switch models under the [Pin] table be Terminator models. Text is put in Other Notes under [Series Pin Mapping] stating this restriction (and also including 'NC'). It is a complication to allow Input or I/O models, and if the pin is connected to a power rail, this can be done in a simulator dependent manner. John also suggested expanding approved BIRD30.2 to include [Series Pin Mapping] models to be included in the [Model Selector] keyword. This could be used for selecting Series_switch models for Vcc = 5 V or Vcc = 4.3 V when used in 3.3 to 5 V logic interface applications. An additional modification is included to make this change. It makes sense to capture within [Model Selector] all of the Model_names that can be selected. The [Series Pin Mapping] keyword defines new models that are not listed under the [Pin] keyword. BIRD41.5: References to quadradic fitting for [Series MOSFET} based on two tables are removed because the algorithms did not yield significant improvement and usually caused other problems. Also there was some extreme data sensitivity issues when the data was near zero mA which would cause much additional complexity. The linear algorithm provided good correlation when more data points were taken. The table extraction circuit is modified so that current through the device is sensed on the source side so that a leakage current to the substrate does not cause non-monotonic increasing values for higher source voltages. BIRD41.6: [Series Pin Mapping] syntax is revised to define the columns in terms of subparameters. This is consistent with the [Pin], [Pin Mapping] and [Diff Pin] keywords. It also allows entering only three columns for Series models and four columns for Series_switch models. All of the other keywords allow two selections for number of columns. Parser development effort should be reduced by maintaining consistency with other similarly formatted keywords. BIRD41.7 The relationship for defining the drain to source current as a function of drain to source voltage was incorrect. A more rigorous explaination is provided in terms of actual ids, vds values and the information from the table. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments 41.4 Submitted May 16, 1997 - [Pin] model Terminator or NC restriction for series pins - [Model Selector] keyword addition to include [Series Pin Mapping] models. 41.5 Submitted May 22, 1997 - Removed references to Quadradric fitting for [Series MOSFET] table - Changed VI extraction setup to prevent non-monotonic currents 41.6 Submitted May 28, 1997 - Changed [Series Pin Mapping] syntax to conform with [Pin], [Pin Mapping] and [Diff Pin] syntax by including column headings as subparameters. - Added to [Series Switch Groups] the example for Bus Switch in the [Series Pin Mapping] keyword - Made other miscellaneous editorial changes for consistency. 41.7 Submitted May 30, 1997 - Corrects and Provides a more rigorous linear functional relationship for using the [Series MOSFET] table data. - Makes minor editorial corrections. From owner-ibis Sat May 31 12:57:52 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA26379 for ; Sat, 31 May 1997 12:57:47 -0700 (PDT) Received: by icx.com (/¥oo/¥ Smail3.1.29.1 #29.2) id ; Sat, 31 May 97 12:56 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Sat, 31 May 97 12:56 PDT Received: by icx.com (/¥==/¥ Smail3.1.28.1 #28.14) id ; Sat, 31 May 97 12:56 PDT Message-Id: Date: Sat, 31 May 97 12:56 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS PENDING VERSION 3.0 DOCUMENTS To IBIS Members: The DRAFT documents for IBIS Version 3.0 have been stored on vhdl.org under /pub/ibis/wip. These documents are available via a browser: http://www.vhdl.org/pub/ibis/wip or via FTP through anonymous login on vhdl.org. The uploaded documents are: ver3_0g.ibs Last revision with APROVED BIRDs ver3_0h.ibs Contains PENDING BIRDs 41.7, 42.2 and 43 ver3_0.ibs Cleaned up Document with PENDING BIRDs for Voting I am not mailing these out because the documents are large. The ver3_0.ibs document is about 55 pages long. We plan to consider the pending BIRDs and the ver3_0.ibs document at the EIA/IBIS Summit meeting on June 12, 1997 for ratification. Please let me know if you spot errors in ver3_0.ibs which can be noted or corrected before the meeting and be included in the ratified document. We plan a more thorough editorial review and revision for consistency as part of the Version 3.1 correction process and associated parser development activity. I will e-mail a copy of ver3_0.ibs to anyone who requests one from me. Best Regards, Bob Ross Interconnectix