From randyh Tue Mar 1 13:12:01 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05979; Tue, 1 Mar 94 13:12:01 PST Date: Tue, 1 Mar 94 13:12:01 PST From: randyh (Randy Harr) Message-Id: <9403012112.AA05979@vhdl.vhdl.org> To: ibis@vhdl.org Subject: Individual bird files These files have been available on the vhdl.org machine since Derrick sent them on 5 February. See the directory pub/ibis/birds. This is contrary to Item #2 in the recent minutes. You can get a list of the current files via email by sending a message to "archive@vhdl.org" with the body: path index pub/ibis/birds To get any particular file, send the following message to the archive server: path send pub/ibis/birds The latest information can always be retrieved from the archive of email messages on the reflector. The current months messages can be retrieved via: path send pub/ibis email.archive and any previous months via: path send pub/ibis email.mmmyy where "mmm" is the three letter month code and "yy" the last two digits of the year. (Note: do not include the brackets <> when substituting your information) Randy Harr randyh@lmc.com From ventham@quantic.mb.ca Fri Mar 4 11:59:51 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26252; Fri, 4 Mar 94 11:59:51 PST Received: by access.mbnet.mb.ca with UUCP id AA16629 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Fri, 4 Mar 1994 13:55:39 -0600 Received: from gauss by quantic.mb.ca (4.1/SMI-4.1) id AA08991; Fri, 4 Mar 94 13:47:33 CST Received: by gauss (4.1/SMI-4.1) id AA05580; Fri, 4 Mar 94 13:47:32 CST From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9403041947.AA05580@gauss> Subject: Re: EGG1.0; specifying the .PKG file To: bracken@valhalla.performance.com Date: Fri, 4 Mar 94 13:47:31 CST Cc: ibis@vhdl.org In-Reply-To: <9402272250.AA05976@valhalla.performance.com>; from "valhalla.performance.com!bracken" at Feb 27, 94 5:50 pm X-Mailer: ELM [version 2.3 PL11] Gentle IBIS folk, I pondered upon Eric's directory quandary purporting to package files and suggest the following. 1) The package file should not be forced to be in the current directory but that should be the first place it is looked for. 2) The next place should be a sub-directory called "packages" (radical eh?). The subdirectory seperation character would be a conditional compilation in the parser dependent on whether it is UNIX or the backward sloping operating system developed by some window dressers. This enables a central directory for packages to be used by the use of links (if the OS supports it). 3) If it is not there then give a polite error to the user. 4) As the packages are likely to be passed via email the package file format will need the file name as part of the syntax along with any other data appropriate from the IBS file header. 5) Also one of our earlier discussions on packages mentioned the fact that although packages have a standard footprint, the chip size inside will vary and therefore affect the wirebond length and thus the package inductances. Therefore one package file for all DIP16s may not necessarily be be suitable, although I would expect it to be close. The question is :- what accuracy does the user want - given what Lynn was saying about IBM's 308 pin packages. Comments anyone? Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ Remember: There are only two ways to develop a bug-free program - and only the third way works. From bracken@valhalla.performance.com Fri Mar 4 12:19:00 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26469; Fri, 4 Mar 94 12:19:00 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA02861; Fri, 4 Mar 94 15:19:13 EST Message-Id: <9403042019.AA02861@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: EGG1.0; specifying the .PKG file In-Reply-To: Your message of "Fri, 04 Mar 94 13:47:31 CST." <9403041947.AA05580@gauss> Date: Fri, 04 Mar 94 15:19:11 -0500 From: bracken@valhalla.performance.com To IBIS folks: Please forgive my unresponsiveness or any bounced e-mail messages. Our router is back up now and hopefully will stay that way for a few days. To Mike Ventham: Could you expand on your Point Number 4 please? It's not clear to me what you're saying. Regarding your point number 2: the conditional compilation would work, but wouldn't this mean that we would then need to have two separate sets of IBIS files, one for Dad's Operating System and the other for Eunuchs? Maybe we should just allow BOTH "\" and "/" as a subdirectory separation character, and forbid the user from employing them as regular characters in file names. (This doesn't sound like it would be too hard a restriction to live by. "\" is often ignored in UNIX shells anyway.) Regarding your point 5: yes, the vendor should beware. That brings up another point. Even if the die sizes are the same, are the locations of the bonding pads on the die necessarily the same from one IC to another? And what if there are some NC's (do they omit the bond wires)? That would alter the RLC matrices. --Eric From ventham@quantic.mb.ca Fri Mar 4 14:29:08 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27770; Fri, 4 Mar 94 14:29:08 PST Received: by access.mbnet.mb.ca with UUCP id AA19671 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Fri, 4 Mar 1994 16:25:39 -0600 Received: from gauss by quantic.mb.ca (4.1/SMI-4.1) id AA10081; Fri, 4 Mar 94 16:24:06 CST Received: by gauss (4.1/SMI-4.1) id AA06246; Fri, 4 Mar 94 16:24:05 CST From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9403042224.AA06246@gauss> Subject: Re: EGG1.0; specifying the .PKG file To: bracken@valhalla.performance.com Date: Fri, 4 Mar 94 16:24:05 CST Cc: ibis@vhdl.org (IBIS Forum) In-Reply-To: <9403042019.AA02861@valhalla.performance.com>; from "bracken@valhalla.performance.com" at Mar 4, 94 3:19 pm X-Mailer: ELM [version 2.3 PL11] Eric, Thanks for your speedy reply > > > Could you expand on your Point Number 4 please? It's not clear > to me what you're saying. > To clarify, if I receive an email of an IBS together of an email of the package file I can use the Keyword: [File name] to know what filename to save the ibis file message as. I therefore also need the equivalent for the package message so that the package file has the right name for the ibs file to reference. The other keywords I think it will need are [IBIS Ver],[File Rev],[Date],[Source],[Notes],[Disclaimer]. > Regarding your point number 2: the conditional compilation would > work, but wouldn't this mean that we would then need to have two > separate sets of IBIS files, one for Dad's Operating System and the > other for Eunuchs? Maybe we should just allow BOTH "\" and "/" as > a subdirectory separation character, and forbid the user from employing > them as regular characters in file names. (This doesn't sound like it > would be too hard a restriction to live by. "\" is often ignored > in UNIX shells anyway.) Actually, I meant that the packages directory is a search path and does not need to be explicitly mentioned in the file, and therefore avoid having any seperation characters, thus getting round the OS issue. This is similar to the include file search in compilers. > > Regarding your point 5: yes, the vendor should beware. That brings > up another point. Even if the die sizes are the same, are the > locations of the bonding pads on the die necessarily the same from one > IC to another? And what if there are some NC's (do they omit the bond > wires)? That would alter the RLC matrices. > Ezacally my point ! > --Eric > > Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ From qdt!sal!jonp@uunet.UU.NET Fri Mar 4 17:18:22 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29054; Fri, 4 Mar 94 17:18:22 PST Received: from uucp6.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwfvp27133; Fri, 4 Mar 94 20:16:24 -0500 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 4 Mar 1994 20:16:32 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01311; Fri, 4 Mar 94 15:45:52 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA26703; Fri, 4 Mar 94 15:45:50 PST Date: Fri, 4 Mar 94 15:45:50 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403042345.AA26703@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA03943; Fri, 4 Mar 94 15:46:04 PST To: ibis@vhdl.org Subject: files and such Hey Guys, When we started defining IBIS the agreement was that IBIS was a data transmittal mechanism and not a file heirarchy definition, so all files must be transfered in total with their complete defining state. We knew this would get burdensome but the alternative requires a little more that file names and directories. we will need A librarian: someone has to guarantee unique file names and control revisions, since it is now possible to have old files that do not work with new files etc. This may be the right way to go but we are getting into the situation where we have to impose more structure on the data then we may want. jonp quad design From bward@sugar.NeoSoft.COM Mon Mar 7 17:41:23 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13043; Mon, 7 Mar 94 17:41:23 PST Received: by sugar.NeoSoft.COM id AA19858 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 7 Mar 1994 19:38:53 -0600 Message-Id: <199403080138.AA19858@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Leadframe models Date: Mon, 7 Mar 94 19:38:45 CST Gentle ibis folk, This is a worm. That is, it is the kind BIRDS feed on. It is in fact, Words On Resolving a Matter. It occurs to me that the BIRD on leadframe models is getting hungry, thus I toss out a WORM. There has been some traffic lately bemoaning the fact that complete leadframe models get so large. Yes they do. But that is the cost of doing business. Lets consider that leadframe models become important to the arts and practices of signal integrity simulation only when the metal structures on them are long enough to be considered transmission lines. That is indeed a high frequency, but there are significant amounts of energy at those frequencies in todays digital signals, and there will be more so as clock rates and edge rates get faster. And be asured they will get faster. Now if the relatively subtle effect of a quarter to a half inch of metal is important, then it is worth modelling correctly. Otherwise you get warm fuzzy feeling of doing something great while you are actually and actively shooting yourself in the foot. No putting it up on the table and taking careful aim at it is more like it. Yes the full representation of modern day leadframes gets large, but a) the software that reads it doesn't care, or at least shouldn't if it written right, and b) I really don't care how compactly a model can be represented that gets me wrong answers. I am fighting that very battle here right now with one of our parts. A stripped down model without all the damping due to mutuals simulates to look artificially very bad, in fact virtually useless. But the real silicon does not look anywhere near that bad. I am preparing the full model for simulation, and following Jon Powell's rather sage advice, comparison to actual physical measurement. Bet it matches pretty closely when tuned up right. Let the record show that I do understand that there are first order and second order effects in this as in all simulation, but I also know from bitter experience how disastrous it can be to wave off an effect because it is so bulky and tedious. Caveat emptor and caveat vendor both apply here! Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bward@sugar.NeoSoft.COM Mon Mar 7 17:50:34 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13115; Mon, 7 Mar 94 17:50:34 PST Received: by sugar.NeoSoft.COM id AA20578 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 7 Mar 1994 19:48:09 -0600 Message-Id: <199403080148.AA20578@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Levels of compliance Date: Mon, 7 Mar 94 19:48:04 CST All ibis folk - A while ago we were coming up with the notion of several levels of compliance, was it levels of detail, for the next revision of the spec. That discussion seems to have largely died out. Where has it settled? Should it be ressurected for discussion again? Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From ccm!Derrick_Duehren@intelhf.intel.com Mon Mar 7 21:57:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14387; Mon, 7 Mar 94 21:57:08 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pdul8-000MPYC; Mon, 7 Mar 94 21:55 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pdurm-0000sEC; Mon, 7 Mar 94 22:02 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 7 Mar 94 22:02:06 PST Date: Mon, 7 Mar 94 22:02:06 PST From: Derrick Duehren Message-Id: <940307220206_4@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Open Forum Agenda for 3/11/94 Text item: Text_1 IBIS Open Forum Meeting Agenda for 3/11/94 Bridge: Res: (415) 904-8800 661901 All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. Meeting Agenda -------------- 8:00 Check-in Intros of new IBIS participants Hobbs Review of 2/18/94 minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues (reshuffle last 5 times?) All Treasurer's Report Hobbs Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 Ratification Hobbs - DAC Conference 6/6 - 6/10 - Steering Committee (5/20? Who? Where?) IBIS Cookbook Hobbs 8:30 Stnd. driver, quality of support, validation Hobbs, All BIRD 8, Spec. of V/I data monotonicity Crisafulli BIRD 9, Other model types Ross BIRD 2, VIH, VIL Thresholds for Inputs Powell Egg 1, mutual pin coupling (ready to hatch?) Bracken 9:00 Simulation temperatures (new BIRD?) Warriner Ramp measurement Reid, Ross, et. al. Egg 2, ramp table? Hobbs Spice-to-IBIS Converter Lipa (NCSU) 9:30 Canright paper Ward Formal BNF notation (BIRD?) Reed, Harr High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A bit of humor from Will/Derrick: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Q: What is this? With mutuals regard, I think to the issue: orthogonal to the pin that is mapping that of that, the mutual is to one have if pins, can couplings be specified independently another they the pin. Long we exclude mappings as consideration of the as from general network (like in topologies that very one you the mail the message described a week famous two ago of). Problems anyway meant at least those in a fashion [Or isn't PinMapping_. not rigorous to handle]. If we come up with the pin spec for a describing mutual to -- (I'd pin couplings to like this still then do straightforward to). The concept, it's "parallel extend", combination to determine of the out into impedances board from seen looking devices connected the the bus the. To fact, that we're in about it now. Here's an earlier talking (Egg a BIRD even on how than do mutuals). to ] Pin2 :[Lmut Cmut Mutuals Pin1 1 2 Rmut -1n 3 1e3 -01p1 1n 01e4 Pin11p Columns " " numbers and pins which Pin2 contain coupled together of the Rmut are etc. Specify the columns of the interest. Values not every couplings must be (in coupling of specified); can the that the sparsity you have assume specified in self inductances [Pin been section (the about backward)]! It talk fits into compatibility and character sall 80 the only. I'm not about here thing where the sure is is is C on the outside it ("to" the node) the close node (board or the die inside). Near, Chris? Do you Kumar or an opinion, where C have be on should? Bracken Eric A: Scrambled Egg! :-) From Will_Hobbs@ccm2.jf.intel.com Mon Mar 7 23:32:15 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14989; Mon, 7 Mar 94 23:32:15 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 7 Mar 94 23:30:20 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 7 Mar 94 23:30:03 -0800 Received: from ccMail by jfsmt2.intel.com id AA763111822 Mon, 07 Mar 94 23:30:22 PST Date: Mon, 07 Mar 94 23:30:22 PST From: "Hobbs, Will" Message-Id: <9402077631.AA763111822@jfsmt2.intel.com> To: bward@sugar.NeoSoft.Com (Bob Ward), ibis@vhdl.org Subject: Levels of compliance Subject: Levels of compliance Date: Mon, 7 Mar 94 19:48:04 CST Bob's mail asked about levels of compliance, a subject that arose in our early December meeting. I think the time to raise this is in a couple of months as we draw the 2.0 enhancements together into a document and move toward ratification, although we could talk about it philosophically now. The main question arises if there are parts of 2.0 that vendors feel they need to support immediately (level 2, versus strictly V1.1 compliance, or level 1) and other more difficult or esoteric parts that most feel can wait (level 3). Examples of level 3 would be mutual parasitics via banded matrix, whereas level 2 might include support for multiple Vcc's, and so on. Will All ibis folk - A while ago we were coming up with the notion of several levels of compliance, was it levels of detail, for the next revision of the spec. That discussion seems to have largely died out. Where has it settled? Should it be ressurected for discussion again? Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bracken@valhalla.performance.com Tue Mar 8 07:19:05 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20928; Tue, 8 Mar 94 07:19:05 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA21327; Tue, 8 Mar 94 10:19:13 EST Message-Id: <9403081519.AA21327@valhalla.performance.com> To: Derrick Duehren Cc: IBIS@vhdl.org Subject: Re: scrambled egg (humor) In-Reply-To: Your message of "Mon, 07 Mar 94 22:02:06 PST." <940307220206_4@ccm.hf.intel.com> Date: Tue, 08 Mar 94 10:19:00 -0500 From: bracken@valhalla.performance.com Gosh, I knew that Intel was having trouble with its mail system, but this seems extreme! --Eric From bracken@valhalla.performance.com Tue Mar 8 07:23:58 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20957; Tue, 8 Mar 94 07:23:58 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA21363; Tue, 8 Mar 94 10:22:35 EST Message-Id: <9403081522.AA21363@valhalla.performance.com> To: Derrick Duehren Cc: IBIS@vhdl.org Subject: Re: scrambled egg (humor) In-Reply-To: Your message of "Mon, 07 Mar 94 22:02:06 PST." <940307220206_4@ccm.hf.intel.com> Date: Tue, 08 Mar 94 10:22:35 -0500 From: bracken@valhalla.performance.com You guys at Intel should really talk to the people who make your mail program. It seems to be getting worse... --Eric From bracken@valhalla.performance.com Tue Mar 8 07:39:24 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21053; Tue, 8 Mar 94 07:39:24 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA21389; Tue, 8 Mar 94 10:38:53 EST Message-Id: <9403081538.AA21389@valhalla.performance.com> To: bward@sugar.neosoft.com (Bob Ward) Cc: ibis@vhdl.org Subject: Re: Leadframe models, Worm In-Reply-To: Your message of "Mon, 07 Mar 94 19:38:45 CST." <199403080138.AA19858@sugar.NeoSoft.COM> Date: Tue, 08 Mar 94 10:38:51 -0500 From: bracken@valhalla.performance.com Bob, Regarding your "worm" : I think _I_ am convinced we'll have to permit a full matrix of couplings to be specified. The BIRD will include that. Look for it "real soon," despite the fact that the "file inclusion" issue still appears to be unresolved. One thing I'm not clear about from your message: you speak of transmission line effects, and apparently advocate doing whatever it takes in the model in order to capture them. OK. Does this mean you're pushing for us to be able to specify arbitrarily complex networks as the package model? In general, the only way I know of modelling a transmission line-LIKE structure with lots of 3-d bends and tapers etc. is to cut the thing up into many series elements. Now we've gone from a network with ONE series RL for each pin (plus all the mutuals amongst them), into a network with MANY R's and L's per pin, and a much larger thicket of mutuals to contend with. I'm willing to step up and write a BIRD for that, but I'd prefer to do it with the sense that I had the "loving support" of the rest of the forum. Anybody else (semi vendors, simulation customers) care to comment? --Eric P.S. There's also a tie-in here with Ravender's "high-frequency" comment. Are the nonlinear models (DC I-V curves) ready to step up to truly HIGH speeds, or do they require enhancements? How can we decide? From cpk@Cadence.COM Tue Mar 8 07:50:42 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21129; Tue, 8 Mar 94 07:50:42 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id HAA00722; Tue, 8 Mar 1994 07:48:12 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma000680; Tue Mar 8 07:47:34 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA19121; Tue, 8 Mar 94 07:35:51 -0800 Received: by hot (5.65+/1.5) id AA11978; Tue, 8 Mar 94 10:46:50 -0500 Date: Tue, 8 Mar 94 10:46:50 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9403081546.AA11978@hot> To: bward@sugar.neosoft.com, bracken@valhalla.performance.com Subject: Re: Leadframe models, Worm Cc: ibis@vhdl.org In my opinion transmission line models will not be adequate for what happens to the bonding wire. The bonding wire is a weak link in signal integrity circuit and it is unlikely that it is a TEM structure which is essential in order to model it as transmission line. Even distributed transmission line model as Eric suggests may not do the job. Since the propeties of these structures are not well known , a lumped RLGC model may do as good or "bad" job as a transmission line model. Acutally this is very good topic for universities because these structures can be studied in isolation and the validity and accuracy of a circuit model representation can be assessed properly if the right questions are asked.` - kumar From bracken@valhalla.performance.com Tue Mar 8 07:58:27 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21157; Tue, 8 Mar 94 07:58:27 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA21428; Tue, 8 Mar 94 10:58:27 EST Message-Id: <9403081558.AA21428@valhalla.performance.com> To: cpk@cadence.com (C. Kumar) Cc: ibis@vhdl.org Subject: Re: Leadframe models, Worm In-Reply-To: Your message of "Tue, 08 Mar 94 10:46:50 EST." <9403081546.AA11978@hot> Date: Tue, 08 Mar 94 10:58:25 -0500 From: bracken@valhalla.performance.com Kumar, To clarify: I was NOT suggesting a distributed (uniform-parameter) transmission line model; I was suggesting a "lumped circuit" approach. I agree that university input would be helpful here, provided that you can find a university with the lab equipment to do some useful measurements! --Eric From Will_Hobbs@ccm2.jf.intel.com Tue Mar 8 16:26:39 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08241; Tue, 8 Mar 94 16:26:39 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 8 Mar 94 16:24:45 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 8 Mar 94 16:24:30 -0800 Received: from ccMail by jfsmt2.intel.com id AA763172691 Tue, 08 Mar 94 16:24:51 PST Date: Tue, 08 Mar 94 16:24:51 PST From: "Hobbs, Will" Message-Id: <9402087631.AA763172691@jfsmt2.intel.com> To: lmsi!milpitas.lmc.com!randyh@sgiblab.sgi.com, ibis@vhdl.org Subject: Re[2]: Returned mail: Host unknown Randy, No idea. I am posting this reply as a query to ibis@vhdl.org and see if anyone can give us an updated address for this individual. Will Will, This is the tenth message in a row I have gotten for this address. I will now presume it is bad. Do you have the contact info for the person to try and inform them of this and get a new, good address? randy ----- Begin Included Message ----- From vhdl.org!Mailer-Daemon@ub-gate.UB.com Tue Mar 8 08:41:54 1994 Subject: Returned mail: Host unknown To: Postmaster@vhdl.org ----- Transcript of session follows ----- 421 Host ralvm29.vnet.ibm.com not found for mailer ddn. 550 jayd@ralvm29.vnet.ibm.com... Host unknown From bward@sugar.NeoSoft.COM Tue Mar 8 18:34:20 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10267; Tue, 8 Mar 94 18:34:20 PST Received: by sugar.NeoSoft.COM id AA26359 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Tue, 8 Mar 1994 20:31:39 -0600 Message-Id: <199403090231.AA26359@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Leadframe models, etc. Date: Tue, 8 Mar 94 20:31:37 CST In particular to Eric, but in general to all ibis watchers - I particularly like your wording that for leadframe mutuals a full matrix should be permitted. In spite of the strong tone of my last note, I agree that it may be too strong to mandate a full matrix, but I also think it disaster to do anything that forbids it either. Thus I like the way you put it about permitting it. I am finding experimentally ( read empirically, it sounds more sophisticated ) that maybe a number of elements cascaded _are_ needed for leadframe elements in the case of high speed, short rise time parts with a lot of drive capability. These put a lot of energy into some pretty interesting frequency regimes. I am not so sure that every possible mutual between such segments is of value, but between parallel neighboring segments, probably. I agree the network can get _very_ messy real quickly, and I am trying some experiments to see what Ma Nature says how much gives good results. I am fortunate to have some parts at my disposal that show just such problems. Hope to have some more to say Real Soon Now (tm). I would say go ahead with the BIRD on leadframe models. It should be a valuable step in any case. I sure won't torpedoe it in any sense just because there _may_ be some effects it cannot capture. Besides you make a very good point about Ravender's concerns. I may be ahead of my time with my details, and I do not want to hold up otherwise valuable progress. If it looks like more detail is needed later we can write another BIRD or amend this one as appropriate. In the meantime I say go for it! ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bward@sugar.NeoSoft.COM Tue Mar 8 18:40:26 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10296; Tue, 8 Mar 94 18:40:26 PST Received: by sugar.NeoSoft.COM id AA26591 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Tue, 8 Mar 1994 20:37:53 -0600 Message-Id: <199403090237.AA26591@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Bond wires Date: Tue, 8 Mar 94 20:37:50 CST All - Kumar makes a _very_ good point about bond wires. I have found them to be a real bugaboo in making leadframe models. They are not at a uniform height above a ground plane, even though they have relative well behaved cross sections. But how do they _really_ behave? Even more puzzleing to me is how to treat the case of parallel bond wires where on power or ground connections, for instance, we may have two, three, or even more bond wires in parallel between the leadframe lead and the bond pad. I imagine the mutual C is pretty well shorted out ( or is it? ) but that the mutual L exists and is pretty well still active ( or is it :-) )KK? :-) ). I agree this may a good are for some university research. Comments? ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From Ravender_Goyal@pdxml1.mentorg.com Wed Mar 9 10:35:03 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18251; Wed, 9 Mar 94 10:35:03 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA07645; Wed, 9 Mar 94 10:32:09 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13435; Wed, 9 Mar 94 10:32:07 -0800 Message-Id: <9403091832.AA13435@rainbow.mentorg.com> Date: 9 Mar 1994 10:30:30 -0800 From: "Ravender Goyal" Subject: Re: Bond wires To: "Bob Ward" , "Bob Ward" Reply to: RE>Bond wires Again, having faced this problem in extreme situations such as RF/ telecom circuit designs, there are closed form rules of thumb available that can be used for bondwire modeling- both for wedge bonding as well as ball bonding, with and without ground planes. These have worked well with me upto 10- 12 GHz in the past. Such formulae are a function of distance between bonding pads (Manhattan length), type of bonding techniques- wedge or ball (determines the curvature in the bondwire path), distance from ground plane (or no- ground plane), number of bondwires on a pad (detemines the effective bondwire inductance- such as if you keep increasing the number of bondwires in parallel believing it will be decreasing the inductance, it is not true after second or third bondwire there is minimal reduction in inductance), bondwire diameter, bondwire material, etc. The other option is to use 3D field solvers to analyze bond wires and provide the L and C matrices. Ravender -------------------------------------- Date: 3/8/94 6:50 PM To: Ravender Goyal From: Bob Ward Received: by pdxml2.mentorg.com with SMTP;8 Mar 1994 18:47:36 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA08096; Tue, 8 Mar 94 18:42:37 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA25506; Tue, 8 Mar 94 18:42:34 -0800 Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10296; Tue, 8 Mar 94 18:40:26 PST Received: by sugar.NeoSoft.COM id AA26591 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Tue, 8 Mar 1994 20:37:53 -0600 Message-Id: <199403090237.AA26591@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.COM (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Bond wires Date: Tue, 8 Mar 94 20:37:50 CST All - Kumar makes a _very_ good point about bond wires. I have found them to be a real bugaboo in making leadframe models. They are not at a uniform height above a ground plane, even though they have relative well behaved cross sections. But how do they _really_ behave? Even more puzzleing to me is how to treat the case of parallel bond wires where on power or ground connections, for instance, we may have two, three, or even more bond wires in parallel between the leadframe lead and the bond pad. I imagine the mutual C is pretty well shorted out ( or is it? ) but that the mutual L exists and is pretty well still active ( or is it :-) )KK? :-) ). I agree this may a good are for some university research. Comments? ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From JAYD@RALVM29.VNET.IBM.COM Thu Mar 10 08:08:49 1994 Return-Path: Received: from vnet.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28718; Thu, 10 Mar 94 08:08:49 PST Message-Id: <9403101608.AA28718@vhdl.vhdl.org> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 8686; Thu, 10 Mar 94 11:03:49 EST Date: Thu, 10 Mar 94 11:02:26 EST From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" X-Addr: Transceiver Technology Dev't, D63/061 IBM Network Hdwe. Div. P. O. Box 12195 Research Triangle Park, NC 27709 To: ibis@vhdl.org Subject: my (rubber?) address Dear IBIS friends, Please be assured that rumors of my disappearance from the network are premature (to blatantly plagiarize a favorite writer of mine, Mark Twain). My only conclusion is that our Internet connection must have been down, as I sent and received mail to and from Dr. Michael Steer this morning using my address shown in Randy's note. I apologize for any inconvenience, and thank Dr. Steer for calling it to my attention. I am on the IBIS contacts list, so please let me know if it re-occurs. Jay Diepenbrock From huq@lightning.nsc.com Fri Mar 11 10:28:15 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04371; Fri, 11 Mar 94 10:28:15 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA19789 for ibis@vhdl.org; Fri, 11 Mar 94 10:26:17 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22345 for ibis@vhdl.org; Fri, 11 Mar 94 10:26:16 -0800 Received: from kural by lightning.nsc.com (4.1/SMI-4.1) id AA10493; Fri, 11 Mar 94 10:30:30 PST Date: Fri, 11 Mar 94 10:30:30 PST From: huq@lightning.nsc.com (Syed Huq) Message-Id: <9403111830.AA10493@lightning.nsc.com> To: ibis@vhdl.org Subject: Meeting in May Cc: huq@lightning.nsc.com Fellow members: In May, there will be a meeting to ratify all the BIRDS so IBIS2.0 can be released. What will be done during the DAC shows in June ? I am sure I can be in Oregon in May. Regards, Syed National Semiconductor Corp. From Derrick_Duehren@ccm2.jf.intel.com Fri Mar 11 11:08:38 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04868; Fri, 11 Mar 94 11:08:38 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 11 Mar 94 11:06:38 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Fri, 11 Mar 94 11:06:23 -0800 Received: from ccMail by jfsmt2.intel.com id AA763412795 Fri, 11 Mar 94 11:06:35 PST Date: Fri, 11 Mar 94 11:06:35 PST From: "Duehren, Derrick" Message-Id: <9402117634.AA763412795@jfsmt2.intel.com> To: ibis@vhdl.org Subject: Re: Meeting in May Syed, The May 20 meeting in Portland, "Orygun" is a steering committee meeting to work out the details of meshing together the approved BIRDs into a proposal for IBIS 2.0. The meeting during the DAC conference will be used to actually ratify version 2.0. - Derrick ______________________________ Reply Separator _________________________________ Subject: Meeting in May Author: huq@lightning.nsc.com at SMTPGATE Date: 3/11/94 10:51 AM Fellow members: In May, there will be a meeting to ratify all the BIRDS so IBIS2.0 can be released. What will be done during the DAC shows in June ? I am sure I can be in Oregon in May. Regards, Syed National Semiconductor Corp. From slipa@eos.ncsu.edu Fri Mar 11 11:48:01 1994 Return-Path: Received: from rand.ece.ncsu.edu (c11046-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05234; Fri, 11 Mar 94 11:48:01 PST Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA20928; Fri, 11 Mar 1994 14:45:59 -0500 From: slipa@eos.ncsu.edu Message-Id: <9403111945.AA20928@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis update, man pages, and example Date: Fri, 11 Mar 94 14:45:57 EST Dear IBIS Community: Here is another s2ibis update. I have been on hold waiting for SPICE executables to be loaded onto our RS6000 and assorted Sun platforms for pre-release testing. In the meantime I have written man pages (unixspeak for documentation) and implemented the min and max simulation runs. Apparently SPICE has been loaded onto the machines in question, so I expect to be able to post the executables for a variety of platforms on vhdl.org by next week. In today's IBIS Open Forum meeting, Kellee et. al. asked me to post my man pages and an example s2ibis output to the reflector. In the interests of keeping this message as short as possible I created a simple s2ibis input deck which describes a single 3-state CMOS inverter and its enable input, along with some clamp diodes. I think it will be very easy to understand the input deck once the man pages are read. I am including, in order: 1) de-unixed man pages that should print anywhere 2) the s2ibis input deck for a simple CMOS 3-state circuit 3) the resulting s2ibis output Please let me know if you have any questions. Steve Lipa slipa@eos.ncsu.edu ***MAN PAGES START HERE 15 Feb 1994 s2ibis(1) NAME s2ibis - convert SPICE models to IBIS models SYNOPSIS s2ibis input_file [ output_file ] DESCRIPTION s2ibis reads in a s2ibis input file and produces a Version 1.1 IBIS model file. The s2ibis input file consists of a s2ibis header line, a modified IBIS pin list, and a SPICE input deck describing the topology of the circuit to be modeled. s2ibis uses the s2ibis header line and pin list to generate the IBIS model file header and pin list, and then invokes SPICE to generate IBIS model tables for the pins specified in the pin list. Currently, SPICE runs are initiated for [Pullup], [Pulldown], [POWER_clamp], and [GND_clamp] tables for all output pins, except Open_drain pins which omit the [Pullup] and [POWER_clamp] tables. [POWER_clamp] and [GND_clamp] simulations are initiated for Input pins. Simulation input and output decks are created in the directory in which s2ibis is invoked. The general naming scheme for the files is xxxyyyyy.spi or xxxyyyyy.out for the input and output files respec- tively, where xxx is a three-letter code name for the simulation type and yyyyy is the pin number. The first two characters of the xxx codes are: [Pullup]=pu, [Pulldown]=pd, [POWER_clamp]=pc, [GND_clamp]=gc, and [RAMP]=rm. The third character is t for typical, n for min, and x for max. Thus, if s2ibis reports convergence problems while generating the [GND_clamp] table for pin 6, the files of interest are: gct6.spi and gct6.out. N.B.: s2ibis will overwrite these files with impunity, regardless of the setting of the noclobber environment variable. s2ibis reads the input file from input_file and puts the output on stdout, unless output_file is specified. INPUT FILE The s2ibis input file consists of three parts: 1) the header line 2) the modified pin list 3) the SPICE input deck. The header line is used to create the IBIS model file header. It has the following format: *company_name device_name package_type technology All four fields are required. s2ibis will accept any string for any of the fields. Currently, the package_type field is not used. This field is reserved for implementation of default parasitic pin inductances and capacitances in future versions of s2ibis. s2ibis expects the technol- ogy field to contain either CMOS or BIPOLAR. Anything else will result in unpredictable behavior. North Carolina State University 1 s2ibis(1) 15 Feb 1994 Immediately following the header line, s2ibis expects to find a pin list. The pin list is the same as a standard IBIS pin list except that after each non-NC pin entry a second line, called the pindata line, is inserted to help s2ibis to set up the subsequent SPICE simulations. The format for the pindata line depends on the model_type of the associ- ated pin. Eight model_types are currently supported: 1) Input 2) Ouput 3) I/O 4) 3-state 5) Open_drain 6) POWER 7) GND 8) NC. For pins with model_type Input, the pindata line has the following for- mat: *model_type SPICE_NODE polarity vil vih The model_type field must be Input. The SPICE_NODE field is used to specify which node in the attached SPICE deck corresponds to the pin. The polarity field should be 1 for inverting inputs and 0 for non- inverting inputs. The vil field should be a floating point number specifying the voltage that this input should be driven to when a logic low is to be applied. The vih field is similar for the logic high situation. For pins with model_type Output, I/O, 3-state, and Open_drain, the pin- data line has the following format: *model_type SPICE_NODE ramp_time input_pin [enable_pin] The model_type field must be Output, I/O, 3-state, or Open_drain. The SPICE_NODE field is as above. The ramp_time field should be a floating point number specifying suggested minimum length for the SPICE .TRAN analysis to be used for generating the [Ramp] tables. Currently, the [Ramp] tables are not generated, but s2ibis expects a floating point number anyway. The [Ramp] tables will be generated in the next version of s2ibis. All output pins must have an associated input pin. The input_pin field refers to the pin number, *not* the SPICE node number. If the model_type is I/O or 3-state, an enable_pin field is expected, specifying the pin number for the input pin that enables the associated output. For POWER pins, the pindata line has the following format: *model_type SPICE_NODE vpwr_typ [vpwr_min] [vpwr_max] The model_type field must be POWER. The SPICE_NODE field operates as described above. The vpwr_typ field is required. A floating point number is expected, describing the nominal supply voltage to be applied. If multiple POWER pins are specified, s2ibis will ignore all except the first. For GND pins, the pindata line has the following format: *model_type SPICE_NODE The SPICE_NODE field operates as described above. Only the first GND 2 North Carolina State University 15 Feb 1994 s2ibis(1) pin is acknowledged by s2ibis. Finally, the [Pin] section must end with an [Endpin] card: *[Endpin] SPICE DECK The input SPICE deck should contain only circuit elements needed to describe the circuit. The power supply and voltage sources are automat- ically generated by s2ibis. Similarly, control cards probably should not be present in the SPICE deck. Currently s2ibis uses default SPICE parameters, so users with convergence problems might want to use the .OPTIONS card to mitigate them. RESTRICTIONS [Ramp] tables are not yet implemented. SPICE convergence problems may result in missing tables. s2ibis tries to continue in the event of problems in the SPICE runs, reporting prob- lems on stderr. Temporary SPICE input and output file names are not variable and will overwrite existing files with the same names automatically. Input voltages are forced to the same voltage (vil or vih) for all simu- lations. That is, no allowance is made for variations in vil and vih for min and max simulations. s2ibis has only been tested using Berkeley SPICE version 2G6, and calls SPICE using the following syntax: spice inputfile outputfile Proprietary versions of SPICE which use different output formats or dif- ferent calling sequences may not work properly with s2ibis. North Carolina State University 3 ***MAN PAGES END HERE ***s2ibis INPUT DECK STARTS HERE *Lipa_Labs 74LLC244 SO20 CMOS *[Pin] signal_name model_name R_pin L_pin C_pin * 1 NC NC * 2 NC NC * 3 gozouta Buffer1 200.0m 5.0nH 2.5pF * 3-state 31 2.0E-8 4 8 * 4 In1 Input1 * Input 21 1 0.0 5.0 * 7 GND GND * GND 0 * 8 En1 Enable1 * Input 22 1 0.0 5.0 * 9 NC NC * 10 NC NC * 11 NC NC * 13 NC NC * 14 VCC POWER * POWER 99 5.0 4.5 5.5 *[Endpin] ***** S2IBIS CMOS TEST FILE ***** *VDD 99 0 5.0V M1 23 21 99 99 PCHAN W=23U L=2U M3 24 22 99 99 PCHAN W=23U L=2U M5 31 22 23 99 PCHAN W=23U L=2U M2 23 21 0 0 NCHAN W=10U L=2U M4 24 22 0 0 NCHAN W=10U L=2U M6 31 24 23 0 NCHAN W=10U L=2U D1 21 99 CLMP D2 0 21 CLMP D3 22 99 CLMP D4 0 22 CLMP D5 31 99 CLMP D6 0 31 CLMP .MODEL CLMP D VJ=0.7 RS=100 .MODEL NCHAN NMOS LEVEL=1 VTO=0.8186 RD=30 RS=30 .MODEL PCHAN PMOS LEVEL=1 VTO=-0.9456 RD=10 RS=10 .END ***s2ibis INPUT DECK ENDS HERE ***s2ibis OUTPUT DECK STARTS HERE [IBIS Ver] 1.1 [Comment char] *_char [File name] example.ibs [File Rev] 0.0 [Date] Fri Mar 11 13:58:41 1994 [Source] s2ibis SPICE to IBIS converter [Disclaimer] This information is for modelling purposes only. [Component] 74LLC244 [Manufacturer] Lipa_Labs [Package] * variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF [Pin] signal_name model_name R_pin L_pin C_pin 1 NC NC 2 NC NC 3 gozouta Buffer1 200.0m 5.0nH 2.5pF 4 In1 Input1 7 GND GND 8 En1 Enable1 9 NC NC 10 NC NC 11 NC NC 13 NC NC 14 VCC POWER [Model] Buffer1 Model_type 3-state Polarity Inverting Enable Active-Low [Voltage range] 5.000000 4.500000 5.500000 [Pulldown] * Voltage I(typ) I(min) I(max) * -5.000 -1.844e-01 -1.875e-01 -1.814e-01 -4.800 -1.758e-01 -1.789e-01 -1.728e-01 -4.600 -1.672e-01 -1.703e-01 -1.642e-01 -4.400 -1.586e-01 -1.617e-01 -1.556e-01 -4.200 -1.500e-01 -1.531e-01 -1.470e-01 -4.000 -1.414e-01 -1.445e-01 -1.384e-01 -3.800 -1.328e-01 -1.359e-01 -1.298e-01 -3.600 -1.242e-01 -1.274e-01 -1.212e-01 -3.400 -1.157e-01 -1.188e-01 -1.126e-01 -3.200 -1.071e-01 -1.102e-01 -1.040e-01 -3.000 -9.852e-02 -1.017e-01 -9.543e-02 -2.800 -8.997e-02 -9.313e-02 -8.686e-02 -2.600 -8.142e-02 -8.460e-02 -7.830e-02 -2.400 -7.289e-02 -7.608e-02 -6.975e-02 -2.200 -6.437e-02 -6.758e-02 -6.122e-02 -2.000 -5.587e-02 -5.910e-02 -5.270e-02 -1.800 -4.741e-02 -5.065e-02 -4.422e-02 -1.600 -3.898e-02 -4.223e-02 -3.577e-02 -1.400 -3.060e-02 -3.387e-02 -2.737e-02 -1.200 -2.232e-02 -2.560e-02 -1.908e-02 -1.000 -1.420e-02 -1.747e-02 -1.098e-02 -0.800 -6.497e-03 -9.639e-03 -3.525e-03 -0.600 -7.295e-04 -2.761e-03 -1.788e-04 -0.400 -7.791e-05 -1.004e-04 -1.024e-04 -0.200 -3.766e-05 -2.912e-05 -5.014e-05 0.000 -1.122e-10 -2.415e-08 -1.685e-11 0.200 3.595e-05 2.754e-05 4.803e-05 0.400 7.018e-05 5.366e-05 9.394e-05 0.600 1.027e-04 7.832e-05 1.377e-04 0.800 1.335e-04 1.015e-04 1.794e-04 1.000 1.629e-04 1.242e-04 2.190e-04 1.200 1.940e-04 1.489e-04 2.595e-04 1.400 2.275e-04 1.757e-04 3.027e-04 1.600 2.634e-04 2.045e-04 3.488e-04 1.800 3.016e-04 2.355e-04 3.975e-04 2.000 3.411e-04 2.675e-04 4.480e-04 2.200 3.808e-04 2.999e-04 4.983e-04 2.400 4.203e-04 3.323e-04 5.481e-04 2.600 4.593e-04 3.644e-04 5.970e-04 2.800 4.975e-04 3.962e-04 6.447e-04 3.000 5.346e-04 4.271e-04 6.907e-04 3.200 5.703e-04 4.571e-04 7.347e-04 3.400 6.042e-04 4.858e-04 7.763e-04 3.600 6.361e-04 5.130e-04 8.150e-04 3.800 6.657e-04 5.385e-04 8.506e-04 4.000 6.926e-04 5.623e-04 8.827e-04 4.200 7.166e-04 5.843e-04 9.109e-04 4.400 7.376e-04 6.038e-04 9.347e-04 4.600 7.552e-04 6.204e-04 9.540e-04 4.800 7.690e-04 6.352e-04 9.683e-04 5.000 7.782e-04 1.243e-03 9.773e-04 5.200 7.822e-04 1.206e-02 9.802e-04 5.400 7.831e-04 3.061e-02 9.802e-04 5.600 1.432e-03 5.079e-02 9.802e-04 5.800 1.364e-02 7.156e-02 9.802e-04 6.000 3.282e-02 9.264e-02 9.805e-04 6.200 5.331e-02 1.139e-01 1.723e-03 6.400 7.428e-02 1.353e-01 1.550e-02 6.600 9.550e-02 1.568e-01 3.527e-02 6.800 1.169e-01 1.783e-01 5.604e-02 7.000 1.384e-01 1.999e-01 7.720e-02 7.200 1.599e-01 2.215e-01 9.856e-02 7.400 1.815e-01 2.432e-01 1.200e-01 7.600 2.032e-01 2.649e-01 1.416e-01 7.800 2.249e-01 2.866e-01 1.632e-01 8.000 2.466e-01 3.084e-01 1.849e-01 8.200 2.683e-01 3.301e-01 2.066e-01 8.400 2.901e-01 3.519e-01 2.284e-01 8.600 3.119e-01 3.737e-01 2.501e-01 8.800 3.336e-01 3.955e-01 2.719e-01 9.000 3.555e-01 4.173e-01 2.937e-01 9.200 3.773e-01 4.391e-01 3.155e-01 9.400 3.991e-01 4.609e-01 3.374e-01 9.600 4.209e-01 4.828e-01 3.592e-01 9.800 4.428e-01 5.046e-01 3.810e-01 10.000 4.646e-01 5.265e-01 4.029e-01 [Pullup] * Voltage I(typ) I(min) I(max) * -5.000 4.614e-01 4.719e-01 4.576e-01 -4.800 4.395e-01 4.500e-01 4.357e-01 -4.600 4.176e-01 4.282e-01 4.138e-01 -4.400 3.958e-01 4.064e-01 3.920e-01 -4.200 3.740e-01 3.846e-01 3.701e-01 -4.000 3.521e-01 3.628e-01 3.483e-01 -3.800 3.303e-01 3.410e-01 3.264e-01 -3.600 3.085e-01 3.192e-01 3.046e-01 -3.400 2.867e-01 2.975e-01 2.828e-01 -3.200 2.649e-01 2.758e-01 2.610e-01 -3.000 2.432e-01 2.540e-01 2.392e-01 -2.800 2.214e-01 2.324e-01 2.175e-01 -2.600 1.997e-01 2.107e-01 1.958e-01 -2.400 1.781e-01 1.891e-01 1.741e-01 -2.200 1.564e-01 1.675e-01 1.524e-01 -2.000 1.349e-01 1.460e-01 1.308e-01 -1.800 1.134e-01 1.246e-01 1.093e-01 -1.600 9.196e-02 1.032e-01 8.784e-02 -1.400 7.071e-02 8.205e-02 6.657e-02 -1.200 4.972e-02 6.110e-02 4.556e-02 -1.000 2.924e-02 4.056e-02 2.513e-02 -0.800 1.030e-02 2.092e-02 6.719e-03 -0.600 4.813e-04 4.548e-03 3.961e-04 -0.400 1.920e-04 1.677e-04 2.440e-04 -0.200 9.376e-05 6.155e-05 1.195e-04 0.000 1.888e-11 2.491e-08 1.655e-11 0.200 -8.933e-05 -5.817e-05 -1.144e-04 0.400 -1.742e-04 -1.131e-04 -2.238e-04 0.600 -2.546e-04 -1.648e-04 -3.281e-04 0.800 -3.306e-04 -2.133e-04 -4.274e-04 1.000 -4.030e-04 -2.596e-04 -5.222e-04 1.200 -4.728e-04 -3.041e-04 -6.141e-04 1.400 -5.402e-04 -3.468e-04 -7.033e-04 1.600 -6.051e-04 -3.876e-04 -7.896e-04 1.800 -6.674e-04 -4.266e-04 -8.730e-04 2.000 -7.272e-04 -4.635e-04 -9.535e-04 2.200 -7.840e-04 -4.983e-04 -1.031e-03 2.400 -8.380e-04 -5.311e-04 -1.105e-03 2.600 -8.892e-04 -5.618e-04 -1.175e-03 2.800 -9.376e-04 -5.905e-04 -1.243e-03 3.000 -9.832e-04 -6.173e-04 -1.307e-03 3.200 -1.026e-03 -6.420e-04 -1.368e-03 3.400 -1.066e-03 -6.648e-04 -1.426e-03 3.600 -1.103e-03 -6.857e-04 -1.480e-03 3.800 -1.138e-03 -7.055e-04 -1.532e-03 4.000 -1.170e-03 -7.264e-04 -1.580e-03 4.200 -1.200e-03 -7.484e-04 -1.625e-03 4.400 -1.232e-03 -7.714e-04 -1.667e-03 4.600 -1.265e-03 -7.955e-04 -1.707e-03 4.800 -1.300e-03 -8.221e-04 -1.747e-03 5.000 -1.336e-03 -1.311e-03 -1.789e-03 5.200 -1.374e-03 -6.331e-03 -1.832e-03 5.400 -1.412e-03 -1.379e-02 -1.877e-03 5.600 -1.572e-03 -2.178e-02 -1.924e-03 5.800 -5.689e-03 -2.998e-02 -1.972e-03 6.000 -1.319e-02 -3.830e-02 -2.022e-03 6.200 -2.126e-02 -4.668e-02 -2.462e-03 6.400 -2.953e-02 -5.511e-02 -7.877e-03 6.600 -3.790e-02 -6.357e-02 -1.566e-02 6.800 -4.633e-02 -7.206e-02 -2.384e-02 7.000 -5.481e-02 -8.057e-02 -3.217e-02 7.200 -6.331e-02 -8.910e-02 -4.058e-02 7.400 -7.183e-02 -9.763e-02 -4.904e-02 7.600 -8.037e-02 -1.062e-01 -5.754e-02 7.800 -8.892e-02 -1.147e-01 -6.606e-02 8.000 -9.748e-02 -1.233e-01 -7.460e-02 8.200 -1.060e-01 -1.319e-01 -8.315e-02 8.400 -1.146e-01 -1.405e-01 -9.171e-02 8.600 -1.232e-01 -1.490e-01 -1.003e-01 8.800 -1.318e-01 -1.576e-01 -1.089e-01 9.000 -1.404e-01 -1.662e-01 -1.175e-01 9.200 -1.490e-01 -1.748e-01 -1.260e-01 9.400 -1.576e-01 -1.834e-01 -1.346e-01 9.600 -1.662e-01 -1.920e-01 -1.432e-01 9.800 -1.748e-01 -2.006e-01 -1.519e-01 10.000 -1.834e-01 -2.092e-01 -1.605e-01 [GND_clamp] * Voltage I(typ) I(min) I(max) * -5.000 -1.830e-01 -1.875e-01 -1.814e-01 -4.800 -1.744e-01 -1.789e-01 -1.728e-01 -4.600 -1.658e-01 -1.703e-01 -1.642e-01 -4.400 -1.572e-01 -1.617e-01 -1.556e-01 -4.200 -1.486e-01 -1.531e-01 -1.470e-01 -4.000 -1.400e-01 -1.445e-01 -1.384e-01 -3.800 -1.314e-01 -1.359e-01 -1.298e-01 -3.600 -1.228e-01 -1.274e-01 -1.212e-01 -3.400 -1.142e-01 -1.188e-01 -1.126e-01 -3.200 -1.057e-01 -1.102e-01 -1.040e-01 -3.000 -9.709e-02 -1.017e-01 -9.543e-02 -2.800 -8.853e-02 -9.313e-02 -8.686e-02 -2.600 -7.997e-02 -8.460e-02 -7.829e-02 -2.400 -7.143e-02 -7.608e-02 -6.975e-02 -2.200 -6.291e-02 -6.758e-02 -6.121e-02 -2.000 -5.441e-02 -5.910e-02 -5.270e-02 -1.800 -4.593e-02 -5.064e-02 -4.421e-02 -1.600 -3.749e-02 -4.223e-02 -3.576e-02 -1.400 -2.911e-02 -3.387e-02 -2.737e-02 -1.200 -2.082e-02 -2.560e-02 -1.907e-02 -1.000 -1.270e-02 -1.746e-02 -1.097e-02 -0.800 -5.070e-03 -9.627e-03 -3.477e-03 -0.600 -1.905e-04 -2.731e-03 -2.425e-05 -0.400 -1.041e-07 -4.215e-05 -5.130e-09 -0.200 -5.844e-11 -1.002e-07 -1.287e-11 0.000 -1.194e-11 -1.250e-08 -1.102e-11 0.200 -1.098e-11 -1.131e-08 -1.022e-11 0.400 -1.002e-11 -1.021e-08 -9.421e-12 0.600 -9.069e-12 -9.105e-09 -8.619e-12 0.800 -8.115e-12 -8.002e-09 -7.817e-12 1.000 -7.160e-12 -6.898e-09 -7.016e-12 1.200 -6.205e-12 -5.794e-09 -6.214e-12 1.400 -5.251e-12 -4.691e-09 -5.412e-12 1.600 -4.296e-12 -3.587e-09 -4.610e-12 1.800 -3.341e-12 -2.483e-09 -3.808e-12 2.000 -2.387e-12 -1.380e-09 -3.007e-12 2.200 -1.432e-12 -2.759e-10 -2.205e-12 2.400 -4.774e-13 8.278e-10 -1.403e-12 2.600 4.773e-13 1.931e-09 -6.013e-13 2.800 1.432e-12 3.035e-09 2.005e-13 3.000 2.387e-12 4.139e-09 1.002e-12 3.200 3.341e-12 5.243e-09 1.804e-12 3.400 4.296e-12 6.346e-09 2.606e-12 3.600 5.251e-12 7.450e-09 3.408e-12 3.800 6.205e-12 8.554e-09 4.209e-12 4.000 7.160e-12 9.657e-09 5.011e-12 4.200 8.115e-12 1.076e-08 5.813e-12 4.400 9.069e-12 1.187e-08 6.615e-12 4.600 1.002e-11 1.650e-08 7.416e-12 4.800 1.098e-11 1.968e-06 8.218e-12 5.000 1.194e-11 6.716e-04 9.020e-12 [POWER_clamp] * Voltage I(typ) I(min) I(max) * -5.000 4.614e-01 4.719e-01 4.576e-01 -4.800 4.395e-01 4.500e-01 4.357e-01 -4.600 4.176e-01 4.282e-01 4.138e-01 -4.400 3.958e-01 4.064e-01 3.920e-01 -4.200 3.740e-01 3.846e-01 3.701e-01 -4.000 3.521e-01 3.628e-01 3.483e-01 -3.800 3.303e-01 3.410e-01 3.264e-01 -3.600 3.085e-01 3.192e-01 3.046e-01 -3.400 2.867e-01 2.975e-01 2.828e-01 -3.200 2.649e-01 2.758e-01 2.610e-01 -3.000 2.432e-01 2.540e-01 2.392e-01 -2.800 2.214e-01 2.324e-01 2.175e-01 -2.600 1.997e-01 2.107e-01 1.958e-01 -2.400 1.781e-01 1.891e-01 1.741e-01 -2.200 1.564e-01 1.675e-01 1.524e-01 -2.000 1.349e-01 1.460e-01 1.308e-01 -1.800 1.133e-01 1.246e-01 1.093e-01 -1.600 9.194e-02 1.032e-01 8.783e-02 -1.400 7.069e-02 8.204e-02 6.655e-02 -1.200 4.969e-02 6.108e-02 4.553e-02 -1.000 2.921e-02 4.054e-02 2.508e-02 -0.800 1.022e-02 2.089e-02 6.579e-03 -0.600 1.991e-04 4.462e-03 2.630e-05 -0.400 1.041e-07 4.245e-05 5.130e-09 -0.200 5.844e-11 1.002e-07 1.183e-11 0.000 1.194e-11 1.250e-08 1.102e-11 [Model] Input1 Model_type Input Polarity Non-Inverting [Voltage range] 5.000000 4.500000 5.500000 [GND_clamp] * Voltage I(typ) I(min) I(max) * -5.000 -4.248e-02 -4.355e-02 -4.209e-02 -4.800 -4.049e-02 -4.157e-02 -4.010e-02 -4.600 -3.850e-02 -3.958e-02 -3.812e-02 -4.400 -3.652e-02 -3.760e-02 -3.613e-02 -4.200 -3.453e-02 -3.562e-02 -3.414e-02 -4.000 -3.255e-02 -3.363e-02 -3.216e-02 -3.800 -3.056e-02 -3.165e-02 -3.017e-02 -3.600 -2.858e-02 -2.968e-02 -2.819e-02 -3.400 -2.660e-02 -2.770e-02 -2.620e-02 -3.200 -2.462e-02 -2.572e-02 -2.422e-02 -3.000 -2.264e-02 -2.375e-02 -2.224e-02 -2.800 -2.067e-02 -2.177e-02 -2.027e-02 -2.600 -1.869e-02 -1.981e-02 -1.829e-02 -2.400 -1.672e-02 -1.784e-02 -1.632e-02 -2.200 -1.475e-02 -1.588e-02 -1.435e-02 -2.000 -1.279e-02 -1.392e-02 -1.238e-02 -1.800 -1.083e-02 -1.197e-02 -1.042e-02 -1.600 -8.884e-03 -1.002e-02 -8.470e-03 -1.400 -6.948e-03 -8.093e-03 -6.532e-03 -1.200 -5.031e-03 -6.180e-03 -4.613e-03 -1.000 -3.152e-03 -4.297e-03 -2.736e-03 -0.800 -1.368e-03 -2.474e-03 -9.784e-04 -0.600 -8.539e-05 -8.266e-04 -1.211e-05 -0.400 -5.206e-08 -2.018e-05 -2.608e-09 -0.200 -2.822e-11 -4.277e-08 -6.430e-12 0.000 -5.010e-12 -8.942e-11 -5.500e-12 0.200 -4.600e-12 -4.098e-12 -5.100e-12 0.400 -4.200e-12 -3.698e-12 -4.700e-12 0.600 -3.800e-12 -3.298e-12 -4.300e-12 0.800 -3.400e-12 -2.898e-12 -3.900e-12 1.000 -3.000e-12 -2.498e-12 -3.500e-12 1.200 -2.600e-12 -2.098e-12 -3.100e-12 1.400 -2.200e-12 -1.698e-12 -2.700e-12 1.600 -1.800e-12 -1.298e-12 -2.300e-12 1.800 -1.400e-12 -8.982e-13 -1.900e-12 2.000 -1.000e-12 -4.982e-13 -1.500e-12 2.200 -6.000e-13 -9.818e-14 -1.100e-12 2.400 -2.000e-13 3.018e-13 -7.000e-13 2.600 2.000e-13 7.018e-13 -3.000e-13 2.800 6.000e-13 1.102e-12 1.000e-13 3.000 1.000e-12 1.502e-12 5.000e-13 3.200 1.400e-12 1.902e-12 9.000e-13 3.400 1.800e-12 2.302e-12 1.300e-12 3.600 2.200e-12 2.702e-12 1.700e-12 3.800 2.600e-12 3.102e-12 2.100e-12 4.000 3.000e-12 3.502e-12 2.500e-12 4.200 3.400e-12 3.902e-12 2.900e-12 4.400 3.800e-12 8.097e-12 3.300e-12 4.600 4.200e-12 1.913e-09 3.700e-12 4.800 4.600e-12 9.562e-07 4.100e-12 5.000 5.010e-12 2.333e-04 4.500e-12 [POWER_clamp] * Voltage I(typ) I(min) I(max) * -5.000 4.248e-02 4.355e-02 4.209e-02 -4.800 4.049e-02 4.157e-02 4.010e-02 -4.600 3.850e-02 3.958e-02 3.812e-02 -4.400 3.652e-02 3.760e-02 3.613e-02 -4.200 3.453e-02 3.562e-02 3.414e-02 -4.000 3.255e-02 3.363e-02 3.216e-02 -3.800 3.056e-02 3.165e-02 3.017e-02 -3.600 2.858e-02 2.968e-02 2.819e-02 -3.400 2.660e-02 2.770e-02 2.620e-02 -3.200 2.462e-02 2.572e-02 2.422e-02 -3.000 2.264e-02 2.375e-02 2.224e-02 -2.800 2.067e-02 2.177e-02 2.027e-02 -2.600 1.869e-02 1.981e-02 1.829e-02 -2.400 1.672e-02 1.784e-02 1.632e-02 -2.200 1.475e-02 1.588e-02 1.435e-02 -2.000 1.279e-02 1.392e-02 1.238e-02 -1.800 1.083e-02 1.197e-02 1.042e-02 -1.600 8.884e-03 1.002e-02 8.470e-03 -1.400 6.948e-03 8.093e-03 6.532e-03 -1.200 5.031e-03 6.180e-03 4.613e-03 -1.000 3.152e-03 4.297e-03 2.736e-03 -0.800 1.368e-03 2.474e-03 9.783e-04 -0.600 8.539e-05 8.266e-04 1.211e-05 -0.400 5.206e-08 2.019e-05 2.608e-09 -0.200 2.822e-11 4.277e-08 5.901e-12 0.000 5.010e-12 8.959e-11 5.500e-12 [Model] Enable1 Model_type Input Polarity Non-Inverting [Voltage range] 5.000000 4.500000 5.500000 [GND_clamp] * Voltage I(typ) I(min) I(max) * -5.000 -4.248e-02 -4.355e-02 -4.209e-02 -4.800 -4.049e-02 -4.157e-02 -4.010e-02 -4.600 -3.850e-02 -3.958e-02 -3.812e-02 -4.400 -3.652e-02 -3.760e-02 -3.613e-02 -4.200 -3.453e-02 -3.562e-02 -3.414e-02 -4.000 -3.255e-02 -3.363e-02 -3.216e-02 -3.800 -3.056e-02 -3.165e-02 -3.017e-02 -3.600 -2.858e-02 -2.968e-02 -2.819e-02 -3.400 -2.660e-02 -2.770e-02 -2.620e-02 -3.200 -2.462e-02 -2.572e-02 -2.422e-02 -3.000 -2.264e-02 -2.375e-02 -2.224e-02 -2.800 -2.067e-02 -2.177e-02 -2.027e-02 -2.600 -1.869e-02 -1.981e-02 -1.829e-02 -2.400 -1.672e-02 -1.784e-02 -1.632e-02 -2.200 -1.475e-02 -1.588e-02 -1.435e-02 -2.000 -1.279e-02 -1.392e-02 -1.238e-02 -1.800 -1.083e-02 -1.197e-02 -1.042e-02 -1.600 -8.884e-03 -1.002e-02 -8.470e-03 -1.400 -6.948e-03 -8.093e-03 -6.532e-03 -1.200 -5.031e-03 -6.180e-03 -4.613e-03 -1.000 -3.152e-03 -4.297e-03 -2.736e-03 -0.800 -1.368e-03 -2.474e-03 -9.784e-04 -0.600 -8.539e-05 -8.266e-04 -1.211e-05 -0.400 -5.206e-08 -2.018e-05 -2.608e-09 -0.200 -2.822e-11 -4.277e-08 -6.430e-12 0.000 -5.010e-12 -8.942e-11 -5.500e-12 0.200 -4.600e-12 -4.098e-12 -5.100e-12 0.400 -4.200e-12 -3.698e-12 -4.700e-12 0.600 -3.800e-12 -3.298e-12 -4.300e-12 0.800 -3.400e-12 -2.898e-12 -3.900e-12 1.000 -3.000e-12 -2.498e-12 -3.500e-12 1.200 -2.600e-12 -2.098e-12 -3.100e-12 1.400 -2.200e-12 -1.698e-12 -2.700e-12 1.600 -1.800e-12 -1.298e-12 -2.300e-12 1.800 -1.400e-12 -8.982e-13 -1.900e-12 2.000 -1.000e-12 -4.982e-13 -1.500e-12 2.200 -6.000e-13 -9.818e-14 -1.100e-12 2.400 -2.000e-13 3.018e-13 -7.000e-13 2.600 2.000e-13 7.018e-13 -3.000e-13 2.800 6.000e-13 1.102e-12 1.000e-13 3.000 1.000e-12 1.502e-12 5.000e-13 3.200 1.400e-12 1.902e-12 9.000e-13 3.400 1.800e-12 2.302e-12 1.300e-12 3.600 2.200e-12 2.702e-12 1.700e-12 3.800 2.600e-12 3.102e-12 2.100e-12 4.000 3.000e-12 3.502e-12 2.500e-12 4.200 3.400e-12 3.902e-12 2.900e-12 4.400 3.800e-12 8.097e-12 3.300e-12 4.600 4.200e-12 1.913e-09 3.700e-12 4.800 4.600e-12 9.562e-07 4.100e-12 5.000 5.010e-12 2.333e-04 4.500e-12 [POWER_clamp] * Voltage I(typ) I(min) I(max) * -5.000 4.248e-02 4.355e-02 4.209e-02 -4.800 4.049e-02 4.157e-02 4.010e-02 -4.600 3.850e-02 3.958e-02 3.812e-02 -4.400 3.652e-02 3.760e-02 3.613e-02 -4.200 3.453e-02 3.562e-02 3.414e-02 -4.000 3.255e-02 3.363e-02 3.216e-02 -3.800 3.056e-02 3.165e-02 3.017e-02 -3.600 2.858e-02 2.968e-02 2.819e-02 -3.400 2.660e-02 2.770e-02 2.620e-02 -3.200 2.462e-02 2.572e-02 2.422e-02 -3.000 2.264e-02 2.375e-02 2.224e-02 -2.800 2.067e-02 2.177e-02 2.027e-02 -2.600 1.869e-02 1.981e-02 1.829e-02 -2.400 1.672e-02 1.784e-02 1.632e-02 -2.200 1.475e-02 1.588e-02 1.435e-02 -2.000 1.279e-02 1.392e-02 1.238e-02 -1.800 1.083e-02 1.197e-02 1.042e-02 -1.600 8.884e-03 1.002e-02 8.470e-03 -1.400 6.948e-03 8.093e-03 6.532e-03 -1.200 5.031e-03 6.180e-03 4.613e-03 -1.000 3.152e-03 4.297e-03 2.736e-03 -0.800 1.368e-03 2.474e-03 9.783e-04 -0.600 8.539e-05 8.266e-04 1.211e-05 -0.400 5.206e-08 2.019e-05 2.608e-09 -0.200 2.822e-11 4.277e-08 5.901e-12 0.000 5.010e-12 8.959e-11 5.500e-12 [End] ***s2ibis OUTPUTDECK ENDS HERE From Will_Hobbs@ccm2.jf.intel.com Fri Mar 11 15:01:12 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06487; Fri, 11 Mar 94 15:01:12 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 11 Mar 94 14:59:09 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Fri, 11 Mar 94 14:58:51 -0800 Received: from ccMail by jfsmt2.intel.com id AA763426738 Fri, 11 Mar 94 14:58:58 PST Date: Fri, 11 Mar 94 14:58:58 PST From: "Hobbs, Will" Message-Id: <9402117634.AA763426738@jfsmt2.intel.com> To: ibis@vhdl.org, huq@lightning.nsc.com (Syed Huq) Cc: huq@lightning.nsc.com Subject: Re: Meeting in May Syed, et al, Let me clarify what is happening in May and June. Rather than waste everyone's time, I wanted a steering committee of a few IBIS members to put together the proposed 2.0. This means rolling all of the Birds into a logical order, identifying conflicts and proposing resolutions, and adding it to the V1.1 spec, cleaning up any stuff that is no longer appropriate. We are not ratifying the spec at that time, but putting it together in readable and logical form so it can be reviewed by everyone. This is happening in May so that there will be 3+ weeks to review the roll-up and generate discussion on the reflector, so when we meet at DAC, we will be able to finalize the document and (hopefully) ratify it. Will Fellow members: In May, there will be a meeting to ratify all the BIRDS so IBIS2.0 can be released. What will be done during the DAC shows in June ? I am sure I can be in Oregon in May. Regards, Syed National Semiconductor Corp. From bob@icx.com Fri Mar 11 17:47:47 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07486; Fri, 11 Mar 94 17:47:47 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04141 for ; Fri, 11 Mar 94 20:42:00 -0500 Date: Fri, 11 Mar 94 17:33:41 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA04538; Fri, 11 Mar 94 17:33:41 PST Message-Id: <9403120133.AA04538@icx.com> To: ibis@vhdl.org Subject: S2IBIS FEEDBACK To IBIS committee and Steve Steve, your Spice to IBIS work and progress is very impressive. I now have several brief comments based on a quick review and an IBIS_CHK of your results. (1) Version 1.1 of IBIS requires that C_comp be defined for all models, and this shows up as an error in your example. After this is corrected, and a [RAMP] is inserted, your IBIS results pass IBIS_CHK. (2) In the DESCRIPTION section for the manual, you indicate that Open_drain omits the [POWER_clamp] table. This table can exist and should be inserted, if it exists, into Open_drain models. (3) In the INPUT FILE section, there needs to be a method to enter "vih" and "vil" for I/O models as well as Input. As a result of a Version 1.1 potential "oversite", This information is not checked by IBIS_CHK. In practice, it is a virtual requirement for timing analysis. Based on the writeup, it appears to be impossible to enter this information for I/O pins. Also, I notice that the Input models in your example do not contain the Vinh and Vinl information. Thank you for posting the results so quickly. Great Job!!! Bob Ross, Interconnectix, Inc. From bob@icx.com Sun Mar 13 19:57:04 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00546; Sun, 13 Mar 94 19:57:04 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA05862 for ; Sun, 13 Mar 94 22:46:09 -0500 Date: Sun, 13 Mar 94 19:43:59 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA08236; Sun, 13 Mar 94 19:43:59 PST Message-Id: <9403140343.AA08236@icx.com> To: ibis@vhdl.org Subject: May 20 Meeting To IBIS committee and Will and Derrick: I would prefer that the members be referred to as an "Editing Committee" rather than a "Steering Committee" which has some incorrect connotations of extra authority. Its purpose is to work collectively to edit the approved changes into a proposed Version 2.0 as a "cleaned up" starting point for IBIS Committee review. While the volunteers willing to travel to Portland and devote one day of editing have been identified, I am sure anyone who has a strong interest in coming would be welcome. Furthermore, if you have some "editorial" comments (corrections, confusion areas) you want addressed, please post them on the reflector so we do not loose this information. Bob Ross, Interconnectix, Inc. From bward@sugar.NeoSoft.COM Mon Mar 14 13:22:52 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02315; Mon, 14 Mar 94 13:22:52 PST Received: by sugar.NeoSoft.COM id AA08194 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 14 Mar 1994 15:20:13 -0600 Message-Id: <199403142120.AA08194@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: A clarification, please! Date: Mon, 14 Mar 94 15:19:58 CST A quick question ... how much text is allowed in the Disclaimer portion of an ibis model file? Some of our legal types seem to have stock in paper companies or something! Thanks in advance, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From Will_Hobbs@ccm2.jf.intel.com Mon Mar 14 13:40:52 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02507; Mon, 14 Mar 94 13:40:52 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 14 Mar 94 13:37:59 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 14 Mar 94 13:37:43 -0800 Received: from ccMail by jfsmt2.intel.com id AA763681067 Mon, 14 Mar 94 13:37:47 PST Date: Mon, 14 Mar 94 13:37:47 PST From: "Hobbs, Will" Message-Id: <9402147636.AA763681067@jfsmt2.intel.com> To: ibis@vhdl.org, bward@sugar.NeoSoft.Com (Bob Ward) Subject: Re: A clarification, please! Anything preceded by a comment character will be ignored by the parser. Will A quick question ... how much text is allowed in the Disclaimer portion of an ibis model file? Some of our legal types seem to have stock in paper companies or something! Thanks in advance, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bob@icx.com Mon Mar 14 15:47:32 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03431; Mon, 14 Mar 94 15:47:32 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04349 for ; Mon, 14 Mar 94 18:43:02 -0500 Date: Mon, 14 Mar 94 15:37:21 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10553; Mon, 14 Mar 94 15:37:21 PST Message-Id: <9403142337.AA10553@icx.com> To: ibis@vhdl.org Subject: Clarification Bob An "unlimited" amount of text can follow the [Disclaimer] keyword, at least enough to satisfy any legal eagle. Bob Ross, Interconnectix, Inc. From speters@ichips.intel.com Mon Mar 14 17:42:21 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04301; Mon, 14 Mar 94 17:42:21 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 14 Mar 94 17:40:24 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 14 Mar 94 17:40:06 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 14 Mar 94 17:40:16 PST Message-Id: <9403150140.AA27431@xtg801.intel.com> To: ibis@vhdl.org Subject: RE: BIRD 9.1 -- package connections Date: Mon, 14 Mar 1994 17:40:15 -0800 From: Stephen Peters Hello Bob, and Fellow IBISans -- Regarding BIRD 9.1, how do we specify what pins in a resistor package are the 'common' or associated pins? I'm thinking that when a simulator goes to parse a resistor model and put it into the target netlist the simulator needs to know the pins on the package relate to the resistors. Let me illustrate. Suppose we have a collection of pullup resistors in a 10 pin SIP as follows: 1 | | |------------------------ | | | | | | | | | R R R R R R R R R R R R R R R R R R R R R R R R R R R | | | | | | | | | | | | | | | | | | 2 3 4 5 6 7 8 9 10 How is one supposed to designate that pin 1 is the common pin? Would doing something like this work? [Pin] signal_name model_name 1 common POWER 2 R1 res1 3 R2 res1 . . . . . . The same question applies to a thevinen type resistor package. Does listing the two common pins as POWER and GND accomplish what we need? There is also a third case: straight thru resistor in a DIP or SIP pack. ____________ | | 1-----|---RRRR---|----14 2-----|---RRRR---|----13 3-----|---RRRR---|----12 . . . 7-----|---RRRR---|----8 |__________| How is the model going to tell the simulator that pin 7 is associated with pin 8, for example? To me it seems that, based on a keyword or model type, both the IBIS model and simulator have to assume some kind of topology for the resistor connections. What do you think? Best Regards, Stephen Peters Intel Corp. From bward@sugar.NeoSoft.COM Mon Mar 14 18:45:50 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04705; Mon, 14 Mar 94 18:45:50 PST Received: by sugar.NeoSoft.COM id AA05233 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 14 Mar 1994 20:43:24 -0600 Message-Id: <199403150243.AA05233@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Series resistance Date: Mon, 14 Mar 94 20:43:21 CST In following up on the discussion in the forum call about the series resistance, and the fact that it is actually a Silicon resistance, not a package resistance, I discovered that we actually use a highly non-linear resistor in this position, at least in some parts. In fact it is saturable such that as voltage increases, current only continues to increase up to a point. Thus it would seem that we need to be able to specify a table of values for this resistor, either an RV or an IV table. Probably an IV table makes more sense. Comments? Thanks,  ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bward@sugar.NeoSoft.COM Mon Mar 14 18:46:27 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04710; Mon, 14 Mar 94 18:46:27 PST Received: by sugar.NeoSoft.COM id AA05763 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 14 Mar 1994 20:44:02 -0600 Message-Id: <199403150244.AA05763@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Timing Date: Mon, 14 Mar 94 20:43:58 CST To all the ibis forum - In looking over some of the BIRDS before the last forum call, the question occured to me that if we are putting voltage thresholds into the input models for the sake of timing analysis ( which I agree with fully! ) should we also have, probably optional, annotation of the setup and hold times for clocked devices for the same purpose? If we view ibis models as some kind of "electronic data book", then it would seem natural to include these times, possibly under an optional [Timing] keyword. This would give enough data all in one place to flag violations. I doubt that there is enough data to assess the metastable behviour possible if the violation occurs, and I am not at all sure we want to put that much data in the model. It gets too much into the specifics of the circuitry, as well as not being particularly amenable to measurement apart from simulation. Does the forum feel this warrants a BIRD? Thanks,  ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From 71436.1314@CompuServe.COM Tue Mar 15 00:47:26 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07202; Tue, 15 Mar 94 00:47:26 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id DAA15665; Tue, 15 Mar 1994 03:45:27 -0500 Date: 15 Mar 94 03:43:04 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: V/I table validation method (from Kellee Crisafulli) Message-Id: <940315084304_71436.1314_HHB26-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx To: Jon Powel(Quad Design), Will Hobbs, IBIS forum Date: Monday, (March 15, 1994) RE: A method to determine if V/I tables in an IBIS model are entered with the correct current direction. HyperLynx has one customer that had it happen to him.... At least 2 semiconductor companies have had it happen.... Kellee had it happen to him at least once... Well ok, we were all bombed by the great IBIS bird. We all made the mistake of creating at least one V/I table with the wrong current direction. At the IBIS meeting last Friday we discussed this problem and had general agreement that the IBIS_CHK program should be modified very soon to detect this problem. I made a proposal for a method to detect the problem. Jon Powel volunteered to make the changes to the program. At the meeting we proposed a 3 step plan to get a quick update of the program completed: 1) Kellee submits his method to the general committee for comment Monday. 2) If by Friday there is a reasonable consensus that this approach is acceptable than Will Hobbs will give the go ahead to modify IBIS_CHK. 3) Jon Powel at Quad Design volunteered to make the changes to the master copies of IBIS_CHK and release them to the VHDL machine. The goal is two have it finished by the end of next week. 4) Everyone who is a paid IBIS member will have access to the source code. Everyone else will have access to the binary executable. Here is the method I am proposing to determine if an IBIS V/I table was entered in the correct direction. Please have your comments posted by Friday. (Thanks in advanced for your quick response). No response is considered accepting the proposal as is. For each V/I table: 1) Sort the V/I table into voltage order from most negative to most positive voltage. 2) Start at the most negative voltage point. 3) As you asend through the table count the number of times the TYPICAL current increases versus decreases. If there are more increases than the table has increasing current. If there are more decreases than the table has decreasing current. 4) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 5) If any table moves in the wrong direction flag as an error  From 71436.1314@CompuServe.COM Tue Mar 15 01:12:38 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07308; Tue, 15 Mar 94 01:12:38 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id EAA13985; Tue, 15 Mar 1994 04:10:41 -0500 Date: 15 Mar 94 04:08:04 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Commentary on Bob Wards suggestion: Message-Id: <940315090803_71436.1314_HHB2-2@CompuServe.COM> To: all the ibis forum From: Kellee Crisafulli, Hyperlynx Re: Bob Wards mail: Bob: In looking over some of the BIRDS before the last forum call, the question occured to me that if we are putting voltage thresholds into the input models for the sake of timing analysis ( which I agree with fully! ) should we also have, probably optional, annotation of the setup and hold times for clocked devices for the same purpose? If we view ibis models as some kind of "electronic data book", then it would seem natural to include these times, possibly under an optional [Timing] keyword. This would give enough data all in one place to flag violations. I doubt that there is enough data to assess the metastable behviour possible if the violation occurs, and I am not at all sure we want to put that much data in the model. It gets too much into the specifics of the circuitry, as well as not being particularly amenable to measurement apart from simulation. Does the forum feel this warrants a BIRD? Hello Bob. We have discussed this one before with the consensus at the time that this would extended IBIS into a much larger set of problems and complications. The goal of a full "DATA BOOK" specification for a device is a big one. The very next thing is a full functional description (boolean logic) and timing description. It explodes quickly. We have many many roads to travel to do really good job on basic signal integrity. For example we don't model turn-on and turn-off time of clamp diodes. For revision 2 and 3, I believe we should stick with creating signal integrity models. (Input/Output buffer information specification) For the future all things are possible.... Have a great day, Kellee From cpk@Cadence.COM Tue Mar 15 07:08:04 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11755; Tue, 15 Mar 94 07:08:04 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id HAA25029; Tue, 15 Mar 1994 07:06:06 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma025004; Tue Mar 15 07:05:14 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA25429; Tue, 15 Mar 94 06:52:34 -0800 Received: by hot (5.65+/1.5) id AA16030; Tue, 15 Mar 94 10:04:34 -0500 Date: Tue, 15 Mar 94 10:04:34 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9403151504.AA16030@hot> To: ibis@vhdl.org, bward@sugar.NeoSoft.COM Subject: Re: Timing > > To all the ibis forum - > > In looking over some of the BIRDS before the last forum call, the > question occured to me that if we are putting voltage thresholds into > the input models for the sake of timing analysis ( which I agree with > fully! ) should we also have, probably optional, annotation of the setup > and hold times for clocked devices for the same purpose? If we view > ibis models as some kind of "electronic data book", then it would seem > natural to include these times, possibly under an optional [Timing] > keyword. This would give enough data all in one place to flag > violations. I doubt that there is enough data to assess the metastable > behviour possible if the violation occurs, and I am not at all sure we > want to put that much data in the model. It gets too much into the > specifics of the circuitry, as well as not being particularly amenable > to measurement apart from simulation. Does the forum feel this warrants > a BIRD? > > Thanks, >  > ______________________________________________ ____________________ > | | Seeking to return to | / __________________O > | Bob Ward | the North Country, MN, | / /|________________ > | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O > | 713.568.4122 | considering Mtn. West. | /_____________________ > |___________________|_________________________| |_____________________O > I whole hearedly agree with Bob's view. It makes sense to have all the related data in one place. - kumar From Will_Hobbs@ccm2.jf.intel.com Tue Mar 15 08:26:26 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12227; Tue, 15 Mar 94 08:26:26 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 15 Mar 94 08:24:24 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 15 Mar 94 08:24:08 -0800 Received: from ccMail by jfsmt2.intel.com id AA763748659 Tue, 15 Mar 94 08:24:19 PST Date: Tue, 15 Mar 94 08:24:19 PST From: "Hobbs, Will" Message-Id: <9402157637.AA763748659@jfsmt2.intel.com> To: ibis@vhdl.org, Kellee Crisafulli <71436.1314@CompuServe.COM> Subject: Re: Commentary on Bob Wards suggestion: Ibisians, I tend to agree with Kellee. I think there are enough dragons to slay (birds to slay dragons, don't they?) in the signal integrity and flight time arenas. I fully support making IBIS a part of a larger electronic data sheet specification, but feel we should keep our present focus until we have reached a point of diminishing returns. If IBIS were to eventually grow into the electronic data sheet, that would be fine, but I hesitate to devote much time to that now. Will To: all the ibis forum From: Kellee Crisafulli, Hyperlynx Re: Bob Wards mail: Bob: In looking over some of the BIRDS before the last forum call, the question occured to me that if we are putting voltage thresholds into the input models for the sake of timing analysis ( which I agree with fully! ) should we also have, probably optional, annotation of the setup and hold times for clocked devices for the same purpose? If we view ibis models as some kind of "electronic data book", then it would seem natural to include these times, possibly under an optional [Timing] keyword. This would give enough data all in one place to flag violations. I doubt that there is enough data to assess the metastable behviour possible if the violation occurs, and I am not at all sure we want to put that much data in the model. It gets too much into the specifics of the circuitry, as well as not being particularly amenable to measurement apart from simulation. Does the forum feel this warrants a BIRD? Hello Bob. We have discussed this one before with the consensus at the time that this would extended IBIS into a much larger set of problems and complications. The goal of a full "DATA BOOK" specification for a device is a big one. The very next thing is a full functional description (boolean logic) and timing description. It explodes quickly. We have many many roads to travel to do really good job on basic signal integrity. For example we don't model turn-on and turn-off time of clamp diodes. For revision 2 and 3, I believe we should stick with creating signal integrity models. (Input/Output buffer information specification) For the future all things are possible.... Have a great day, Kellee From qdt!sal!jonp@uunet.UU.NET Tue Mar 15 08:45:23 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12571; Tue, 15 Mar 94 08:45:23 PST Received: from uucp6.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhiw02344; Tue, 15 Mar 94 11:43:24 -0500 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 15 Mar 1994 11:43:26 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00457; Tue, 15 Mar 94 08:21:02 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA27323; Tue, 15 Mar 94 08:21:01 PST Date: Tue, 15 Mar 94 08:21:00 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403151621.AA27323@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09489; Tue, 15 Mar 94 08:21:19 PST To: ibis@vhdl.org Subject: Timing Hey all, regarding set-up and hold times. Though the industry does need set-up and hold times (in general) I believe that we would be opening a can of worms were we to take this paritucalar aspect on. For instance: setup and hold only have meaning if you know the timing of the entire data path, the entire clock path, the relative skew between the start of the data and the clock etc. None of this information is calculable by any of the SPICE or Transmission line simulators I know of. (and though MOTIVE will do this it needs a lot of other data besides setup and hold). These timing numbers are usually available in standard databooks which other industry groups are in the process or "electronicizing" jonp From qdt!sal!jonp@uunet.UU.NET Tue Mar 15 09:46:08 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13058; Tue, 15 Mar 94 09:46:08 PST Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhja28530; Tue, 15 Mar 94 12:44:08 -0500 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 15 Mar 1994 12:44:11 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00579; Tue, 15 Mar 94 09:03:27 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA27607; Tue, 15 Mar 94 09:03:24 PST Date: Tue, 15 Mar 94 09:03:24 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403151703.AA27607@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09562; Tue, 15 Mar 94 09:03:43 PST To: uunet!CompuServe.COM!71436.1314@uunet.UU.NET Cc: ibis@vhdl.org In-Reply-To: Kellee Crisafulli's message of 15 Mar 94 03:43:04 EST <940315084304_71436.1314_HHB26-1@CompuServe.COM> Subject: V/I table validation method (from Kellee Crisafulli) Cases that will not work for proposed algorithm: V: I: 0.0 0.0 3.5 50.0 3.51 49.9 3.52 49.8 3.53 49.7 5.0 100.0 any OC any OD perhaps it should be the relative size of the changes and not the absolute number? Perhaps it should just be the absolute value at VCC. If current is possitve at VCC for a pulldown, then it cannot pulldown. If current is not negative at GND for the pullup then it cannot pullup? (except for ECL OC etc?). jonp From ccm!Arpad_Muranyi@intelhf.intel.com Tue Mar 15 10:40:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13514; Tue, 15 Mar 94 10:40:18 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pge0T-000MPQC; Tue, 15 Mar 94 10:38 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pge83-0000G2C; Tue, 15 Mar 94 10:46 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 15 Mar 94 10:46:11 PST Date: Tue, 15 Mar 94 10:46:11 PST From: Arpad Muranyi Message-Id: <940315104611_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: V/I table validation method (from Kellee Crisafulli) ---------------------------- Forwarded with Changes --------------------------- From: 71436.1314@CompuServe.COM at Internet_Gateway Date: 3/15/94 12:58AM To: Don A Telian at FMCCM4 To: Arpad Muranyi at FMCCM4 *To: Tim A Schreyer at JFCCM7 *To: ibis@vhdl.org at Internet_Gateway Subject: V/I table validation method (from Kellee Crisafulli) ------------------------------------------------------------------------------- What happens if there are equal number of increases and decreases in a curve? Most of the curves I am generating lately do that and I do not think I am doing it wrong. Arpad From: Kellee Crisafulli, HyperLynx To: Jon Powel(Quad Design), Will Hobbs, IBIS forum Date: Monday, (March 15, 1994) RE: A method to determine if V/I tables in an IBIS model are entered with the correct current direction. HyperLynx has one customer that had it happen to him.... At least 2 semiconductor companies have had it happen.... Kellee had it happen to him at least once... Well ok, we were all bombed by the great IBIS bird. We all made the mistake of creating at least one V/I table with the wrong current direction. At the IBIS meeting last Friday we discussed this problem and had general agreement that the IBIS_CHK program should be modified very soon to detect this problem. I made a proposal for a method to detect the problem. Jon Powel volunteered to make the changes to the program. At the meeting we proposed a 3 step plan to get a quick update of the program completed: 1) Kellee submits his method to the general committee for comment Monday. 2) If by Friday there is a reasonable consensus that this approach is acceptable than Will Hobbs will give the go ahead to modify IBIS_CHK. 3) Jon Powel at Quad Design volunteered to make the changes to the master copies of IBIS_CHK and release them to the VHDL machine. The goal is two have it finished by the end of next week. 4) Everyone who is a paid IBIS member will have access to the source code. Everyone else will have access to the binary executable. Here is the method I am proposing to determine if an IBIS V/I table was entered in the correct direction. Please have your comments posted by Friday. (Thanks in advanced for your quick response). No response is considered accepting the proposal as is. For each V/I table: 1) Sort the V/I table into voltage order from most negative to most positive voltage. 2) Start at the most negative voltage point. 3) As you asend through the table count the number of times the TYPICAL current increases versus decreases. If there are more increases than the table has increasing current. If there are more decreases than the table has decreasing current. 4) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 5) If any table moves in the wrong direction flag as an error  From bob@icx.com Tue Mar 15 17:36:39 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16849; Tue, 15 Mar 94 17:36:39 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA00409 for ; Tue, 15 Mar 94 20:16:29 -0500 Date: Tue, 15 Mar 94 17:15:43 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA14256; Tue, 15 Mar 94 17:15:43 PST Message-Id: <9403160115.AA14256@icx.com> To: ibis@vhdl.org Subject: BIRD9 AND RSERIES COMMENTS To IBIS Committee and Stephen Peters and Bob Ward Stephen, you have raised a very significant point in asking the question "How do we specify what pins in a resistor package are the 'common' or associated pins?" Secondly, you raised some questions on how to connect a straight thru resistor in a DIP or SIP pack. The simple answer is that IBIS Version 1.1 and proposed extensions including BIRD9.1 DO NOT FULLY support "associating" a [Model] of one pin to any other pin, even if that pin is a POWER or GND pin. The connectivity function is EXTERNAL to IBIS. In fact, all of the POWER and GND pins can be removed from any [Component], and it will still pass IBIS_CHK On one hand it would be nice to enlarge IBIS to include power connectivity information to pass into the [Model]. Other types of net connectivity might also be nice, but may actually be less applicable for long trace connection problems where the geometrical layout is the dominant consideration, not just the connectivity. For example, a DIP or SIP resistor pack series terminator may be designed with matching pin alignment to a driver component to be connected to AND positioned next to the driver. The partial solution [RSERIES] terminator proposal in BIRD9.1 is intended for that situation as a minimal cost APPROXIMATION of a series terminator by positioning it in series with R_pin in the driver [Model]. As Will Hobbs pointed out last Friday, the package elements may distort the analysis because this series element is on the wrong side of the package. However, the dominant consideration is that it provides a termination to a long net and the degradations may be second order relative to the overall analysis. In general, IBIS itself does not provide arbitary connection mechanisms of any [Component] in a netlist specification sense. It just provides the [Pin] interface through which connections can be made external to IBIS to ONE pin which has a [Model]. Extentions to IBIS either through [Model] or another [Pin_Mapping]_type table could be considered to handle specific straight thru resistor topologies within packages. Perhaps other elements could be handled as well. With respect to [Model], the [Voltage reference], GND, and optional other reference voltages (e.g., [POWER_CLAMP reference] per BIRD 3) provide a set of Voltages which can be used as rails to reference the VI data tables and [Ramp]. So, for simulation, an internal model can be constructed with respect to these specified VOLTAGES. The proposed [Rgnd] and [Rpower] elements would also be connected to VOLTAGES. Any assignment of these VOLTAGES to the [COMPONENT] pins for POWER and GND is done EXTERNAL to IBIS. In specific cases with one POWER and one GND, one can assume a connection. Through such a connection, one could override the internal reference voltages with externally applied voltages. The [Pin_Mapping] keyword per BIRD5.2 offers another opportunity to do pin association. It may work very well for resistor packs used as terminators to "gnd" or to "pwr", or resistor packs with parallel terminators to both "gnd" and "pwr" to associate through the GNDBUS or PWRBUS names the [Model] connection and the rails. To date, this keyword is optional and cannot be guarenteed to be provided in the [Component]. Furthermore, this keyword would have to be expanded by two columns to include the multiple rail connection possiblities that exist per BIRD3 to fully support connections of I/O and Output Models to any of the supply pins. For example, the [Pullup] may be referenced to the 3.3V rail, but the [POWER_clamp] may be referenced to the 5V rail. Bob, regarding a non-linear internal series resistance, my first approach would be to try to absorb it or at least the non-linear portions of it into the [PULLUP] and [PULLDOWN] tables as a first order APPROXIMATION to its effect. There may be some absortion in to the clamping tables as well. I would hope to avoid if possible the need for another set of VI tables, especially one that may be hard to extract. Thank you for the comments in these areas. I feel I have just touched the surface of some larger issues. Bob Ross Interconnectix, Inc. From 71436.1314@CompuServe.COM Tue Mar 15 22:33:05 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19001; Tue, 15 Mar 94 22:33:05 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id BAA29679; Wed, 16 Mar 1994 01:31:07 -0500 Date: 16 Mar 94 01:28:24 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL , Arpad Muranyi , Jon Powell Subject: V/I table checking (from Kellee Crisafulli) Message-Id: <940316062823_71436.1314_HHB56-1@CompuServe.COM> To: Jon Powel, Arpad, IBIS commitee From: Kellee Crisafulli Re: method to determine if V/I table is valid Good point Jon and Arpad. I had negelected to considered noise from systems where the data is being sampled with a data acquisition system. (oops) Several things make it difficult to test for the wrong sign: - The data can change direction and be valid. - Only 2 points are required to have a valid table. - No particular voltage points are required. (there may or may not be data points at VCC or ground). I have a new simplified method based on Jon's suggestion that should also work with Arpad's data: For each V/I table: 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The TYPICAL current corresponding to Vmax is less than the TYPICAL current corresponding to Vmin than the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. 3) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 4) If any table moves in the wrong direction flag as an error 5) Another test we could consider is if the currents at Vmin and Vmax are equal then assume the data is a single point and thus invalid. (This may already be tested I don't recall). I would still like to get agreement on this by Friday if possible. Here's hoping this IBIS_CHK egg is not broken,scrambled, or stolen by the big bad wolf. Have a great day... Kellee From Will_Hobbs@ccm2.jf.intel.com Tue Mar 15 23:16:55 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19263; Tue, 15 Mar 94 23:16:55 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 15 Mar 94 23:14:57 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 15 Mar 94 23:14:42 -0800 Received: from ccMail by jfsmt2.intel.com id AA763802108 Tue, 15 Mar 94 23:15:08 PST Date: Tue, 15 Mar 94 23:15:08 PST From: "Hobbs, Will" Message-Id: <9402157638.AA763802108@jfsmt2.intel.com> To: bob@icx.com ( Bob Ross), ibis@vhdl.org Subject: May 20 Meeting Bob, Your points are well taken. Editing Committee it is. And, yes, this is not restricted to those who already volunteered. Anyone that enjoys editing stuff and making it more logical and comprehensible, and wants to visit Portland in May, is welcome. The output of this committee will be posted to the reflector for general comment and review before the DAC session, so nothing will be final until everyone has had a chance to make their opinions known. Will To IBIS committee and Will and Derrick: I would prefer that the members be referred to as an "Editing Committee" rather than a "Steering Committee" which has some incorrect connotations of extra authority. Its purpose is to work collectively to edit the approved changes into a proposed Version 2.0 as a "cleaned up" starting point for IBIS Committee review. While the volunteers willing to travel to Portland and devote one day of editing have been identified, I am sure anyone who has a strong interest in coming would be welcome. Furthermore, if you have some "editorial" comments (corrections, confusion areas) you want addressed, please post them on the reflector so we do not loose this information. Bob Ross, Interconnectix, Inc. From bward@sugar.NeoSoft.COM Wed Mar 16 04:57:14 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23711; Wed, 16 Mar 94 04:57:14 PST Received: by sugar.NeoSoft.COM id AA27614 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 16 Mar 1994 06:54:24 -0600 Message-Id: <199403161254.AA27614@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: More on series R Date: Wed, 16 Mar 94 6:54:21 CST Kellee - You both did and didn't miss something :-). From the picture given with the proposal for series resistance, it is the bond wire, pin, bond pad, and bond lead resistance lumped into one and added in series with the leadframe. But in the course of discussion it was mentioned that this was intended to be a silicon resistance or an element resistance in the case of a through resistor pack. That got me thinking about the series resistance we use as part of some of our ESD networks that appears exactly in series with the output lead, between the bond pad and the output transistor ( pair ). In that case the resistor is saturable in the sense that the voltage across it continues to increase, but the current through it limits at some value. Thus the resistance is a function of the voltage between the pin, neglecting leadframe and bondwire drop, and the output point of the driver circuit. Our situation is somewhat as follows: -----+-----Vcc | |_| | |---o| | |_ | | | | | | Vdrop | | | |<------>| ------| +-----/\/\/\------ Output pin | | Rseries | | I| . . . | |_| | . | | | |----| | . |_ | . | | |. | |___________________ ------+-----Vss Vdrop Where the IV curve is that of Vseries. A similar situation exists on input pins. Now I have thought about whether or not this non-linearity would be captured as part of the normal driver IV curve, and so far have built about an equal case in my mind that it will and that it won't. I lean toward the notion that it will. In that case, the whole thing is a moot point anyway. According to my mail, Bob Ross is also coming down on this side of the question, which DOES add fuel to that fire. But if it be not correctly captured, then perhaps there is a problem here that needs to be addressed. I plan to ask my trusty Spice simulator about it tomorrow ( probably today as you read this ). Yes, there is, in theory some temperature effect on the resistance, but the effect of importance is the voltage dependence rather than temperature or some even more exotic effect. Now I ask the forum for the advice of collective wisdom ... should this be dealt with as a separate element in the ibis model when the information to do so is available, or should it lumped into the driver IV curve? Or should that question wait until this evening after some simulation experiments? :-) ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bward@sugar.NeoSoft.COM Wed Mar 16 04:58:00 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23716; Wed, 16 Mar 94 04:58:00 PST Received: by sugar.NeoSoft.COM id AA27652 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 16 Mar 1994 06:55:06 -0600 Message-Id: <199403161255.AA27652@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Re: Sign of current Date: Wed, 16 Mar 94 6:55:05 CST Kellee and all the rest - I think the proposed method of current sign determination might run into trouble in at least two cases. One is when there are exactly the same number of rising and falling segments, which could happen quite easily, and the other is the same problem one runs into testing for monotonicity of the independent variable. That problem is that very small oscillations occur on the "flat" part of a numerically generated curve, not so much because they are real, but because of the nature of small numbers, finite precision, and floating point round off. It is almost impossible to do enough smoothing to get rid of this effect without destroying the shape of the curve in more "normally behaving" regions. These oscillations would very possibly lead to false conclusions. I think it better, read more reliable, to test the slope of the straight line between the zero volt, or therabouts, current and the rail voltage, or thereabouts, current. ( It is likely that there will not be a point at EXACTLY 0 or rail voltage. ) And now that I think about it again, this ought to work for ECL also, with the terms 0 and rail redefined as appropriate. That should tell at a glance if we are looking at a pull up or pull down curve, and the sign of the current can be adjusted accordingly.  ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bward@sugar.NeoSoft.COM Wed Mar 16 05:00:03 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23750; Wed, 16 Mar 94 05:00:03 PST Received: by sugar.NeoSoft.COM id AA27694 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 16 Mar 1994 06:57:10 -0600 Message-Id: <199403161257.AA27694@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Re: sample / hold times Date: Wed, 16 Mar 94 6:57:09 CST Fellow ibis folk-- The context of my question about setup and hold time is this ... if we are including high and low thresholds "for the purpose of timing analysis", we are including only a small part of what is needed. Yes, these data points are needed to know where to measure times from and to, but we can do nothing with them after measuring them without something to compare them to. So it seems that if ibis models are not to get into the timing arena then we do not need high and low thresholds on input models, either. That data would be supplied from the data book just as would the setup and hold times to compare against. My point is that if we are going to put in something for timing analysis, lets put in enough to make it truly useful, or else leave it all out. I appreciate the points about having enough to do to get SI simulation right, but if the model we are building is to be useful also for timing analysis, as put forth in Bird 2.1, then we should put in enough to make it fully useful. Otherwise we still have to get half of what we need from another source. I am well aware that there are still other things needed to calculate the time of arrival of pulses at pins, not the least of which is the transit time along traces, skew of pulse launching, etc. but that is a function of a different model than ibis, and is simply something more that must be supplied to the simulator. Likewise there is more to a spice model than transistors, but we try to capture all the data about the transistors in a small set of models, all in one place. I am seeking the analogous situation here of enough data in one place to be usefulin its own right. I agree that carried to it logical extreme, this could go on forever. That is not what I am proposing. But likewise lets not put a tiny part of what's needed in and then claim to be able to do timing analysis with it, either. ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From qdt!sal!jonp@uunet.UU.NET Wed Mar 16 09:16:22 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25657; Wed, 16 Mar 94 09:16:22 PST Received: from uucp1.uu.net (via uucp1-le1.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhmq08994; Wed, 16 Mar 94 12:14:01 -0500 Received: from qdt.UUCP by uucp1.uu.net with UUCP/RMAIL ; Wed, 16 Mar 1994 12:14:10 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00560; Wed, 16 Mar 94 08:16:17 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA01426; Wed, 16 Mar 94 08:16:16 PST Date: Wed, 16 Mar 94 08:16:16 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403161616.AA01426@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA11201; Wed, 16 Mar 94 08:16:35 PST To: ibis@vhdl.org Subject: committee name I agree with the suggestion to call the May committee the "God-like assembly that can make no error" jonp From qdt!sal!jonp@uunet.UU.NET Wed Mar 16 11:18:33 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26516; Wed, 16 Mar 94 11:18:33 PST Received: from uucp4.uu.net (via uucp4-le1.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhmz15878; Wed, 16 Mar 94 14:16:13 -0500 Received: from qdt.UUCP by uucp4.uu.net with UUCP/RMAIL ; Wed, 16 Mar 1994 14:16:19 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00694; Wed, 16 Mar 94 10:01:46 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA01769; Wed, 16 Mar 94 10:01:45 PST Date: Wed, 16 Mar 94 10:01:45 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403161801.AA01769@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA11235; Wed, 16 Mar 94 10:02:04 PST To: uunet!sugar.NeoSoft.Com!bward@uunet.UU.NET Cc: ibis@vhdl.org In-Reply-To: Bob Ward's message of Wed, 16 Mar 94 6:57:09 CST <199403161257.AA27694@sugar.NeoSoft.COM> Subject: sample / hold times re: usefull timing data. Quad Design manufactures two main products, A transmission line simulation tool (XNS) and a static timing verification tool (MOTIVE). We have been in the business for about 7 years now of supplying 1) SI information and 2) timing data. We have found that the information you need in the SI tool inorder to provide usefull information to the Timing tool are: Input Thresholds and VM delay correction. The rest of the timing data is needed by the Timing tool but is not used in any context by the SI tool, while the SI tool CANNOT PROVIDE ADEQUATE data to the TIMING tool without information about input logic thresholds. my point, Input thresholds are necessary for SI models to be able to provide the required pin-to-pin delay data to Timing. VM correction is a really sticky wickett. This involves correcting for the manner that the manufacturer measured and specified internal part delay (usually driving a 50pf load). It is a nice thing to have but can usually be approximated or calculated on the fly by the SI tool. regards, jon From ccm!Derrick_Duehren@intelhf.intel.com Wed Mar 16 12:09:25 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26940; Wed, 16 Mar 94 12:09:25 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ph1sF-000MPGC; Wed, 16 Mar 94 12:07 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ph1zy-0000XxC; Wed, 16 Mar 94 12:15 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Mar 94 12:15:26 PST Date: Wed, 16 Mar 94 12:15:26 PST From: Derrick Duehren Message-Id: <940316121526_8@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Gregg_Fortner@ccm.hf.intel.com Subject: 3/16/94 IBIS Participation Roster Text item: Text_1 ============================================================================ IBIS Open Forum Participation Roster As of 3/16/94 (updated periodically) Submit changes/updates to: Derrick Duehren, Intel Corp. Derrick_Duehren@ccm.jf.intel.com (503) 696-4299, Fax (503) 696-4904 ============================================================================ Anacad Contact: Steffen Rochel Email: sr@anacad.de Phone: +49 (731) 9545414, FAX: +49 (731) 9545450 Address: Helmholtzstr.20 89081 Ulm Germany Support: Anacad can translate IBIS descriptions into models using their analog behavioral modeling language HDL-A. Together with Eldo and a VHDL simulator, highly accurate investigations of mixed signal designs are then possible. Ansoft Corporation Contact: Henri Maramis Email: maramis@ansoft.com Phone: (412) 261-3200, Fax: (412) 471-9427 Address: 4 Station Square, Suite 660 Pittsburgh, PA. 15219 Support: Work is in progress to support IBIS models/library in native file/format. Atmel Corporation Contact: Dan Terry Email: Phone: (408) 436-4346, Fax: (408) 436-4200 Address: Support: Cadence Design Systems, Inc. Contact: C. Kumar Email: cpk@cadence.com Phone: (508) 262-6481 Phone: (508) 262-6488, Fax: 508-262-6600 Address: 270 Billerica Rd, Chelmsford, MA 01824 Support: Cadence fully supports IBIS behavior models at the I/O cell and package levels. Customers can convert IBIS 1.1 files to Cadence library format by using translator program IBIS2Cadence Contec Microelectronics USA Inc. Contact: Maah Sango, Clark Cochran Email: maah@contec.com Phone: (408) 434-6767, Fax: (408) 434-6884 Address: 2188 Bering Drive San Jose, CA 95131 Support: A Contec product will support IBIS models in native mode. Digital Equipment Corp. Contact: Barry Katz Email: katz@decsim.enet.dec.com Phone: (508) 568-6016 Address: 77 Reed Road, HLO2-2/H13 Hudson, MA 01749 Support: Digital is interested in generating IBIS models for some of its components and supporting these and other IBIS models in our in-house simulation tools. High Design Technology Contact: Michael Smith Email: Phone: Address: Support: HyperLynx Contact: Kellee Crisafulli Email: 71436,1314@compuserve.com Phone: (206) 869-2320, Fax: (206) 881-1008 Address: P.O. Box 3578 Redmond, WA 98073-3578 Support: The Linesim Pro product supports IBIS as follows: 1) Any IBIS file can be used directly as a 'NATIVE' file (Version 3.0 or newer). 2) A single model in an IBIS file can selected, loaded, and viewed directly. 3) Several IBIS models can be included in a single file and used as a library. Note: this library file still complies completely with the IBIS specification and can be checked with the IBIS check program. IBM Corp. Contact: (unofficially) Joseph C. (Jay) Diepenbrock Email: jayd@ralvm29.vnet.ibm.com Phone: (919) 543-8804 Address: IBM Network Hdwe. Div. Transceiver Technology Dev't, D63/061 P. O. Box 12195 Research Triangle Park, NC 27709 Support: No formal declaration of support. IBM-Motorola (PowerPC) Contact: Lynn Warriner, Hoa Quoc Email: Phone: Address: Support: Integrity Engineering, Inc. Contact: Greg Doyle Email: gdoyle@intgrty.mn.org Phone: (612) 636-6913, Fax: (612) 631-2241 Address: 1306 W. Country Rd. F, Suite 100 St. Paul, MN 55112 Support: The Integrity Simulators and Parasitic Extractor tools, SImnet, SImnet X, and Autospice are shipped with an IBIS2IEI translation program that enables any IBIS file to be directly converted for use with the simulator or SPICE extractor. The next revisions of IEI programs, slated for delivery 2Q '94, will support IBIS models in native mode. A utility will be provided to read, edit, and view IBIS files directly. Intel Corporation Contact: Will Hobbs Email: Will_Hobbs@ccm2.jf.intel.com Phone: (503) 696-4369, Fax: (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel Interconnectix, Inc. Contact: Bob Ross Email: bob@icx.com Phone: (503) 684-6641, Fax: (503) 639-3469 Address: 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Support: Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. Intergraph Corp. Contact: Ian Dodd, David Wiens Email: idodd@ingr.com, dwiens@ingr.com Phone: (303) 581-2300 Address: 6101 Lookout Road, Suite A Boulder, CO 80301 Support: IntuSoft Contact: Charles Hymowitz Email: Phone: (303) 833-0710 Address: Support: IntuSoft takes a customer's netlist or model and translates it into a Spice model, free of charge. IntuSoft has the Golden Parser source but hasn't, as of yet, automated the process. IntuSoft is waiting until there are more IBIS models available. Logic Modeling Corp./Synopsys Inc. Contact: Randy Harr Email: randyh@lmc.com Phone: (408) 945-9181 Address: 1520 McCandless Dr. Milpitas, CA 95035 Support: None at this time Mentor Graphics Corp. Contact: Ravender Goyal Email: Ravender_Goyal@mentororg.com Phone: Address: 8005 SW Boeckman Rd. Wilsonville, OR 97070-7777 Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Meta-Software Contact: John Sliney, Mei Wong Email: johns@metasw.com, mei@metasw.com Phone: (408) 369-5446, (408) 371-5100 Address: 1300 White Oaks Rd. Campbell, CA 95008 Support: MicroSim Corp. Contact: Arthur Wong Email: Phone: (714) 770-3022, FAX: (714) 455-0554 Address: 20 Fairbanks Irvine, CA 92718 Support: MicroSim can automatically generate PSpice models for vendors who provide data in a file format conforming to the IBIS Ver 1.1 specification. The models can then be simulated with PSpice. MicroSim has made IBIS models for Intel's Pentium processor 82430 PCIset available to customers. National Semiconductor Corp. Contact: Syed Huq Email: huq@rockie.nsc.com Phone: (408)721-4874, Fax:(408)721-4785 Address: 2900 Semiconductor Drive M/S E-200 Santa Clara, CA 95052 Support: National Semiconductor is willing to write some IBIS files and see how they work with a simulator of choice. North Carolina State University Contact: Michael Steer, Paul Franzon, Steve Lipa Email: mbs@ncsu.edu paulf@ncsu.edu slipa@eos.ncsu.edu Phone: 919-515-5191 919-515-7351 919-515-3947 FAX for all three: 919-515-5523 Address: ECE Dept. Box 7911 NC State Univ. Raleigh, NC 27695-7911 Support: (as of 2/94) A Spice to IBIS converter is being developed. A measurement based procedure is being developed for extracting IBIS models. A yacc/lex parser for IBIS models is being develped. All software and techniques will be put in the public domain. Performance Signal Integrity, Inc. Contact: Eric Bracken Email: bracken@performance.com Phone: (412) 682-7101, Fax: (412) 682-7178 Address: 4618 Henry St. Pittsburgh, PA 15213 Support: PSIBoards will accept IBIS V1.1 (ibis_chk compatible) model files directly. The IBIS files can contain any number of models or components. Instances of these models can be declared in the input deck, along with interconnections, to describe a complete design. Quad Design Technology, Inc. Contact: Jon Powell Email: jonp@qdt.com Phone: (805) 988-8250 Address: 1385 Del Norte Rd. Camarillo, CA 93010 Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and will be generally distributed with the XTK 5.2 release (available in Feb. 1994). Quantic Laboratories, Inc. Contact: Mike Ventham, Zhen Mu Email: ventham@quantic.mb.ca, mu@quantic.mb.ca Phone: (204) 942-4000, Fax: (204) 957-1158 Address: 12th Floor, 191 Lombard Ave Winnipeg, Manitoba, R3B 0X1 Canada Support: Quantic will be providing an IBIS reader (based on the Golden Parser) that will read IBIS models and automatically generate data files for Phidias (our graphical VI curve device modellor) and database files that associate the component definitions with the pin models. From Phidias, both SPICE models for Greenfield Phyllis (our PHYsical Load and Line Simulator) and models for BoardScan, (our PC board scanner for signal integrity and crosstalk) can be created. The release date has not been set yet. An application note is available regarding using IBIS models with Phidias. Racal-Redac Systems Ltd. Contact: John Berrie Email: johnb@redact.co.uk Phone: +44 684 294161, Fax: +44 684 299754 Address: Tewkesbury Gloucestershire GL20 8QL, England Support: Work is in progress to enable use of IBIS models in native format for Redac High-Performance Engineering and EMC Adviser products. In addition, integration with Quad Design and Quantic products provides the stated level of support provided by these companies. Siemens Nixdorf Contact: Werner Rissiek, Olaf Rethmeier Email: wr@cadlab.cadlab.de, olaf@cadlab.cadlab.de Phone: ++49-5251-284-155, ++49-5251-284-222, Fax: ++49-5251-284-105 Address: Siemens Nixdorf Informationssysteme AG Cadlab / Analog System Engineering Bahnhofstrasse 32 D-33102 Paderborn, Germany Support: Siemens Nixdorf uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. Siemens Nixdorf can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. Siemens Nixdorf uses an IBIS parser, developed by Siemens Nixdorf, and a semi-automatic process for the parametrization of the FREACS macromodels. The translation of IBIS to FREACS is available as a service for customers. A fully automated process will be developed when there are more IBIS models available. Additionally, so called 'reference lists' are set-up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit informations in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS-informations, as well. In this way a controlled set-up of a library is possible using IBIS-files as basis. Detailed information will be available on request. Texas Instruments Contact: Bob Ward Email: bward@dadhb1.ti.com Phone: (713) 274-4146, Fax (713) 274-3911 Address: Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Zeelan Technology, Inc. Contact: Hiro Moriyasu, George Opsahl Email: zeelan@netcom.com Phone: (503) 520-1000 Address: 10550 SW Allen Blvd. Beaverton, OR 97005 Support: Zeelan Tech. provides a modeling service that characterize and creates models conforming to the IBIS format. Zeelan Tech. MasterModel(TM) models are created from measurements of physical devices using a tightly controlled high-frequency fixture and modeling system. These models closely represent actual device behaviour when used in simulation. From ccm!Derrick_Duehren@intelhf.intel.com Wed Mar 16 12:09:51 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26945; Wed, 16 Mar 94 12:09:51 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ph1sg-000MPGC; Wed, 16 Mar 94 12:07 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ph1wr-000084C; Wed, 16 Mar 94 12:12 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Mar 94 12:12:13 PST Date: Wed, 16 Mar 94 12:12:13 PST From: Derrick Duehren Message-Id: <940316121213_4@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Randy_L_Wilhelm@ccm.hf.intel.com, Gregg_Fortner@ccm.hf.intel.com, Jerry_Budelman@ccm.hf.intel.com Subject: 3/11/94 IBIS Meeting Minutes Text item: Text_1 Date: March 16, 1994 From: Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager (Will Hobb's IBIS Assistant) Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Will Hobbs (503) 696-4369, fax (503) 696-4210 Intel Modeling Manager Subject: Minutes from IBIS Open Forum 3/11/94 To: Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran, Mike Venthon* Digital Equipment Corp. Barry Katz* High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* IBM Jay Diepenbrock IBM-Motorola alliance Lynn Warriner, Hoa Quoc*, John Burnett Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens* IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong, Mei-Ling Wei MicroSim Arthur Wong, Jerry Brown, Graham Bell National Semiconductor Syed Huq* North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa* Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell* Quantic Labs Mike Ventham*, Zhen Mu Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the 2/18/94 meeting are indicated by * Upcoming Meetings: Date: Bridge: Res: 4/1/94 (415) 904-8944 661905 4/22/94 TBD 5/13/94 TBD 6/3/94 TBD 6/24/94 TBD All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. Please note: If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org) send e-mail to ibis-request@vhdl.org. ------------------------------------------------------------------------------ 3/11/94 Meeting Agenda ---------------------- 8:00 Check-in Intros of new IBIS participants Hobbs Review of 2/18/94 minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues (reshuffle last 5 items?) All Treasurer's Report Hobbs Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 Ratification Hobbs - DAC Conference 6/6 - 6/10 - Steering Committee (5/20? Who? Where?) IBIS Cookbook Hobbs Spice-to-IBIS Converter Lipa (NCSU) 8:30 Stnd. driver, quality of support, validation Hobbs, All BIRD 8, Spec. of V/I data monotonicity Crisafulli BIRD 9, Other model types Ross BIRD 2, VIH, VIL Thresholds for Inputs Powell Egg 1, mutual pin coupling (ready to hatch?) Bracken 9:00 Simulation temperatures (new BIRD?) Warriner Ramp measurement Reid, Ross, et. al. Egg 2, ramp table? Hobbs 9:30 Canright paper Ward Formal BNF notation (BIRD?) Reed, Harr High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs Minutes ------- 1. Intros of new IBIS participants New participants: None. There were no corrections made to last month's minutes. Several open ARs (attention required) are rolled into this meeting minutes. 2. Miscellany/Announcements No new announcements. 3. Opens for new issues (reshuffle last 5 items?) Kellee: A large number of new people are creating IBIS models. Nearly all have put the sign in wrong in at least one of the V/I tables (both diode and pull- up/pull-down tables). Most of the errors are simple mistakes. We need a quick update to the IBIS check program to check for correct polarity in these tables. Kellee then made a proposal for checking these tables and issuing a warning message. Jon Powell offered to change the parser, Kellee outlined how to do it. It involves sorting the data and analyzing for polarity. AR Kellee: Write an emergency BIRD for the change. Approval will be attempted by the reflector within 1 week. AR Will: Administer the voting on the emergency BIRD. AR Jon: Make the change to the parser, once the BIRD is approved by the forum and pass it to Will Hobbs for distribution to those who have already paid for the parser source code. (Note: Will is uncomfortable with posting the encrypted source to vhdl.org. Will's address is: US Mail: Private Mail Delivery (FedEx): Will Hobbs Will Hobbs M/S JF1-57 M/S JF1-57 5200 NE Elam Young Pkwy 2111 NE 25th St. Hillsboro, OR 97124 Hillsboro, OR 97124 Jon heard that the RS6000 version of Golden Parser doesn't work, but the update is that it was cockpit error. 4. Treasurer's Report Will has inquired with the Intel legal dept. regarding the Tax ID issue and is waiting for a response. A check for the golden parser is pending, waiting for the Tax ID. Another check has arrived for the GP. Will wants approval from the buyer before mentioning who it is. 5. Press updates In the IEEE Spectrum publication, Pg. 54 of March issue; there is an article on managing EMI by Ravender Goyal that references IBIS and most of the participating companies. 6. Progress toward enlisting new IC vendors Will noted that he is seeing more IC vendors being added to the IBIS reflector. Jon: First-try PowerPC IBIS models have been received. Hoa Quoc: PowerPC IBIS model is available now and he can post them to vhdl.org. AR Derrick/Randy: send instructions for posting IBIS models to vhdl.org. Bob Ward: TI is getting closer, IBIS is a "good thing". Full buy-in should come soon. Syed: In process of convincing National Semiconductor upper management, but may have to wait for 2.0 for differential support before they can implement. Barry: Just a matter of time for Digital. The IBIS cookbook is needed. Will: The Intel DX4(TM) processor now has a public IBIS model; also several Intel960(TM) family IBIS models are publicly available. Will is working to get Pentium(TM) family of processors available, but it may take a while. Will and Derrick will be putting the new Intel models on vhdl.org. Another set of chipset IBIS models should be coming soon. 7. IBIS 2.0 Ratification - DAC Conference 6/6 - 6/10 After discussing the potential schedule of the conference, we decided to have Jon and Derrick decide on the two days and post them soon so travel plans can be made. AR Derrick and Jon: Decide and post. - Steering/Editing Committee (5/20? Who? Where?) Bob Ross, Stephen, Kellee, Jon, Will, Syed volunteered to participate May 20, in Portland, OR. It is open to anyone that enjoys editing stuff and making it more logical and comprehensible, and wants to visit Portland in May. The output of this committee will be posted to the reflector for general comment and review before the DAC session, so nothing will be final until everyone has had a chance to make their opinions known. AR Derrick: Make arrangements for May 20 meeting. 8. IBIS Cookbook Intel's internal Cookbook is nearly complete. We have an Intel tech writer (Robin R.) available for 1 week to create a generic base document from which the forum can build. Should be avail in 4 wks. Kellee will review. 9. Spice-to-IBIS Converter Steve Lipa: In holding mode with SPICE-to-IBIS converter because SPICE wasn't working on Sun and RS6000 workstations until yesterday. They want to hold off until it is tested on all major platforms. All development is done on DEC 2100's and 3100's. Steve is writing Man pages and has added all min/max tables except ramp table. (Steve wants feedback before doing ramp table.) AR Steve: Post the Man page drafts for forum review. (Done) Steve has Berkeley SPICE version 3 and version 4, and has not tried any proprietary versions (Hspice, etc.). Kellee proposed sending one of his IBIS models to the reflector and have the forum try it for sanity check. He will "put" the executable at \incoming on vhdl.org. Steve needs a non-Berkeley spice simulator for IBIS model. Kellee offered to provide one. AR Steve: Put your IBIS output file to the reflector. Add test vectors. Others can test it and provide feedback. Bob Ross asked if NCSU had made any progress on the Lex/Yacc IBIS parser. Steve said that Michael has it pretty much working. It will be posted publicly soon. 10. Stnd. driver, quality of support, validation Agreement from last meeting: Companies will self-certify (see 2/18/94 minutes). Old AR Will: See if Intel/Don Telian can release waveforms for the simulations in the Overview doc. The data should end up in Postscript format so the curves can be universally accessed. Old AR Everyone: If, and when you self-certify (run the test suite), send email to Derrick_Duehren@ccm.jf.intel.com so Derrick can add the information to the Participants Roster document. Include what IBIS version level you support. 11. BIRD 8, Spec. of V/I data monotonicity The existing BIRD has a few limitations. Many feel it needs to be more restrictive. Kellee is waiting to hear from others, but feels that monotonicity should be in one axis only (voltage). Jon said that the designs that were non- monotonic in current were abandoned because they rang too much. Many felt that we could restrict both axes to be monotonic, because we currently don't have any time dependency support (hysteresis or fold-back), and therefore we couldn't model it anyway. Kumar and Maah feel we should make the one-axis restriction conditional. Stephen drew a picture of non-monotonic I with monotonic V (similar to below) that looked real. Bob Ward knows of one but is not sure if he can make it available. | * | * * I | * * * | * | * |______________________________ V The Forum decided to leave monotonicity on voltage axis and call it good. AR Kellee: Update BIRD 8 accordingly. 12. BIRD 9, Other model types Bob Ross discussed bird 9.1. He added series and AC terminators. Discussion indicated some confusion about whether the new model types were inside or outside IC package (tied in with bird 2.1 questions). Kellee: "Are we degenerating from original IBIS proposal to stay away from trying to model resisters and capacitors?" Bob: We need to constrain the IBIS model. Kellee: Suggests a small modification to current model; add series resisters. "Maybe we need building blocks that we can add together?" Bob might create a BIRD to handle the series resistor as a separate model. No conclusions. Continue discussion on reflector. "IBIS is a bird that thrives in muddy waters", J. Powell. 13. BIRD 2.1 VIH, VIL Thresholds for Inputs We briefly discussed BIRD 2.1 and noted some conflicts with the recently passed BIRD 7.2. AR Jon: Reconcile BIRD 2.1 with BIRD 7.2 and come out with BIRD 2.2 or a new BIRD. 14. Egg 1, mutual pin coupling (ready to hatch?) Not discussed. 15. Simulation temperatures (new BIRD?) Lynn not present 16. Ramp measurement Not discussed. 17. Egg 2 ramp table? Will suggests this Egg. No time to discuss. 18. Canright paper Not discussed. 19. Formal BNF notation (BIRD?) Steve Lipa: The BNF parser from Michael Steer is working, but Steve has been involved on other things. NCSU uses it as their parser. 20. High freq. and EMI Not discussed. 21. Phased turn-on/off of multiple devices Not discussed. 22. Wrap-up, Next Meeting Plans AR Derrick: Schedule phone bridge connections for future meetings. Next is 4/1/93. From Will_Hobbs@ccm2.jf.intel.com Wed Mar 16 12:25:00 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27043; Wed, 16 Mar 94 12:25:00 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 16 Mar 94 12:22:44 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Wed, 16 Mar 94 12:22:24 -0800 Received: from ccMail by jfsmt2.intel.com id AA763849355 Wed, 16 Mar 94 12:22:35 PST Date: Wed, 16 Mar 94 12:22:35 PST From: "Hobbs, Will" Message-Id: <9402167638.AA763849355@jfsmt2.intel.com> To: ibis@vhdl.org, qdt!sal!jonp@uunet.UU.NET (Jon Powell) Subject: Re: committee name Jon, I take it you plan on joining us, then, brother Jon? Will I agree with the suggestion to call the May committee the "God-like assembly that can make no error" jonp From ccm!Don_A_Telian@intelhf.intel.com Wed Mar 16 13:55:48 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27601; Wed, 16 Mar 94 13:55:48 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ph3Wc-000MOrC; Wed, 16 Mar 94 13:53 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ph3eM-0000KGC; Wed, 16 Mar 94 14:01 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Mar 94 14:01:13 PST Date: Wed, 16 Mar 94 14:01:13 PST From: Don A Telian Message-Id: <940316140113_7@ccm.hf.intel.com> To: Arpad_Muranyi@ccm.hf.intel.com, Tim_A_Schreyer@ccm.hf.intel.com, 71436.1314@CompuServe.COM, ibis@vhdl.org, jonp@qdt.com Subject: Re: V/I table checking (from Kellee Crisafulli) Howdy, I'm glad you guys are working this issue. Please remember that it takes an accepted BIRD to change the parser. I thought I read about someone editing the parser on Monday (!?). That's not going to happen, right? Donald Telian ___________________________________________________________ To: Jon Powel, Arpad, IBIS commitee From: Kellee Crisafulli Re: method to determine if V/I table is valid Good point Jon and Arpad. I had negelected to considered noise from systems where the data is being sampled with a data acquisition system. (oops) Several things make it difficult to test for the wrong sign: - The data can change direction and be valid. - Only 2 points are required to have a valid table. - No particular voltage points are required. (there may or may not be data points at VCC or ground). I have a new simplified method based on Jon's suggestion that should also -work with Arpad's data: For each V/I table: 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The TYPICAL current corresponding to Vmax is less than the TYPICAL current corresponding to Vmin than the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. 3) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 4) If any table moves in the wrong direction flag as an error 5) Another test we could consider is if the currents at Vmin and Vmax -are equal then assume the data is a single point and thus invalid. (This may -already be tested I don't recall). I would still like to get agreement on this by Friday if possible. Here's hoping this IBIS_CHK egg is not broken,scrambled, or stolen by -the big bad wolf. Have a great day... Kellee From Will_Hobbs@ccm2.jf.intel.com Wed Mar 16 16:27:13 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28674; Wed, 16 Mar 94 16:27:13 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 16 Mar 94 16:25:08 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Wed, 16 Mar 94 16:24:50 -0800 Received: from ccMail by jfsmt2.intel.com id AA763863905 Wed, 16 Mar 94 16:25:05 PST Date: Wed, 16 Mar 94 16:25:05 PST From: "Hobbs, Will" Message-Id: <9402167638.AA763863905@jfsmt2.intel.com> To: Arpad_Muranyi@ccm.hf.intel.com, Tim_A_Schreyer@ccm.hf.intel.com, 71436.1314@CompuServe.COM, ibis@vhdl.org, jonp@qdt.com, Don A Telian Subject: Re[2]: V/I table checking (from Kellee Crisafulli) Don, et al, This has been referred to as an emergency BIRD, which has to be ratified. The BIRD hasn't been generated yet, and the change to the parser will have to be benign (i.e., warning, not error). The issue is that this is a common pitfall, and several feel we need to do something about it quickly. Will Howdy, I'm glad you guys are working this issue. Please remember that it takes an accepted BIRD to change the parser. I thought I read about someone editing the parser on Monday (!?). That's not going to happen, right? Donald Telian ___________________________________________________________ To: Jon Powel, Arpad, IBIS commitee From: Kellee Crisafulli Re: method to determine if V/I table is valid Good point Jon and Arpad. I had negelected to considered noise from systems where the data is being sampled with a data acquisition system. (oops) Several things make it difficult to test for the wrong sign: - The data can change direction and be valid. - Only 2 points are required to have a valid table. - No particular voltage points are required. (there may or may not be data points at VCC or ground). I have a new simplified method based on Jon's suggestion that should also -work with Arpad's data: For each V/I table: 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The TYPICAL current corresponding to Vmax is less than the TYPICAL current corresponding to Vmin than the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. 3) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 4) If any table moves in the wrong direction flag as an error 5) Another test we could consider is if the currents at Vmin and Vmax -are equal then assume the data is a single point and thus invalid. (This may -already be tested I don't recall). I would still like to get agreement on this by Friday if possible. Here's hoping this IBIS_CHK egg is not broken,scrambled, or stolen by -the big bad wolf. Have a great day... Kellee From ccm!Don_A_Telian@intelhf.intel.com Wed Mar 16 17:10:09 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29046; Wed, 16 Mar 94 17:10:09 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ph6Yc-000MOhC; Wed, 16 Mar 94 17:07 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ph6gD-0000EgC; Wed, 16 Mar 94 17:15 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Mar 94 17:15:21 PST Date: Wed, 16 Mar 94 17:15:21 PST From: Don A Telian Message-Id: <940316171521_8@ccm.hf.intel.com> To: Arpad_Muranyi@ccm.hf.intel.com, Tim_A_Schreyer@ccm.hf.intel.com, Will_Hobbs@ccm2.jf.intel.com, Tim A Schreyer@intelhf.intel.com, 71436.1314@CompuServe.COM, ibis@vhdl.org, jonp@qdt.com Subject: Re[3]: V/I table checking (from Kellee Crisafulli) Will and ?, Will one of the "several who feel we need to do something about it quickly" please let me know what the rush is. Give me a call if you like, (916)356-5029. The monotonicity discussion has been around for a long time with no quick solutions. I do not believe any change to the parser is benign, particularly one that creates new warning messages. Thanks, Donald Telian -------------------------------------------------------------------------- Don, et al, This has been referred to as an emergency BIRD, which has to be ratified. - The BIRD hasn't been generated yet, and the change to the parser will have to be benign (i.e., warning, not error). The issue is that this is a common -pitfall, and several feel we need to do something about it quickly. Will Howdy, I'm glad you guys are working this issue. Please remember that it takes an accepted BIRD to change the parser. I thought I read about someone editing -the parser on Monday (!?). That's not going to happen, right? Donald Telian ___________________________________________________________ To: Jon Powel, Arpad, IBIS commitee From: Kellee Crisafulli Re: method to determine if V/I table is valid Good point Jon and Arpad. I had negelected to considered noise from systems where the data is being sampled with a data acquisition system. (oops) Several things make it difficult to test for the wrong sign: - The data can change direction and be valid. - Only 2 points are required to have a valid table. - No particular voltage points are required. (there may or may not be data points at VCC or ground). I have a new simplified method based on Jon's suggestion that should also -work with Arpad's data: For each V/I table: 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The TYPICAL current corresponding to Vmax is less than the TYPICAL current corresponding to Vmin than the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. 3) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 4) If any table moves in the wrong direction flag as an error 5) Another test we could consider is if the currents at Vmin and Vmax -are equal then assume the data is a single point and thus invalid. (This may -already be tested I don't recall). I would still like to get agreement on this by Friday if possible. Here's hoping this IBIS_CHK egg is not broken,scrambled, or stolen by -the big bad wolf. Have a great day... Kellee From ccm!Derrick_Duehren@intelhf.intel.com Wed Mar 16 17:48:06 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29336; Wed, 16 Mar 94 17:48:06 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ph7A0-000MP5C; Wed, 16 Mar 94 17:46 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ph7Hm-000085C; Wed, 16 Mar 94 17:54 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Mar 94 17:54:09 PST Date: Wed, 16 Mar 94 17:54:09 PST From: Derrick Duehren Message-Id: <940316175409_4@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Posting IBIS models to vhdl.org ***************************************************************************** How to Submit IBIS Models to vhdl.org ***************************************************************************** Until further notice, Derrick Duehren is coordinating IBIS model submissions to vhdl.org. Instructions follow: a) email the files to "incoming@vhdl.org". Or, If there are many or binary files, they should be "tar"ed together and then "uuencoded"; or use "shar" or "mailsplit". Most of these utilities are in the /pub/tools directory structure. Include a "readme" file identifying the files and the submitter. login as "guest" from either a telnet or dial-in (408-945-4170) session. Use "kermit", "rz" (receive Zmodem), or "PUT" to transfer the file(s) into /incoming. Or, Send a DOS-formatted diskette with the IBIS and "readme" files to: US Postal Service: Package Delivery Service: Derrick Duehren Derrick Duehren Intel Corp. M/S JF1-97 Intel Corp. M/S JF1-97, Post E10 2400 NE Elam Young Pkwy. 2111 NE 25th St. Hillsboro, OR 97124 Hillsboro, OR 97124 b) Send email to derrick_duehren@ccm.jf.intel.com letting him know what you have transferred to \incoming so Derrick can move them to the appropriate directory. Following are more detailed instructions for "accessing" vhdl.org. - Randy Harr and Derrick Duehren ------------------------------------------------------------------------------- Accessing Documents and Literature on the VHDL International Users' Forum Standards On-line Support system 24 August 1993, version 1.0 ------------------------------------------------------------------------------- Many reference documents and related information are all available via the VHDL International Internet Repository. You can access and download the files in many different ways. Each is described further here. Email Access: ------------- There is an FTP archive server which is accessible via email. Send an email message to archive@vhdl.org. The subject is ignored. If a line in the body begins with the word "help", then a descriptive file of commands available is sent. Basically, you communicate with the server through commands in the body of your mail message. It then responds automatically and immediately to your request. (Note: immediate is relative to your connection mechanism to the Internet mail services.) You should always include the command: path in every request to assure the server knows where to send the message back to (otherwise it has to guess from the return path encoded in the mail message which does not always work) The following are a few examples of useful commands you could send in the body of your mail message. Each assumes you have requested to mail a message to archive@vhdl.org and included the path command in the body. To get help: help or to get this document: send docs pub.access.txt To get a listing of available files and directories for a given level: index vi/vital send vi/vital 00README To ask that a file be downloaded: send vi/vital email.archive As an example, for Joe Smith of XYZ (login name joes) to get the VITAL version 2.0 spec, he would send an email request to "archive@vhdl.org" with the following body: path joes@xyz.com send vi/vital vitalspec20.ps.Z Dial-Up Access: --------------- Dial-up to the vhdl.org system at 408.945.4170. Any baud (up to 14,400), parity, start & stop bits, and v.* settings will do. Login using the "guest" account. Once in, simple UNIX commands such as "cd vi/vital", "ls" and "cat 00README" are available. Also, you can download desired files using "kermit", "zmodem" or "sz" (zmodem). Internet Access: ---------------- Use "ftp vhdl.org" (or "ftp 198.31.14.3") and login as user "anonymous". Look in to "vi/vital". Also, gopher is available and highly recommended if you have it available. Gopher to "vhdl.org". Remember to set "binary" mode for any binary files (*.doc, *.fm, *.xls) you may elect to receive. In general, most documents are available in source (binary) form (such as WORD, EXCEL or FrameMaker formats), in an ASCII exchange format (such as RTF, SyLK, and MIF; respectively), and in postscript form ready to be sent to your printer directly. The file size increases accordingly as you move away from the source form. If you have any problems, send an email to support@vhdl.org. docs/pub.access.txt From bob@icx.com Wed Mar 16 19:17:42 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29986; Wed, 16 Mar 94 19:17:42 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA08339 for ; Wed, 16 Mar 94 22:01:16 -0500 Date: Wed, 16 Mar 94 19:00:18 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18078; Wed, 16 Mar 94 19:00:18 PST Message-Id: <9403170300.AA18078@icx.com> To: ibis@vhdl.org Subject: V/I table checking To IBIS Committee, Jon, Kellee: (1) Should the V/I table checks be EQUAL-or-INCREASING and EQUAL-or- DECREASING? Do ALL simulators which require Monotonic Current support EQUAL current values within the voltage range? (2) My understanding is that the error is a "Warning" Error. It serves two purposes: (a) Warn the user of a general incorrect Current sign problem (b) Warn the user of non-monotonic data (3) If the data is non-monotonic, AND the simulator requires Monotonic data, (a) The data can be rejected (b) The user can edit the IBIS file to force monotonic data (c) The simulator itself could have an automatic monontonic filter (and issue a warning message if invoked) when reading the IBIS file into the internal data base. From bob@icx.com Wed Mar 16 20:27:13 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00549; Wed, 16 Mar 94 20:27:13 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18326 for ; Wed, 16 Mar 94 23:16:18 -0500 Date: Wed, 16 Mar 94 20:12:16 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18225; Wed, 16 Mar 94 20:12:16 PST Message-Id: <9403170412.AA18225@icx.com> To: ibis@vhdl.org Subject: Bird2.1, Useful timing data To IBIS Committee I basically agree with Jon Powells comments regarding having the Input Threshholds, and feel that Vinh and Vinl should be provided in all Input and I/O type models. I lean toward requiring this data if there is another "Model_type" such as "Analogue" or "Terminator" or whatever that would allow a device to be on the net for which no timing information is needed or desired. One application that is within IBIS Version 1.1 functionality is to add a clamping diode terminator package at the end of a net which has no need for threshhold timing calculations. I am assuming that the Vinl and Vinh values are in practice, Data Book specification limit values. However, they also could represent an attempt to represent actual values which may be within a smaller range. Furthermore, they could also represent values for a Hysterisis Input where the Vinl value is greater than the Vinh value. One underlying assumption is that any simulator that needs threshhold data can enter that data for each model and/or override any data that is presented in the model. Because of this, the issue is not critical. The workaround is to enter the value externally and/or use some default values. However, a consideration is that the Model provider will probably know this information and therefore should provide it. Some devices (larger ones) may have several types of input and outputs and may have several different threshhold levels specified. TTL/ECL translator chips will have different levels. It is easier for values to be provided than to have the user tediously go through literally pin-by-pin, especially when there are significant differences. Concerning "VM", I presume both a voltage and a correction time would be provided. I think that at least a VM voltage would be a good addition since that is also provided in Data Books and is relevant to timing analysis measurement points. The whole timing issue is a "sticky wicket", so I can understand the safer position of doing nothing at this time. However, I do believe that these timing "enhancements" provide measurement parameters closely related to "SI analysis" and in many cases timing is the PASS/FAIL crieria of SI on nets. So I strongly recommend all model providers include at least the Vinh and Vinl information. Bob Ross, Interconnectix, Inc. From 71436.1314@CompuServe.COM Wed Mar 16 21:34:28 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00915; Wed, 16 Mar 94 21:34:28 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id AAA21249; Thu, 17 Mar 1994 00:32:29 -0500 Date: 17 Mar 94 00:28:59 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL , Jon Powell , Don A Telian Subject: V/I table sign validation (from Kellee Crisafulli) Message-Id: <940317052858_71436.1314_HHB35-1@CompuServe.COM> To: Jon Powel, Arpad, Don T.,Bob Ward, IBIS commitee From: Kellee Crisafulli Re: method to determine if V/I table is valid Don: This should not require a new bird because we are not changing the IBIS specification. This also has little to do with monoticity. The problem as I described earlier is simply validating that the V/I tables have the correct sign. For example the source generator should source current, and the sink generator should sink current. The reason for the rush is that I have personally seen 4 separate cases of incorrect IBIS models being created in the last two weeks. We now have numerous companies including consultants creating IBIS models. I believe it is very important to make sure models are correct before being released to the public. If we cannot agree on a simple method of validating the V/I table sign than it will require a full fledged BIRD to achieve this and a much longer time table. My first impression was that this would be a simple matter. I still beleive there is a simple method of validating the sign of these tables: I will repeat my proposal: For each V/I table: 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The TYPICAL current corresponding to Vmax is less than the TYPICAL current corresponding to Vmin than the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. 3) Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current 4) If any table moves in the wrong direction report that the table has an ERROR, (wrong sign....). Note: I am proposing an ERROR, not a warning! 5) Another test we should consider: If the currents at Vmin and Vmax are equal then consider that the data may be a single point. The IBIS specification requires at least two data points. I propose that we flag this with a WARNING message. Bob Ward, I have revised number 5 to better address your inputs. I would still like to get agreement on a method of validating the sign of the V/I tables as soon as possible. We had agreement at the last meeting that Will Hobbs would determine if we had suffient agreement to continue with a modification to the IBIS_CHK program. From Will_Hobbs@ccm2.jf.intel.com Thu Mar 17 09:28:42 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08699; Thu, 17 Mar 94 09:28:42 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 17 Mar 94 09:26:42 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Thu, 17 Mar 94 09:26:26 -0800 Received: from ccMail by jfsmt2.intel.com id AA763924756 Thu, 17 Mar 94 09:19:16 PST Date: Thu, 17 Mar 94 09:19:16 PST From: "Hobbs, Will" Message-Id: <9402177639.AA763924756@jfsmt2.intel.com> To: bob@icx.com ( Bob Ross), ibis@vhdl.org Subject: V/I table checking Bob and others, Monotonicity is not required by IBIS at all and for backward compatibility will never go beyond a recommendation. For now, and until the recommendation becomes embodied in IBIS 2.0, I do not believe we should even check for it. Regarding the discussion on the issue of incorrect signs, I am beginning to doubt if we will resolve this quickly, either. I do not want to react quickly and make a mistake. Even if only a warning is issued, it will confuse users if the warning is erroneous. (That's why I never run the grammar checker on my word processor-- it's wrong more often than I am.) We appear to be able to come up with counterproposals for every algorithm that is suggested, which tells me we need to look more closely before jumping in to a golden parser change. Wil To: ibis@vhdl.org Subject: V/I table checking To IBIS Committee, Jon, Kellee: (1) Should the V/I table checks be EQUAL-or-INCREASING and EQUAL-or- DECREASING? Do ALL simulators which require Monotonic Current support EQUAL current values within the voltage range? (2) My understanding is that the error is a "Warning" Error. It serves two purposes: (a) Warn the user of a general incorrect Current sign problem (b) Warn the user of non-monotonic data (3) If the data is non-monotonic, AND the simulator requires Monotonic data, (a) The data can be rejected (b) The user can edit the IBIS file to force monotonic data (c) The simulator itself could have an automatic monontonic filter (and issue a warning message if invoked) when reading the IBIS file into the internal data base. From qdt!sal!jonp@uunet.UU.NET Thu Mar 17 09:53:25 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08968; Thu, 17 Mar 94 09:53:25 PST Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhql23080; Thu, 17 Mar 94 12:51:19 -0500 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 17 Mar 1994 12:51:22 -0500 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00669; Thu, 17 Mar 94 09:15:35 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA06108; Thu, 17 Mar 94 09:15:35 PST Date: Thu, 17 Mar 94 09:15:35 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9403171715.AA06108@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA11362; Thu, 17 Mar 94 09:15:54 PST To: uunet!ccm2.jf.intel.com!Will_Hobbs@uunet.UU.NET Cc: ibis@vhdl.org In-Reply-To: "Hobbs, Will"'s message of Wed, 16 Mar 94 12:22:35 PST <9402167638.AA763849355@jfsmt2.intel.com> Subject: committee name Will, If I can pass the required ORDEAL I will be there as a diligent member of the brotherhood. (Do I get a sash?). jonp From bob@icx.com Thu Mar 17 14:31:05 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10883; Thu, 17 Mar 94 14:31:05 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03498 for ; Thu, 17 Mar 94 17:13:39 -0500 Date: Thu, 17 Mar 94 13:56:59 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA20076; Thu, 17 Mar 94 13:56:59 PST Message-Id: <9403172156.AA20076@icx.com> To: ibis@vhdl.org Subject: V/I table checking To IBIS Committee and Will Thanks for your response on Monotonicity. I goofed in confusing the Monotonicity discussion with the checking discussion because I read INCORRECTLY into 4) as "any table entry ..." instead of "any table ..." So, one gooney bird award to me. One member of the "God-like assembly that can make no error" can make errors. I think the discussion should continue on the checker modification with still the possibility of rapid agreement. If this proposal is adopted, it would apply to just IBIS Version1.1. The polarity rules do not comply with proposed IBIS extensions BIRDS 3 and 4 for ECL type devices. For ECL type devices, the polarities of both the Pullup and Pulldown tables will go in the same (decreasing) direction because BOTH tables are tabulated referenced to Vcc using Vtable = Vcc - Vout. I am sure this will become another area of confusion, justifying a test. I have a problem at this time with test 5) checking for equal currents at Vmin and Vmax and flagging it as an error if they are equal. This may be an acceptable condition if the currents are 0 ma. Also it may be possible to approximate a constant current source or sink with an "ideal" current source using a constant clamping current, although I have not thought out all of the implications of doing this. In general, I can accept the V/I table checking proposal but prefer it to be modified to allow Equal current values. Bob Ross Interconnectix, Inc. From contec!contec.COM!maah@netcom.com Thu Mar 17 17:17:21 1994 Return-Path: Received: from netcomsv.netcom.com (uucp9.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12220; Thu, 17 Mar 94 17:17:21 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id RAA02831; Thu, 17 Mar 1994 17:16:22 -0800 Received: from contec4.contec.COM ([192.9.200.168]) by contec.COM (4.1/SMI-4.1) id AA12404; Thu, 17 Mar 94 16:54:30 PST Date: Thu, 17 Mar 94 16:54:29 PST From: maah@contec.COM Message-Id: <9403180054.AA12404@contec.COM> To: ibis@vhdl.org Subject: V/I table checking Gentle IBIS folk: Just a couple of points about V/I table checking. 1. I agree with Don and Will that changing the Golden Parser should not be undertaken lightly. I believe we agreed that the Golden Parser IS, in fact, the IBIS specification. Let us follow procedure for changes to the parser, and perhaps issue some interim IBIS application note to provide temporary guidance until an issue is fully resolved. We all know about runaway software where fixing one problem creates a couple more problems which then multiply geometrically. Beyond that...there are the issues raised below. 2. I agree with Bob Ross that the proposed scheme for enforcing data integrity will not work for ECL, nor for a few other device types. (See item 3 of the proposal). Either the "pullup" or the "pulldown" data for the ECL and other device types will violate these requirements. 3. The proposed scheme, item 3, will not always work even for CMOS unless we use only the magnitudes of the currents. Existing data for ageing (old) devices is sometimes presented with positive currents and sometimes with negative currents for CMOS pullup devices. 4. I am not sure that checking only the two end points will always guarantee the conclusions we are assuming here. Current(I) data in between these two points may increase or decrease and still be perfectly valid, particularly if we think of device types other than CMOS. Maah Sango Contec Microelectronics USA Inc. From bward@sugar.NeoSoft.COM Thu Mar 17 19:46:12 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13495; Thu, 17 Mar 94 19:46:12 PST Received: by sugar.NeoSoft.COM id AA11956 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 17 Mar 1994 21:43:58 -0600 Message-Id: <199403180343.AA11956@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Checking V/I tables Date: Thu, 17 Mar 94 21:43:55 CST I agree with Maah's observations. I would point up that his point 4, about checking the end points is especially valid. This is why I was suggesting that a point be checked in the near vicinity of gnd rail voltage and in the near vicinity of power rail voltage. But then I realized, he said, looking around quickly, this won't work for ECL. I would propose examining the slope of the line through a point near the extrema of the swing in that case to determine the direction of current. But as Bob Ross points out, the sign may not make much sense for ECL anyway. Ah, well, long live CMOS. But what DO we do with ECL? ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From slipa@eos.ncsu.edu Thu Mar 17 23:08:25 1994 Return-Path: Received: from mw7.ece.ncsu.edu (c11049-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14703; Thu, 17 Mar 94 23:08:25 PST Received: by mw7.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA14996; Fri, 18 Mar 1994 02:06:26 -0500 From: slipa@eos.ncsu.edu Message-Id: <9403180706.AA14996@mw7.ece.ncsu.edu> To: ibis@vhdl.org Cc: slipa@eos.ncsu.edu Subject: s2ibis executables Date: Fri, 18 Mar 94 02:06:25 EST Dear IBIS Community: Hi. I have put s2ibis executables for DEC 2100/3100/5000, SUN SPARCstation, and RS6000 workstations in the incoming directory at vhdl.org. Our WATCOM compiler is broken, and one of the master diskettes is corrupted, so I will not be able to provide the IBM PC version until I can recompile. I think we have another compiler around here, so I may be able to fix it later today or over the weekend. I have tested s2ibis with Berkeley SPICE 2 and 3 on the Decstations, with Berkeley SPICE 3 on the SPARCstations, and with Lipa SPICE 0.0 on an RS6000. Lipa SPICE is a kludge, but I think s2ibis will work OK with both versions of Berkeley SPICE on the RS6000. I would really appreciate it if someone with one of the Berkeley SPICE versions would let me know if it works OK on the RS6000, as I have no idea when it will be loaded onto our machine. The PSPICE routines are also implemented, but we only have PSPICE on IBM PCs, so I won't be able to test them until I get the WATCOM compiler fixed, or a replacement compiler. Regarding the feedback I've gotten so far: I have updated the documentation to reflect the fact that I/O pins require polarity, vih and vil entries on their pindata lines to describe the input part of the functionality. I have added a C_comp entry for each [Model], but I just copied the one in the Version 1.1 spec. I didn't put it in in the first place because I didn't understand what it was. I still haven't put a [POWER_Clamp] table in for Open_drain outputs because that doesn't make much sense to me either. Thanks to Eagle-eye Bob Ross (or should I say Ibis-eye???) and all the others who wrote me about the example output I posted last week. The updated man pages are in the tar files with the executables. Please let me know if you have any questions, failures, suggestions, complaints, or successes with the executables. Steve Lipa slipa@eos.ncsu.edu PS: I would appreciate it if someone would be willing to comment on the following line taken from Section 3 of the NOTES ON DATA DERIVATION METHOD appendix to the IBIS spec: 1. Start with silicon model, remove all packaging. Does this mean that the circuit s2ibis uses for [Ramp] tables has to be different than the one used for the other tables? Is the s2ibis input file syntax too simple to handle this? Should the pindata line for output pins have a SPICENODE and RAMPSPICENODE entry and should there be some way of flagging components to be left out of the [Ramp] SPICE decks? From 71436.1314@CompuServe.COM Thu Mar 17 23:43:58 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14959; Thu, 17 Mar 94 23:43:58 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id CAA14273; Fri, 18 Mar 1994 02:41:59 -0500 Date: 18 Mar 94 02:39:05 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: V/I table checking (from Kellee) Message-Id: <940318073904_71436.1314_HHB40-1@CompuServe.COM> From: Kellee I see my hopes of a fast update have faded into the end of the week (oh well). I have to agree that it is far better to take the time and do it correctly the first time. On the other hand if we ended up with numerous IBIS models with incorrect tables that weren't done correctly the first time we have also failed. 1) Relative to the ECL problem. This updated is intended only to address Ver 1.1 so it seems like this is not a problem. We could however check for the ECL parameter and check for both tables have the same sign direction in this update. This would get us a head start on the Ver2.0 parser. 2) Relative to several comments about only checking the signs at the two end points and some devices having only negative or only positive signs. This doesn't matter, what I proposed is testing if the values were larger or smaller. The sign is not needed for this test. (-5 is less than -2) (0 is less than 2). Did I miss something. 3) The IBIS_CHK program is not the specification. It only supports a portion of the full IBIS 1.1 specification information. What we agreed to is that the IBIS_CHK program would be the golden parser. That means when there is a question about who's parser is correct the IBIS_CHK parser is always the one that is correct. I am willing to make this into a BIRD and add the ECL, or just continue with my proposal as is. Which way should we go? I would like to continue as it is and just support version 1.1 I'll check in Sunday and start a BIRD if that is really needed. I still believe that the IBIS_CHK program is simply the validation of the existing specification and thus doesn't require a bird. It seems like the need for a BIRD indicates that we didn't specify this area well enough and that is what the BIRD would need to address. If we do start requiring a BIRD for each parser change than how in the world will we ever get the parser done for version 2.0. Do we need a BIRD for each and every item to be updated in the parser (it could get very lengthy). It seems to me we just need to agree that a new version is acceptable to everyone and release it. A set of regression IBIS files seems like a good idea though. How about using the 82430 and 82420 files as the first set of regression files. Each IBIS representative should also test the new update with their own IBIS files before we re-certify the parser. What do you think? Have a great weekend! (I will am going snow shoeing with my wife on Friday) Kellee From Will_Hobbs@ccm2.jf.intel.com Fri Mar 18 08:45:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21470; Fri, 18 Mar 94 08:45:32 PST Received: from ccm.jf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0phhdx-000MPTC; Fri, 18 Mar 94 08:43 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 18 Mar 94 08:43:29 PST Date: Fri, 18 Mar 94 08:43:29 PST From: Will Hobbs Message-Id: <940318084329_2@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Tips and techniques IBIS-persons, I would like to make a couple of comments about generating models. First, models should be simulated into known loads and the results inspected for sanity. Reversed V/I signs will show up quickly in the results. We generally run our models into three standard load topologies for a first pass sanity check: one pure capacitive load, one purely resistive load, and one "break the model" load such as the PCI Speedway load that is shown in the IBIS Overview. While it might be nice to have the more common types of errors checked for by the parser, there is no substitute for model validation by cross-correlation with silicon or netlist-level model simulation. Second, when I've been involved in releasing a product with some non-obvious features, we've usually provided a quick checklist of frequent sources of error, hint and tips, etc. A good one or two page document describing potential gotchas and hints in creating and validating IBIS models would be beneficial. I'd be happy to collect input for such a circular and post the collection to the reflector. Comments? Will Hobbs Intel Corp. From Will_Hobbs@ccm2.jf.intel.com Fri Mar 18 09:10:09 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21610; Fri, 18 Mar 94 09:10:09 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 18 Mar 94 09:08:07 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Fri, 18 Mar 94 09:07:44 -0800 Received: from ccMail by jfsmt2.intel.com id AA764010480 Fri, 18 Mar 94 09:08:00 PST Date: Fri, 18 Mar 94 09:08:00 PST From: "Hobbs, Will" Message-Id: <9402187640.AA764010480@jfsmt2.intel.com> To: ibis@vhdl.org Subject: Bird 10 from Eric Bracken, 1st double digit bird (2 claws?) ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 10 ISSUE TITLE: Describing coupling effects in package models REQUESTOR: Eric Bracken, Performance Signal Integrity, Inc. DATE SUBMITTED: 17 March 1994 DATE REVISED: {revision date} DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: For a more thorough signal integrity analysis, a mechanism is needed for describing electromagnetic couplings between the different pins of a package. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Summary: ------- A new keyword, [Package Model], is added to the .ibs file. Following this keyword, the name of a package model for the part is given. Package models can be found in separate package model files, which bear the .pkg extension. The format of .pkg files is also part of the resolved specification, and is explained in detail below. Use of [Package Model] is OPTIONAL. If it is not provided, then the table of RLC values listed in the [Pin] section of the .ibs file is used as the "package model" for the part. On the other hand, if the [Package Model] IS given, then the R_pin, L_pin and C_pin values in the [Pin] section may either be ignored, or may be used for less detailed simulations without coupling. Probably this data will simply be left out of the [Pin] section when a [Package Model] is used; this practice is permitted by the IBIS Ver. 1.1 specification. I. Syntax for the .IBS File. ---------------------------- The following syntax is used for specifying a package model: |============================================================================== | | Keyword: [Package Model] | | Required: No | | Description: Used to indicate the name of the package model | | Usage Rules: The Package_Model_Name is limited to 40 characters. | Spaces are allowed in the name. | |------------------------------------------------------------------------------ | [Package Model] Package_Model_Name This is the only change to the .ibs file. The actual package model is contained within the .pkg file, which is described next. II. Syntax for the .PKG File ----------------------------- Package models are stored in a file whose name looks like .pkg The provided must adhere to the venerable MS-DOS file name conventions: it must not exceed 8 characters in length. All of these characters must be lower case. The extension ".pkg" is used to identify files containing package models. A. Global elements ------------------- The .PKG file contains several elements which are identical to those in a .IBS file. The following keywords are required for each file: [IBIS Ver] (must be the 1st keyword in the file) [File Name] [File Rev] Optional keywords may be added to clarify the file's contents: [Date] [Source] [Notes] [Disclaimer] All of the abovementioned keywords follow rules absolutely identical to those in the .IBS file. The reader is referred to the IBIS Version 1.1 specification for more details. The default character for comments in the .pkg file is "|". As in the .ibs file, the comment character may be changed through the use of the [Comment char] keyword at any point in the file. Again, the syntax is the same as for a .ibs Ver. 1.1 file. After the information listed above, the actual package models are given. These are described in the next subsection. B. Package Models ------------------ Each package model is preceded by the [Define Package Model] keyword. |============================================================================== | | Keyword: [Define Package Model] | | Required: Yes | | Description: Used to mark the beginning of a package model description. | | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the Package_Model_Name must not | exceed 40 characters in length and blank characters ARE | allowed. | |------------------------------------------------------------------------------ | [Define Package Model] Package_Model_Name The [Manufacturer] keyword is used to declare the manufacturer of the part(s) which use this package model. This would typically be the name of the semiconductor vendor. The syntax is identical to that of the [Manufacturer] keyword in the .ibs file, e.g. [Manufacturer] Bozonics Semiconductors Ltd. An additional optional keyword, [OEM], is used to indicate the name of the PACKAGE's manufacturer. This is useful if the semiconductor vendor sells a single IC in packages from different manufacturers (e.g. AMP, Kyocera). The [OEM] keyword's syntax is analogous to that of the [Manufacturer] keyword. [OEM] Pkgs'R'Us The [Description] keyword is used to indicate to a human being what the model is describing. |============================================================================== | | Keyword: [Description] | | Required: Yes | | Description: This is used to provide a concise yet easily human-readable | description of what kind of package the [Package_Model] | is representing. An example Description_Text might be: | "220-Pin Quad Ceramic Flat Pack". | | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and MAY contain spaces. | |------------------------------------------------------------------------------ | [Description] Description_Text The [Number of Pins] keyword identifies how many pins the package has. |============================================================================== | | Keyword: [Number of Pins] | | Required: Yes | | Description: This is used to tell the parser how many pins to expect. | | Usage Rules: The How_Many field must be a positive integer less than 60 | characters long. | |------------------------------------------------------------------------------ | [Number of Pins] How_Many The beginning of the actual model data is marked with the [Model Data] keyword. |============================================================================== | | Keyword: [Model Data] | | Required: Yes | | Description: This is used to indicate the beginning of the formatted | model data. | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Model Data] Similarly, the end of the model data is marked with an [End Model Data] keyword: |============================================================================== | | Keyword: [End Model Data] | | Required: Yes | | Description: This is used to indicate the end of the formatted | model data. | | Usage Rules: This is pretty simple too. | |------------------------------------------------------------------------------ | [End Model Data] In between these two keywords is the package model data itself. The data to be supplied is a set of 3 matrices: the resistance (R), inductance (L), and capacitance (C) matrices. Each matrix may be formatted differently (see below). A special keyword is used to mark the beginning of each new matrix: |============================================================================== | | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | | Required: [Resistance Matrix] is optional. If it's not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | | Description: These are used to mark the beginning of a matrix, and to | specify how the matrix data will be formatted. | | Usage Rules: There are 3 choices for the Format_Keyword: | Banded Matrix, Sparse Matrix, and Full Matrix. | | After each of these keywords, the matrix data will follow | in the appropriate format. | | These formats are described in detail below. | |------------------------------------------------------------------------------ | [Resistance Matrix] Format_Keyword [Inductance Matrix] Format_Keyword [Capacitance Matrix] Format_Keyword C. Matrix Formats ------------------ For each [Resistance Matrix], [Inductance Matrix], or [Capacitance Matrix] a different format may be used for the data. The choice of formats is provided to satisfy different simulation accuracy and speed requirements. Also, there are many packages in which the resistance matrix may have no coupling terms at all; in this case, the most concise format (Banded Matrix) may be used. One common aspect of all the different formats is that they exploit the symmetry of the matrices they describe. This means that the entries below the main diagonal of the matrix are identical to the corresponding entries above the main diagonal. Therefore, only roughly one-half of the matrix needs to be described. By convention, the main diagonal and the UPPER half of the matrix will be provided. The available formats are Banded Matrix, Sparse Matrix, and Full Matrix. We describe each of the formats separately below. In the following, we use the notation [I, J] to refer to the entry in row I and column J of the matrix. 1. Full Matrix When the Full Matrix format is used, the couplings between every pair of elements will be specified explicitly. We assume that the matrix has N rows and N columns. The Full Matrix is specified one row at a time, starting with Row 1 and continuing down to Row N. Each new row is identified with the Row keyword. |============================================================================== | | Keyword: [Row] | | Required: Yes | | Description: This is used to indicate the beginning of a new row of | the matrix. The Row_Number field must be a positive | integer in the range from 1 up to the number of rows | specified in the corresponding [Number of Pins] keyword. | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Row] Row_Number Following a [Row] keyword is a block of numbers which represent the entries for that row. Suppose that the current row is number M. Then the first number listed is the diagonal entry, [M,M]. Following this are the entries of the upper half of the matrix that belong to row M: [M, M+1], [M, M+2], ... up to [M,N]. For even a modest-sized package, this data will not all fit on one line. Since each line of an IBIS file must be 80 characters long or less, it is permissible to break the data up with newlines so that this limit is observed. An example: suppose the package has 40 pins and that we are currently working on Row 19. There will be 1 diagonal entry, plus 40 - 19 = 21 entries in the upper half of the matrix to be specified, for 22 entries total. The data might be formatted as follows: [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 In the above example, the entry 5.67e-9 is on the diagonal of row 19. It will be observed that Row 1 always has the most entries, and that each successive row has one fewer entry than the last; the last row will always have just a single entry. 2. Banded Matrix A Banded Matrix is one whose entries are guaranteed to be zero if they are farther away from the main diagonal than a certain distance, known as the "bandwidth." Again let the matrix size be N, and let the bandwidth be B. An entry [I,J] of the matrix will be zero if | I - J | > B where |.| denotes the absolute value. The bandwidth for a Banded Matrix must be specified using the [Bandwidth] keyword: |============================================================================== | | Keyword: [Bandwidth] | | Required: Yes (for banded matrices only) | | Description: This is used to indicate the bandwidth of the matrix. | The BW field below must be a nonnegative integer. This | keyword occurs after the [Resistance Matrix], etc. | keyword, and BEFORE the matrix data is given. | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Bandwidth] BW The banded matrix is specified one row at a time, starting with row 1 and working up to higher rows. Each row is marked with the [Row] keyword, as above. As before, symmetry is exploited: entries below the main diagonal are never given. The first row will only need to specify the entries [1,1] through [1,1+B] since any other entries are guaranteed to be zero. The second row will need to specify the entries [2,2] through [2, 2+B], and so on. In general, for row M the entries [M,M] through [M,M+B] are given. Unlike the Full Matrix, each successive row will _typically_ have the same number of entries, except for the last few rows. When M + B finally exceeds the size of the matrix N, then the number of entries in each row will start to decrease; the last row (row N) will have only 1 entry. As in the Full Matrix, if all the entries for a particular row will not fit into a single 80-character line, the entries may be broken across several lines. It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix with no coupling terms.) This is sometimes useful for resistance matrices. 3. Sparse Matrix The final option for specifying the entries of the matrix is the Sparse Matrix format. A sparse matrix is expected to consist mostly of zero- valued entries, except for a few nonzeros. Unlike the Banded Matrix, there is no restriction on where the nonzero entries may occur. This is useful in certain situations, such as for Pin Grid Arrays (PGA's.) As usual, symmetry may be exploited to reduce the amount of data by eliminating from the matrix any entries below the main diagonal. An N x N Sparse Matrix is specified one row at a time, starting with row 1 and continuing down to row N. Each new row is marked with [Row] keyword, as in the other matrix formats. Data for the entries of a row is given in a slightly different format, however. For the entry [I, J] of a row, it is necessary to explicitly list the column index J before the value of the entry is given. This serves to indicate to the parser where the entry is put into the matrix. The proper location is not otherwise obvious because of the lack of restrictions on where nonzeros may occur. Each (Index, Value) pair is listed upon a separate line. An example follows. Suppose that row 10 has nonzero entries [10,10], [10,11], [10,15] and [10,25]. The following row data would be provided: [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 Please note that each of the column indices listed for any row must be greater than or equal to the row index, because they always come from the upper half of the matrix. Also, please note that it is again necessarily the case that the N'th row of an N x N matrix will have just a single entry (the diagonal entry.) D. An Example The following is an example of a package model file following the above specifications. For the sake of brevity, an 8-pin package has been described. For purposes of illustration, each of the matrices is specified using a different format. | |================================================================ | [IBIS Ver] 2.0 [File Name] example.pkg [File Rev] 0.1 [Date] 16 March 1994 [Source] imaginary data from K-mart field solver software [Notes] Example for a BIRD on couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. Read at your own risk. See your dentist regularly. | |================================================================ | [Define Package Model] SMT-cer-8-pin [Manufacturer] Bozonics Semiconductors Ltd. [OEM] Pkgs'R'Us [Description] 8-Pin ceramic SMT package [Number of Pins] 8 [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded Matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full Matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse Matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | | All done! | [End Model Data] ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This is an attempt to add more electromagnetic information to the packaging models. The main element missing from the original IBIS packaging models are couplings between pins. These couplings can change the effective inductances of power and ground pins, affecting the amount of ground bounce that occurs in the model. The couplings can also lead to increased noise between signal pins. For these reasons (and more), they are worth considering. There are many ways one might approach the description of the coupling information. The choices made will certainly impact the efficiency and the accuracy of the signal integrity simulations that are carried out. To meet a wide variety of needs, several different options have been provided for specifying the coupling data. Full-matrix formats may be used for maximum electromagnetic rigorousness, or descriptions with limited amounts of coupling can be used to speed up simulation. The data for package models has been separated from the nonlinear, mostly-memoryless I-V curve information in the .ibs file, and has been put into a separate .pkg file. This approach is intended to minimize the impact on tools that currently read and write .ibs files. However, it would not be out of the question to keep all of this information in the .ibs file, too. The spec could be rewritten easily to allow this. Note that this is a departure from standard IBIS practice--in .ibs files, the "model" names, at least, are not exported from the file that contains them. Keeping this data in separate files leads to the possibility of naming conflicts across different vendors' model files. Hopefully this can be managed by using long names for package models. What is still missing from this spec is the ability to handle models with arbitrary topologies of RLC circuit elements. This would be useful, for example, in the modelling of large packages where the traces are long enough to exhibit some "transmission-line" effects. In these cases, it would be useful to be able to break the single series RL element up into a ladder (or some more complex structure) of RLC elements. This capability will become more important as the signal speeds of the IC's rise. Therefore, this spec may need to be overhauled and updated at some time in the not-too-distant future. It is certainly true that the Full Matrix format is a special case of both the Banded Matrix and the Sparse Matrix formats. It can be regarded as "syntactic sugar" which may or may not appeal to everyone. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The classic electromagnetics text by Ramo, Whinnery and Van Duzer provides some nice background theory on how one goes about defining resistance, inductance and capacitance values for arbitrary structures, and also describes the high-frequency limitations to this approach. ******************************************************************************* From lmsi!milpitas.lmc.com!randyh@sgiblab.sgi.com Fri Mar 18 12:50:00 1994 Return-Path: Received: from sgiblab.sgi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23199; Fri, 18 Mar 94 12:50:00 PST Received: from lmsi by sgiblab.sgi.com via UUCP (931110.SGI/911001.SGI) id AA19168; Fri, 18 Mar 94 12:47:26 -0800 Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA14987; Fri, 18 Mar 94 11:38:53 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA01173; Fri, 18 Mar 94 11:38:52 PST Date: Fri, 18 Mar 94 11:38:52 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9403181938.AA01173@fiji.lmsi.com> To: ibis@vhdl.org Subject: s2ibis "tar" files They have been moved from /incoming to /pub/ibis/s2ibis. randy harr randyh@lmc.com From ccm!Arpad_Muranyi@intelhf.intel.com Fri Mar 18 13:18:56 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23381; Fri, 18 Mar 94 13:18:56 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0phlub-000MP5C; Fri, 18 Mar 94 13:16 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0phm2a-0000UKC; Fri, 18 Mar 94 13:25 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 18 Mar 94 13:25:12 PST Date: Fri, 18 Mar 94 13:25:12 PST From: Arpad Muranyi Message-Id: <940318132512_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: V/I checker Text item: Text_1 IBIS folks, Regarding the latest trend in getting the parser to do curve checking: I do not understand what this hurry is all about. I feel that such an important thing should not go without a BIRD. This issue is quite a complex one, and we should not handle it light-heartedly. We might restrict ourselves severly if we do not consider all the possibilities. That needs time. Arpad From ccm!Arpad_Muranyi@intelhf.intel.com Fri Mar 18 13:45:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23557; Fri, 18 Mar 94 13:45:01 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0phmJq-000MOwC; Fri, 18 Mar 94 13:43 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0phmRq-0000EgC; Fri, 18 Mar 94 13:51 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 18 Mar 94 13:51:18 PST Date: Fri, 18 Mar 94 13:51:18 PST From: Arpad Muranyi Message-Id: <940318135118_13@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re[3]: V/I table checking (from Kellee Crisafulli) ---------------------------- Forwarded with Changes --------------------------- From: Don A Telian at SWCAD Date: 3/16/94 5:22PM To: Don A Telian at FMCCM4 To: Arpad Muranyi at FMCCM4 *To: Tim A Schreyer at JFCCM7 *To: jonp@qdt.com at Internet_Gateway *To: ibis@vhdl.org at Internet_Gateway *To: 71436.1314@CompuServe.COM at Internet_Gateway *To: Schreyer@intelhf.intel.com at Internet_Gateway *To: Will_Hobbs@ccm2.jf.intel.com at Internet_Gateway *To: Tim A Schreyer Subject: Re[3]: V/I table checking (from Kellee Crisafulli) ------------------------------------------------------------------------------- So what are we checking for anyways? Sign errors or monotonicity? They are completely two different issues. Arpad Will and ?, Will one of the "several who feel we need to do something about it quickly" please let me know what the rush is. Give me a call if you like, (916)356-502 -9. The monotonicity discussion has been around for a long time with no quick solutions. I do not believe any change to the parser is benign, particularly - one that creates new warning messages. Thanks, Donald Telian From Will_Hobbs@ccm2.jf.intel.com Fri Mar 18 13:54:59 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23687; Fri, 18 Mar 94 13:54:59 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 18 Mar 94 13:52:59 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Fri, 18 Mar 94 13:52:44 -0800 Received: from ccMail by jfsmt2.intel.com id AA764027586 Fri, 18 Mar 94 13:53:06 PST Date: Fri, 18 Mar 94 13:53:06 PST From: "Hobbs, Will" Message-Id: <9402187640.AA764027586@jfsmt2.intel.com> To: ibis@vhdl.org, Arpad Muranyi Subject: Re[4]: V/I table checking (from Kellee Crisafulli) This is not about montonicity but V/I sign. Other mail has already cleared this confusion up, I thought. Will So what are we checking for anyways? Sign errors or monotonicity? They are completely two different issues. Arpad From ccm!Arpad_Muranyi@intelhf.intel.com Fri Mar 18 14:39:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24067; Fri, 18 Mar 94 14:39:58 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0phnB1-000MPEC; Fri, 18 Mar 94 14:37 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0phnJ1-0000K4C; Fri, 18 Mar 94 14:46 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 18 Mar 94 14:46:15 PST Date: Fri, 18 Mar 94 14:46:15 PST From: Arpad Muranyi Message-Id: <940318144615_7@ccm.hf.intel.com> To: ibis@vhdl.org Subject: s2ibis executables ---------------------------- Forwarded with Changes --------------------------- From: Will Hobbs at JFCCM2 Date: 3/18/94 1:53PM To: Arpad Muranyi at FMCCM4 *To: Stephen Peters at SMTPGATE Subject: s2ibis executables ---------------------------- Forwarded with Changes --------------------------- From: slipa@eos.ncsu.edu at SMTPGATE Date: 3/18/94 2:06AM *To: ibis@vhdl.org at SMTPGATE *cc: slipa@eos.ncsu.edu at SMTPGATE Subject: s2ibis executables ------------------------------------------------------------------------------- Text item: Text Item Regarding your question at the end: No. You can use the same output. That statement was just made there to make sure that the ramp measurement is not effected by the packaging. Since the V/I curves are swept slowly, it really does not matter whether the package is there or not, as long as your resistance value (R_pkg) is not huge. Arpad Dear IBIS Community: Hi. I have put s2ibis executables for DEC 2100/3100/5000, SUN SPARCstation, and RS6000 workstations in the incoming directory at vhdl.org. Our WATCOM compiler is broken, and one of the master diskettes is corrupted, so I will not be able to provide the IBM PC version until I can recompile. I think we have another compiler around here, so I may be able to fix it later today or over the weekend. I have tested s2ibis with Berkeley SPICE 2 and 3 on the Decstations, with Berkeley SPICE 3 on the SPARCstations, and with Lipa SPICE 0.0 on an RS6000. Lipa SPICE is a kludge, but I think s2ibis will work OK with both versions of Berkeley SPICE on the RS6000. I would really appreciate it if someone with one of the Berkeley SPICE versions would let me know if it works OK on the RS6000, as I have no idea when it will be loaded onto our machine. The PSPICE routines are also implemented, but we only have PSPICE on IBM PCs, so I won't be able to test them until I get the WATCOM compiler fixed, or a replacement compiler. Regarding the feedback I've gotten so far: I have updated the documentation to reflect the fact that I/O pins require polarity, vih and vil entries on their pindata lines to describe the input part of the functionality. I have added a C_comp entry for each [Model], but I just copied the one in the Version 1.1 spec. I didn't put it in in the first place because I didn't understand what it was. I still haven't put a [POWER_Clamp] table in for Open_drain outputs because that doesn't make much sense to me either. Thanks to Eagle-eye Bob Ross (or should I say Ibis-eye???) and all the others who wrote me about the example output I posted last week. The updated man pages are in the tar files with the executables. Please let me know if you have any questions, failures, suggestions, complaints, or successes with the executables. Steve Lipa slipa@eos.ncsu.edu PS: I would appreciate it if someone would be willing to comment on the following line taken from Section 3 of the NOTES ON DATA DERIVATION METHOD appendix to the IBIS spec: 1. Start with silicon model, remove all packaging. Does this mean that the circuit s2ibis uses for [Ramp] tables has to be different than the one used for the other tables? Is the s2ibis input file syntax too simple to handle this? Should the pindata line for output pins have a SPICENODE and RAMPSPICENODE entry and should there be some way of flagging components to be left out of the [Ramp] SPICE decks? From ccm!Arpad_Muranyi@intelhf.intel.com Fri Mar 18 14:47:47 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24136; Fri, 18 Mar 94 14:47:47 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0phnIa-000MOhC; Fri, 18 Mar 94 14:45 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0phnQa-0000G5C; Fri, 18 Mar 94 14:54 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 18 Mar 94 14:54:04 PST Date: Fri, 18 Mar 94 14:54:04 PST From: Arpad Muranyi Message-Id: <940318145404_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: V/I table checking ---------------------------- Forwarded with Changes --------------------------- From: contec!contec.COM!maah@netcom.com at Internet_Gateway Date: 3/17/94 5:29PM To: Don A Telian at FMCCM4 To: Arpad Muranyi at FMCCM4 *To: Tim A Schreyer at JFCCM7 *To: ibis@vhdl.org at Internet_Gateway Subject: V/I table checking ------------------------------------------------------------------------------- This is another general comment, (not so much a comment on the contents of this EMAIL below). If we JUST want a polarity checker for the MOST COMMON error, I have another most common error to check for: VCC-relative! That needed more explaining than the polarity of the current in my experience, and I have seen more people being confused about that. Should that also be checked for then? Arpad Gentle IBIS folk: Just a couple of points about V/I table checking. 1. I agree with Don and Will that changing the Golden Parser should not be undertaken lightly. I believe we agreed that the Golden Parser IS, in fact, the IBIS specification. Let us follow procedure for changes to the parser, and perhaps issue some interim IBIS application note to provide temporary guidance until an issue is fully resolved. We all know about runaway software where fixing one problem creates a couple more problems which then multiply geometrically. Beyond that...there are the issues raised below. 2. I agree with Bob Ross that the proposed scheme for enforcing data integrity will not work for ECL, nor for a few other device types. (See item 3 of the proposal). Either the "pullup" or the "pulldown" data for the ECL and other device types will violate these requirements. 3. The proposed scheme, item 3, will not always work even for CMOS unless we use only the magnitudes of the currents. Existing data for ageing (old) devices is sometimes presented with positive currents and sometimes with negative currents for CMOS pullup devices. 4. I am not sure that checking only the two end points will always guarantee the conclusions we are assuming here. Current(I) data in between these two points may increase or decrease and still be perfectly valid, particularly if we think of device types other than CMOS. Maah Sango Contec Microelectronics USA Inc. From ccm!Arpad_Muranyi@intelhf.intel.com Fri Mar 18 14:52:47 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24154; Fri, 18 Mar 94 14:52:47 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0phnNQ-000MOiC; Fri, 18 Mar 94 14:50 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0phnVQ-0000G9C; Fri, 18 Mar 94 14:59 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 18 Mar 94 14:59:04 PST Date: Fri, 18 Mar 94 14:59:04 PST From: Arpad Muranyi Message-Id: <940318145904_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Checking V/I tables ---------------------------- Forwarded with Changes --------------------------- From: bward@sugar.NeoSoft.COM at Internet_Gateway Date: 3/17/94 7:56PM To: Don A Telian at FMCCM4 To: Arpad Muranyi at FMCCM4 *To: Tim A Schreyer at JFCCM7 *To: ibis@vhdl.org at Internet_Gateway Subject: Checking V/I tables ------------------------------------------------------------------------------- How about bipolar? The current of a pulldown transistor crosses zero about 0.15 volts on a bipolar output, meaning negative currents between 0 to +0.15 volts! Is that case a sign eror? Arpad I agree with Maah's observations. I would point up that his point 4, -about checking the end points is especially valid. This is why I was suggesting that a point be checked -in the near vicinity of gnd rail voltage and in the near vicinity of power rail -voltage. But then I realized, he said, looking around quickly, this won't work -for ECL. I would propose examining the slope of the line through a point near the -extrema of the swing in that case to determine the direction of current. But -as Bob Ross points out, the sign may not make much sense for ECL anyway. Ah, well, -long live CMOS. But what DO we do with ECL? ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From slipa@eos.ncsu.edu Fri Mar 18 15:54:14 1994 Return-Path: Received: from ecemws.ncsu.edu (c11039-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24495; Fri, 18 Mar 94 15:54:14 PST Received: by ecemws.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA01379; Fri, 18 Mar 1994 18:52:04 -0500 From: slipa@eos.ncsu.edu Message-Id: <9403182352.AA01379@ecemws.ncsu.edu> To: randyh@milpitas.lmc.com Cc: ibis@vhdl.org Subject: DOS version of s2ibis version 0.0 Date: Fri, 18 Mar 94 18:52:01 EST Randy: I have placed a DOS version of s2ibis version 0.0 in the incoming directory at vhdl.org. I have only tested it on a handful of input files, but it seems to work OK. It requires a 386 or 486 with math coprocessor. I have only tested it with PSPICE since we don't have Berkeley SPICE on our PC. I used the tar format because I don't know if our PKZIP is compatible with everyone else's. I guess someone who is more up to speed on IBM stuff should convert the tar file to a zip file. As usual, please let me know if you have any questions, problems, etc. Steve Lipa slipa@eos.ncsu.edu From slipa@eos.ncsu.edu Sat Mar 19 12:29:36 1994 Return-Path: Received: from rand.ece.ncsu.edu (c11046-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08390; Sat, 19 Mar 94 12:29:36 PST Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA25074; Sat, 19 Mar 1994 15:27:33 -0500 From: slipa@eos.ncsu.edu Message-Id: <9403192027.AA25074@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis Date: Sat, 19 Mar 94 15:27:32 EST Dear IBIS Community: Randy has moved the s2ibis tar files to the /pub/ibis/s2ibis directory at vhdl.org. Steve Lipa slipa@eos.ncsu.edu From bward@sugar.NeoSoft.COM Mon Mar 21 06:08:33 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27824; Mon, 21 Mar 94 06:08:33 PST Received: by sugar.NeoSoft.COM id AA18160 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 21 Mar 1994 08:05:54 -0600 Message-Id: <199403211405.AA18160@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: To bird or not to bird ... Date: Mon, 21 Mar 94 8:05:53 CST Hey, Ibis guys! I have been reading the accumulated mail from the past couple of days and see a thread about whether or not to change the parser for the current sign problem without a full blown bird. After thinking about it, it would seem a fairly large departure from "policy" to do that. But since I agree with Kellee that _something is needed here, how about a stand alone utility to check this until we can fully hash out a bird? ( Hatch out a bird? ) Seems it should not be too mch harder to write this than to write the changes into the parser ( He says! ). Just a thought ... I defer to the group to determine how good a thought it is. Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From Will_Hobbs@ccm2.jf.intel.com Mon Mar 21 11:57:12 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00860; Mon, 21 Mar 94 11:57:12 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 21 Mar 94 11:54:09 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 21 Mar 94 11:53:36 -0800 Received: from ccMail by jfsmt2.intel.com id AA764279615 Mon, 21 Mar 94 11:53:35 PST Date: Mon, 21 Mar 94 11:53:35 PST From: "Hobbs, Will" Message-Id: <9402217642.AA764279615@jfsmt2.intel.com> To: ibis@vhdl.org, bward@sugar.NeoSoft.Com (Bob Ward) Subject: Re: To bird or not to bird ... Bob, I came to the same conclusion. My gut says that the parser should only be changed to fix reported bugs, which would require a Bird, in my opinion, or to undergo a revision to match a new IBIS spec version. I would still opt for a bird in the latter case, just to keep the formality there, a Big Bird, if you will, to deal with a big revision. The detail for such a bird would be minimal-- change parser to match spec-- end of bird. For enhancements, I still think a bird is appropriate, but would not be required for a standalone sign checker, or one that checked for vcc relativity per Arpad's comment. A bird could be used then to cause the new utility to be merged into the parser after it is proven good. Will Hey, Ibis guys! I have been reading the accumulated mail from the past couple of days and see a thread about whether or not to change the parser for the current sign problem without a full blown bird. After thinking about it, it would seem a fairly large departure from "policy" to do that. But since I agree with Kellee that _somethin g is needed here, how about a stand alone utility to check this until we can fully hash out a bird? ( Hatch out a bird? ) Seems it should not be too mch harder to write this than to write the changes into the parser ( He says! ). Just a thought ... I defer to the group to determine how good a thought it is. Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From bert@ibmoto.com Mon Mar 21 13:19:29 1994 Return-Path: Received: from apple.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01702; Mon, 21 Mar 94 13:19:29 PST Received: from [129.38.12.13] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA09605; Mon, 21 Mar 94 13:17:22 -0800 for ibis@vhdl.org Received: from lw.ibmoto.com by cerberus.ibmoto.com with SMTP id AA09227 (5.65c/IDA-1.5 for ); Mon, 21 Mar 1994 15:17:05 -0600 Received: by lw.ibmoto.com id AA19173 (5.65c/IDA-1.5 for ibis@vhdl.org); Mon, 21 Mar 1994 21:17:05 GMT Message-Id: <199403212117.AA19173@lw.ibmoto.com> To: ibis@vhdl.org Subject: Re: To bird or not to bird ... Date: Mon, 21 Mar 94 15:17:05 -0600 From: bert@ibmoto.com I am one of the users that has been "gone to the birds" on the current sign issue. I have been getting some of my associates to generate data. The rev. 1.0 spec does not mandate the current convention. The example in the spec is correct, but there is no statement that it has to be a certain way. The confusion is in the current to the load or from the buffer. The reason that I think that the parser should be changed, is that at least one IBIS complient tool has failed to this issue. I am sure that most of the vendor tools will fail. The purpose of the parser is to provide pertinent information about the file correctness. There may rightfully be a discussion of which is to come first the "bird or the egg" (Sorry about that). I would really like to see the "current sign issue" resolved by rev. 2. This would include a little tighter wording in the spec and an upgrade to the parser. The issue on monotonicity seems to be between tools vendors. Some tools allow it and some tools don't. We have a CMOS driver that is non-monotonic -- but a good editor can take care of that :-). So, do we limit the ourselves to a subset of vendors, limit ourselves to a subset of capabilities, issue warnings only, or let the user beware? I suppose this could also become a tool vendor certification issue. Pardon my ramblings.... +------------------------------------+ | | | Lynn Warriner - bert | | Somerset Design Center -- Austin | | | +------------------------------------+ From bob@icx.com Mon Mar 21 16:07:24 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03258; Mon, 21 Mar 94 16:07:24 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04550 for ; Mon, 21 Mar 94 18:57:43 -0500 Date: Mon, 21 Mar 94 15:46:38 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00837; Mon, 21 Mar 94 15:46:38 PST Message-Id: <9403212346.AA00837@icx.com> To: ibis@vhdl.org Subject: Current Convention To IBIS Committee: As a point of clarification both IBIS Versions 1.0 and 1.1 contain a statement "hidden" in the first section: General syntax rules and guidelines. "9) Currents are considered positive when their direction is into the component." To me "component" means the I/O buffer consistent with the [Component] keyword, and the direction is in agreeement with the examples. Perhaps this could be reinforced in the "Tips and Techniques" document Will has proposed. Bob Ross, Interconnectix, Inc. From 71436.1314@CompuServe.COM Mon Mar 21 21:24:31 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05830; Mon, 21 Mar 94 21:24:31 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id AAA11981; Tue, 22 Mar 1994 00:22:22 -0500 Date: 22 Mar 94 00:19:11 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: V/I table checking (from Kellee Crisafulli) Message-Id: <940322051910_71436.1314_HHB44-1@CompuServe.COM> From: Kellee Crisafulli Date: 3-21-93 Re: V/I table checking. Given the amount of EMAIL generated, I will generate a BIRD for the V/I table checking modification and propose that we try to close on it at the next meeting. It seems to me that if the BIRD passes at the regular phone meeting that we could go ahead and make the changes without waiting for the full rev 2.0 release. Does this seem exceptable to everyone? By the way, the email today gets a big EGG-NOD for good humor. (Will,Bert,Bob) keep up the good work. I will attempt to add something per Arpads suggestion also. ***************************************************************** A word about signs. As was pointed out the signs are clearly specified in the beginning of the document. This may not be so obvious by the time people get to the V/I tables and need it. I plan to roll another change into the same BIRD that repeats this definition near the V/I table specification area in the spec. From bob@icx.com Tue Mar 22 23:07:21 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18998; Tue, 22 Mar 94 23:07:21 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01350 for ; Wed, 23 Mar 94 02:01:39 -0500 Date: Tue, 22 Mar 94 22:59:24 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03594; Tue, 22 Mar 94 22:59:24 PST Message-Id: <9403230659.AA03594@icx.com> To: ibis@vhdl.org Subject: BIG BIRD COMMENTS To IBIS Committee and Eric: First, you did an impressive job, Eric, in presenting and packaging Bird10. Most of the considerations here already have some resolution within the proposal, but they are still items for comment and possible refinement. (1) The .pkg file is structured very much like the .ibs file. The header and clarification sections are identical. One difference is that .ibs requires an [End] at the end of the file, but .pkg does not. For parallelism [End] could be required even though each [Define Package Model] section contains an [End Model Data] statement. So the question is, for parallelism, should [End] be required? This is more a format style question than one of required functionality. I am happy with the proposal as is. (2) Should the package model be required to reside in a separate file .pkg? The structure presented from [Define Package Model] through [End Model Data] appear to be a self contained, complete grouping which would fit very well within the same .ibs file as the component or components referencing it. The parser commands for .pkg would be the same for the .ibs file. Also, some components may be supplied with special, one of a kind packages. The search order could be to look first within the .ibs file and then to other ..pkg files. This may be an unnecessary complication beyond what is needed, so I can accept the proposal as is. (3) One concern I have is that the proposed .pkg formats allow PGA alphanumeric nomenclature "A1 .. AA1 .. BB1 ..". The existing .ibs files allow such nomenclature. Can [Row] numbers include alphanumeric arguments in in addition to numerical arguments? The column ordering would have to follow the same order as the rows. While not stated, this could be an additional requirement for numerical entries as well. In the Sparce Matrix format both the [Row] and Index entries could name actual PGA pins. (4) "Banded Matrix" should be "Banded_Matrix". Similarly for "Full Matrix" and "Sparce Matrix". Only keywords within square brackets "[" and "]" allow spaces. (5) Are the same set of units as in the .ibs file allowed in the .pkg file? I assume so and that all of the relevant format conventions in .ibs apply to .pkg. Finally, Eric, you have presented documentation showing conclusively that BIG BIRD really is larger than IBIS. That by itself deserves a 10! Bob Ross, Interconnectix, Inc. From ccm!Derrick_Duehren@intelhf.intel.com Wed Mar 23 21:26:43 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01353; Wed, 23 Mar 94 21:26:43 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pjhuC-000MOgC; Wed, 23 Mar 94 21:24 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pji2r-0000l9C; Wed, 23 Mar 94 21:33 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 23 Mar 94 21:33:28 PST Date: Wed, 23 Mar 94 21:33:28 PST From: Derrick Duehren Message-Id: <940323213328_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS article for EDN, Vendor Support List Text item: Text_1 IBISers, 1. I am writing an IBIS article for targeted placement in EDN. It is based heavily on the Overview document. In it, I plan to include a table of vendors supporting IBIS. Most of you have statements of support in the current Roster of Participants. I'll need relatively short statements. I'll use the existing statements that I have, and edit them down as necessary If you haven't given me a statement, or you want to submit something new, send me your statement by 4/15/94. If you are sending a replacement statement, indicate if you want the changes reflected in the Roster. If, for some reason you don't want to be mentioned, let me know that as well. 2. I would like to add company tag-lines to the Roster entries; "who we are" lines. Many of the participants are smaller companies and may not be widely known. I'll set a limit of 192 characters (3 lines in the roster). For example, Intel's is: "Intel, the world's largest chip maker, is also a leading manufacturer of personal computer networking and communications products." Please submit your company's tag line. Thanks, Derrick Duehren Ye old keeper 'o the Roster ------------------------------------------------------------------------------ Ibis n, pl ibis or ibises: any of several wading birds related to the herons but distinguished by a long slender downwardly curved bill (Webster's 9th) ------------------------------------------------------------------------------ From bracken@valhalla.performance.com Thu Mar 24 19:15:10 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14289; Thu, 24 Mar 94 19:15:10 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA00277; Thu, 24 Mar 94 22:14:59 EST Message-Id: <9403250314.AA00277@valhalla.performance.com> To: bob@icx.com ( Bob Ross) Cc: ibis@vhdl.org Subject: Re: BIG BIRD COMMENTS In-Reply-To: Your message of "Tue, 22 Mar 94 22:59:24 PST." <9403230659.AA03594@icx.com> Date: Thu, 24 Mar 94 22:14:52 -0500 From: bracken@valhalla.performance.com Bob, Thanks for taking the time to read it! With regard to the several good points you brought up: 1) [End] keyword at end of file? Oops! I'll put that in rev 10.1 of the BIRD. 2) Separate .PKG file? It seemed to me from voice discussions in the Forum that several people wanted a separate file for the package, perhaps to minimize the impact on the parser. But since the package models won't appear until Version 2.0 comes out, and since the parser will change a lot then anyway, I'd be happy to see this data encapsulated in the .IBS file. One problem is that, if a tool doesn't do a detailed package analysis and only wants the data from the [Pin] section, it'll have to wade through tons o' package data to find what it wants, thus slowing it down. Comments, anyone else? 3) PGA alphanumeric pin names? Frankly, I didn't realize one could use names like "AA1" for pins. All of the models we have on vhdl.org are from Intel, and those guys always seem to use "1", "2", "3", ..., even for big, nasty 208-pin components. I admit that, on reading the 1.1 spec, I don't see that alphanumeric names are prohibited. Is this an oversight, or is it an intentional feature of the language? The only problem I see with alphanumerics is how to make it clear what the "ordering" of the pin identifiers is. Remember that to exploit symmetry you need to know which matrix index is "bigger" so that you can decide whether an entry is in the upper or lower half. I suppose that we could let the ordering be the same as the order in which the names are given in the [Pin] section of the .IBS file. Before I rewrite the BIRD, I'd like clarification from others on whether the alphanumerics are truly kosher or not. Again, anyone care to comment? 4) "Banded Matrix" -> Banded_Matrix OK! That would make life easier. I'll put it in rev 10.1. 5) Are metric suffixes allowed? Yes. I'll make it explicit in rev 10.1. --Eric From bracken@valhalla.performance.com Thu Mar 24 19:23:28 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14347; Thu, 24 Mar 94 19:23:28 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA00297; Thu, 24 Mar 94 22:23:34 EST Message-Id: <9403250323.AA00297@valhalla.performance.com> To: ibis@vhdl.org Subject: And another thing Date: Thu, 24 Mar 94 22:23:34 -0500 From: bracken@valhalla.performance.com All, In case you're wondering, I also forgot to put a note in the BIRD about the directions for currents. When you're computing the inductances and the mutuals, the reference direction for the currents is always INTO the package, just as for I-V models. For self inductances, it's a moot point; but for mutuals, you will get all kinds of sign confusion unless this is understood. I'll also put this into rev 10.1 (coming Real Soon Now.) --Eric From speters@ichips.intel.com Fri Mar 25 08:08:33 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21381; Fri, 25 Mar 94 08:08:33 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 25 Mar 94 08:06:07 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 25 Mar 94 08:05:50 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 25 Mar 94 08:06:01 PST Message-Id: <9403251606.AA04246@xtg801.intel.com> To: ibis@vhdl.org Subject: Alphanumeric Pin names Date: Fri, 25 Mar 1994 08:06:00 -0800 From: Stephen Peters Hello Eric -- Just a quick note. The standard way of naming PGA package pins is with alphanumerics. A corner of a PGA package might look as follows: 1 2 3 4 5 6 ........ A . . . . . . B . . . . . . C . . . . D . . . . The pin in the upper left hand corner is called A1. Best Regards, Stephen Peters Intel Corp. From slipa@eos.ncsu.edu Sun Mar 27 20:42:33 1994 Return-Path: Received: from rand.ece.ncsu.edu (c11046-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21305; Sun, 27 Mar 94 20:42:33 PST Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA03829; Sun, 27 Mar 1994 23:40:24 -0500 From: slipa@eos.ncsu.edu Message-Id: <9403280440.AA03829@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis Version 0.1 Date: Sun, 27 Mar 94 23:40:22 EST Dear IBIS Community: Hi. I have made the following updates to s2ibis: 1) Ramp table capability 2) Non-integer SPICE node name capability (for PSPICE users) 3) More graceful handling of most input deck syntax errors 4) Documentation updates I am ready to upload the new version (Version 0.1) to vhdl.org, but I would like to fix any known bugs before the update. The problem is that I don't know of any bugs, and I have gotten zero (yes, that's 0.0) feedback since I uploaded Version 0.0. If *anyone* has tried Version 0.0 and had any problems at all, *please* send me some EMAIL, and I will fix them before uploading. If I don't hear from anyone for a couple of days I'll just upload what I've got now. Thanks for your attention. Steve Lipa slipa@eos.ncsu.edu From 71436.1314@CompuServe.COM Wed Mar 30 01:21:11 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28036; Wed, 30 Mar 94 01:21:11 PST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id EAA13016; Wed, 30 Mar 1994 04:19:03 -0500 Date: 30 Mar 94 04:16:08 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: New Bird to fix IBIS_CHK and a bug in BIRD 7.2 Message-Id: <940330091608_71436.1314_HHB32-2@CompuServe.COM> From: Kellee Crisafulli Date: 3-30-94 (very early) Re: IBIS_CHK changes and a possible bug in BIRD 7.2 I submitted the BIRD on IBIS_CHK changes to Will Hobbs and hope that he is able to get it a BIRD number and release it today. While I was creating the new BIRD for the IBIS_CHK changes I believe I discovered a sign problem in BIRD 7.2 in the Pulldown V/I table in the example. I was looking for examples to put in my BIRD and grabbed the V/I tables from BIRD 7.2. My suggested algorithim indicated that there is an error in the Pulldown V/I table. I am finishing this quite late and my brain may be miss-firing, but the V/I tables in BIRD 7.2 seem to have different signs for the Pullup and Pulldown tables. I thought ECL was suppose to have the same signs on both Pullup and Pulldown tables. Anyone care to comment? From bob@icx.com Wed Mar 30 10:46:00 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06690; Wed, 30 Mar 94 10:46:00 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA06780 for ; Wed, 30 Mar 94 13:28:38 -0500 Date: Wed, 30 Mar 94 10:16:25 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10730; Wed, 30 Mar 94 10:16:25 PST Message-Id: <9403301816.AA10730@icx.com> To: ibis@vhdl.org Subject: BIRD7.2 BUG Kellee, My records indicate that there are no Pullup and Pulldown table examples in BIRD7.2. So I wonder if another file inadvertantly got appended to your copy. Based on BIRD4, I agree with your understanding that for ECL type devices, both the Pullup and Pulldown tables are referenced to VCC and should have the same sign. Bob Ross, Interconnectix, Inc. From ccm!Derrick_Duehren@intelhf.intel.com Wed Mar 30 17:49:23 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09686; Wed, 30 Mar 94 17:49:23 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pmBqi-000MNOC; Wed, 30 Mar 94 17:47 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pmC0E-00007GC; Wed, 30 Mar 94 17:57 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 30 Mar 94 17:57:01 PST Date: Wed, 30 Mar 94 17:57:01 PST From: Derrick Duehren Message-Id: <940330175701_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 4/1/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 4/1/94 Bridge: Res: (415) 904-8944 661905 All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. 8:00 Check-in Intros of new IBIS participants Hobbs Review of 2/18/94 minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All IBIS 2.0 Ratification Hobbs - DAC Conference 6/6 - 6/10 - Editing Committee (5/20) IBIS Cookbook Hobbs Spice-to-IBIS Converter Lipa (NCSU) 8:30 Sign of current checking Hobbs, All BIRD 8, Spec. of V/I data monotonicity Crisafulli BIRD 9, Other model types Ross BIRD 10, Coupling effects in package models Bracken BIRD 2, VIH, VIL Thresholds for Inputs Powell Egg 1, mutual pin coupling (ready to hatch?) Bracken 9:00 Simulation temperatures (new BIRD?) Warriner Ramp measurement Reid, Ross, et. al. Egg 2, ramp table? Hobbs 9:30 Canright paper Ward Formal BNF notation (BIRD?) Reed, Harr High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs From Will_Hobbs@ccm2.jf.intel.com Wed Mar 30 17:57:06 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09762; Wed, 30 Mar 94 17:57:06 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 30 Mar 94 17:54:58 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Wed, 30 Mar 94 17:54:38 -0800 Received: from ccMail by jfsmt2.intel.com id AA765078876 Wed, 30 Mar 94 17:54:36 PST Date: Wed, 30 Mar 94 17:54:36 PST From: "Hobbs, Will" Message-Id: <9402307650.AA765078876@jfsmt2.intel.com> To: ibis@vhdl.org Subject: Bird 11, IBIS_CHK V/I sign checking ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 11 ISSUE TITLE: Improving common error detection in IBIS_CHK program. REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: 03-28-94 DATE REVISED: 03-28-94 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Several common problems with IBIS models are not detected with the present version of IBIS_CHK. Two main problems include: 1) Incorrect 'I'(current) signs in the V/I tables. 2) Pullup and POWER_clamp V/I tables are not VCC relative. This BIRD is directed at problem 1 only. A 2nd separate BIRD will be generated to address problem 2. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The following changes apply to version 1.1 and forward versions of the IBIS_CHK program and including testing of some parameters for BIRD 7.2 for ECL model types *************************************************************************** Change 1- Add verbiage on current direction. *************************************************************************** Keywords: [Pullup], [Pulldown], [GND_clamp], [POWER_clamp] Required: Yes, if they exist in the device Description: The data points under these keywords define the V/I curves of the pulldown and pullup structures of an output buffer and the V/I curves of the clamping diodes connected to the GND and the POWER pins, respectively. Currents are considered positive when their direction is into the component. *************************************************************************** Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. *************************************************************************** For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, GND_clamp 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF: The current in the TYPICAL column corresponding to Vmax is less than the current in the TYPICAL column corresponding to Vmin then the table is assumed to have decreasing current. ELSE: The table is assumed to have increasing current. Note: This works for all cases of discontinuities unless the magnitude of discontinuity is such that this model is in all probability competely unrealistic. Examples: *** example with significant change of slope of current at the end point V: I: 0.00 0.0 4.90 50.0ma 4.91 49.9ma 4.93 56.7ma 5.00 3.0ma -> V/I table has increasing current (3.0 > 0) *** example with negative to positive voltages with negative first V: I: -5.00 -0.1ma 0.00 0.0 5.00 100.0ma -> V/I table has increasing current (100 > -0.1) *** example with table data entered postive voltages first V: I: 5.00 10.1ma 0.00 0.0 -5.00 -10.1ma -> V/I table has increasing current (10.1 > -10.1) *** ECL example with sign errors in the Pulldown table [Pulldown] | Voltage I(typ) I(min) I(max) -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m 0.0V 0.0m 0.0m 0.0m 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m -> V/I table is increasing (45 > -40) [Pullup] | Voltage I(typ) I(min) I(max) -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m 0.0V 0.0m 0.0m 0.0m 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m -> V/I table is decreasing (-38 < 32) [GND_clamp] | Voltage I(typ) I(min) I(max) -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m -> V/I table is increasing (0 is > -3900) [POWER_clamp] | Voltage I(typ) I(min) I(max) -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA -> V/I table is decreasing (0 is < 4450) *** An abreviated INTEL model for a CMOS output |**************************************************************************** [Pulldown] | Voltage I(typ) I(min) I(max) -5.00V -38.70mA -29.47mA -51.22mA -1.00V -24.88mA -19.18mA -32.90mA -0.50V -14.35mA -11.06mA -19.05mA 0.00V -11.84pA -554.66pA -11.03pA 100.00mV 3.20mA 2.47mA 4.27mA 200.00mV 6.24mA 4.80mA 8.30mA 4.90V 38.68mA 29.45mA 51.18mA 5.00V 38.70mA 29.47mA 51.22mA 10.00V 39.96mA 30.37mA 53.06mA -> V/I table increasing [GND_clamp] | Voltage I(typ) I(min) I(max) -5.00V -680.00mA NA NA -1.10V -75.50mA NA NA -600.00mV -950.00uA NA NA -500.00mV -78.00uA NA NA -200.00mV 0.00pA NA NA -100.00mV 0.00pA NA NA 0.00V 0.00pA NA NA 5.00V 0.00pA NA NA -> V/I table increasing (0 > -680) [Pullup] | Voltage I(typ) I(min) I(max) -5.00V 38.14mA 27.33mA 54.76mA -4.50V 37.49mA 26.87mA 53.79mA -1.00V 17.13mA 12.81mA 23.55mA -0.50V 9.26mA 6.96mA 12.66mA 0.00V 13.57pA 613.51pA 11.04pA 100.00mV -1.96mA -1.48mA -2.67mA 200.00mV -3.87mA -2.92mA -5.27mA 300.00mV -5.72mA -4.31mA -7.80mA 400.00mV -7.52mA -5.66mA -10.26mA 500.00mV -9.26mA -6.96mA -12.66mA 1.80V -26.79mA -19.79mA -37.25mA 1.90V -27.74mA -20.46mA -38.64mA 2.00V -28.64mA -21.08mA -39.95mA 2.10V -29.47mA -21.66mA -41.19mA 2.20V -30.25mA -22.19mA -42.35mA 4.60V -37.62mA -26.97mA -54.00mA 4.70V -37.76mA -27.06mA -54.20mA 4.80V -37.89mA -27.15mA -54.39mA 4.90V -38.01mA -27.24mA -54.58mA 5.00V -38.14mA -27.33mA -54.76mA 10.00V -44.52mA -33.72mA -61.15mA -> V/I table decreasing [POWER_clamp] | Voltage I(typ) I(min) I(max) -5.00V 1.05A NA NA -1.10V 79.00mA NA NA -1.00V 54.00mA NA NA -900.00mV 29.00mA NA NA -800.00mV 10.40mA NA NA -200.00mV 0.00uA NA NA -100.00mV 0.00uA NA NA 0.00V 0.00pA NA NA -> V/I table decreasing IF the model is any of the following types:(Input_ECL, Output_ECL, I/O_ECL) { Verify that: - Pullup V/I table has increasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current } ELSE { Verify that: - Pullup V/I table has decreasing current - POWER_clamp V/I table has decreasing current - Pulldown V/I table has increasing current - GND_clamp V/I table has increasing current } 4) If any table moves in the wrong direction report the following error message: 'Error found in xxx V/I table at line number nnn!'. Where xxx is one of the following: Pullup, Pulldown, POWER_clamp, GND_clamp. Where nnn is the line number. Note: It is acceptable to stop the parser after the first line found with this error. *************************************************************************** Change 3- Add a header comment statement at the TOP of the IBIS_CHK program to insure that new changes to the IBIS_CHK program donot break tests that worked in old MAJOR versions. This approach makes the program larger however it insures the parser always works the same on older versions of IBIS. This apporach uses more memory, but has the reward of low maintaining costs. The IBIS_CHK program is very small and would not be effected by this until many revisions have occured. *************************************************************************** NOTICE TO ANY PERSON MODIFING THIS PROGRAM!----------------------------------- This program SHALL NOT BE MODIFIED unless there is an associated IBIS BIRD. Said BIRD shall be agreed upon by IBIS committee vote. The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED when adding code for the next version of the IBIS specification. Instead completely new code for all functions and features shall be created. This may require duplication of numerous functions. Each function shall be preceded by VXX_ where XX is the MAJOR version of the IBIS specification which is being parsed and tested. A MAJOR version would for example be 1.x going to 2.x. A MINOR version would for example be 1.1 to 1.2. Functions using the above syntax would look as follows: V01_GetValue MINOR revisions DO NOT required new code. Startup code shall be provided at the top of the program which reads the version number from the IBIS file and runs the portion of the program corresponding to that MAJOR version. Code which is used only by the program startup function is not duplicated. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Change 1) Suggested from inputs of several people in Email and at the at previous IBIS meetings. Change 2) Defective IBIS models are slipping through the IBIS_CHK program. A method for determining sign errors in V/I table was determined based on inputs from several people including: Kellee Crisafulli, HyperLynx Jon Powell, Quad Design Arpad, Intel Bob Ward, TI Bob Ross, Interconnectix Maah Sango, Contec I reviewed all the comments that have been submitted and I believe this method will work with all conditions mentioned so far. Change 3) I am proposing a method of insuring that future IBIS_CHK modifications do not affect the parsing of older IBIS files. This only applies to MAJOR revisions in the specification, like 2.0 coming up. This would not apply to this update, it would however be added to the program header information now and would apply to all future MAJOR updates to the IBIS specification. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: Comments about EMAIL leading up to this BIRD-------------------------------- From: Jon Powel, qdt Cases that will not work for proposed algorithm V: I: 0.0 0.0 3.5 50.0 3.51 49.9 3.52 49.8 3.53 49.7 5.0 100.0 any OC any OD If current is not negative at GND for the pullup then it cannot pullup? (except for ECL OC etc?). ****************** From: Arpad, Intel What happens if there are equal number of increases and decreases in a curve? Most of the curves I am generating lately do that and I do not think I am doing it wrong. ******************** Bob Ward, TI I think the proposed method of current sign determination might run into trouble in at least two cases. One is when there are exactly the same number of rising and falling segments. The other is the same problem one runs into testing for monotonicity of the independent variable. That problem is that very small oscillations occur on the "flat" part of a numerically generated curve, not so much because they are real, but because of the nature of small numbers, finite precision, and floating point round off. ****************************** Bob Ross, Interconnectix, Inc. If this proposal is adopted, it would apply to just IBIS Version1.1. The polarity rules do not comply with proposed IBIS extensions BIRDS 3 and 4 for ECL type devices. For ECL type devices, the polarities of both the Pullup and Pulldown tables will go in the same (decreasing) direction because BOTH tables are tabulated referenced to Vcc using Vtable = Vcc - Vout. I am sure this will become another area of confusion, justifying a test. ************************** Maah Sango, Contec Microelectronics USA Inc 2. I agree with Bob Ross that the proposed scheme for enforcing data integrity will not work for ECL, nor for a few other device types. (See item 3 of the proposal). Either the "pullup" or the "pulldown" data for the ECL and other device types will violate these requirements. 3. The proposed scheme, item 3, will not always work even for CMOS unless we use only the magnitudes of the currents. Existing data for ageing (old) devices is sometimes presented with positive currents and sometimes with negative currents for CMOS pullup devices. 4. I am not sure that checking only the two end points will always guarantee the conclusions we are assuming here. Current(I) data in between these two points may increase or decrease and still be perfectly valid, particularly if we think of device types other than CMOS. ******************************* Arpad, Intel If we JUST want a polarity checker for the MOST COMMON error, I have another most common error to check for: VCC-relative! That needed more explainingthan the polarity of the current in my experience, and I have seen more people being confused about that. Should that also be checked for then? ******************************************************************************* From 71436.1314@CompuServe.COM Wed Mar 30 20:15:36 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10793; Wed, 30 Mar 94 20:15:36 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id XAA05926; Wed, 30 Mar 1994 23:12:27 -0500 Date: 30 Mar 94 23:09:18 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "INTERNET:bob@icx.com" Cc: IBIS ALL Subject: BIRD7.2 BUG Message-Id: <940331040917_71436.1314_HHB28-1@CompuServe.COM> From: Kellee Crisafulli Bob , I was working too late. What I found was the tail end of BIRD 4 revisions just before the standard V/I table example. I thought the example was for an ECL device because the text just prior to the example talks about ECL V/I tables. Perhaps Bird 4 or 7 which ever is the most related should add a line above the V/I table example stating that it is an example of a typical CMOS output. What do you think? It could also be that I was working too late. Have a great day.. Talk to you Friday... Kellee From wr@apathix.cadlab.de Thu Mar 31 01:34:20 1994 Return-Path: Received: from mail.Germany.EU.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15893; Thu, 31 Mar 94 01:34:20 PST Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.4.3.a) via EUnet id LAA29596; Thu, 31 Mar 1994 11:33:18 +0200 Received: by cadlab.cadlab.de (5.51/12.71); Thu, 31 Mar 94 11:01:34 +0100 Message-Id: <9403310930.AA29415@apathix.cadlab.de> Received: by apathix.cadlab.de (4.1/12.71); Thu, 31 Mar 94 11:30:19 +0200 Date: 3/31/94 From: wr@cadlab.cadlab.de Subject: Next IBIS Open forum meeting Apparently-To: IBIS@vhdl.org Dear IBISians, as Friday is a christian holiday (Karfriday) in Germany, we are not able to participate at the meeting. Nevertheless we wish a successfull conference. Best regards Werner Rissiek, SNI/Cadlab From johnb@redact.co.uk Thu Mar 31 03:37:54 1994 Return-Path: Received: from eros.britain.eu.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18855; Thu, 31 Mar 94 03:37:54 PST Message-Id: <9403311137.AA18855@vhdl.vhdl.org> Received: from redact.co.uk by eros.britain.eu.net with UUCP id ; Thu, 31 Mar 1994 12:33:51 +0100 Received: by redact (5.0/Redac-Exterior-Gateway-V1.2) id AA00563; Thu, 31 Mar 1994 12:27:55 +0000 From: johnb@redact.co.uk Date: Thu, 31 Mar 94 12:27:55 GMT Apparently-To: >Received: from redpo.UUCP by redact (4.1/Redac-Exterior-Gateway-V1.2) id AA12727; Thu, 31 Mar 94 12:26:57 BST Organisation: Racal-Redac Systems Ltd., Tewkesbury, UK Received: from redact.co.uk by redactcouk.redact.co.uk; Thu, 31 Mar 1994 12:27 BST Received: from redpo.UUCP by redact (4.1/Redac-Exterior-Gateway-V1.2) id AA12727; Thu, 31 Mar 94 12:26:57 BST Received: from [89.32.39.5] (mac4_tsupp) by redpo (4.1/Redac-Interior-Gateway-V1.1) id AA19010; Thu, 31 Mar 94 12:18:53 BST Date: Thu, 31 Mar 94 12:18:52 BST Message-Id: <9403311118.AA19010@redpo> To: vhdl.org!IBIS From: redact.co.uk!johnb (John Berrie) Subject: Meeting 4/1/94 Content-Type: text Content-Length: 268 Dear IBIS colleagues, I'm afraid I'll have to give the 4/1/94 meeting a miss as it's a public holiday (Good Friday) here in the U.K, and we'll be talking about Easter eggs rather than BIRDs eggs. Here's hoping you have a sucessful meeting. Best Regards John Berrie From huq@rockie.nsc.com Thu Mar 31 08:58:28 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21077; Thu, 31 Mar 94 08:58:28 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA19529 for ibis@vhdl.org; Thu, 31 Mar 94 08:56:22 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA17912 for ibis@vhdl.org; Thu, 31 Mar 94 08:56:21 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA12353; Thu, 31 Mar 94 09:00:50 PST Date: Thu, 31 Mar 94 09:00:50 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9403311700.AA12353@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS mentioned in Seminar Cc: huq@rockie.nsc.com Hi Fellow IBIS gurus: I attended the 1994 HP ATM/Broadband Design seminar yesterday in Santa Clara,CA and in one of the papers presented on 'Advanced Simulation and Modeling of Communication Hardware Designs', IBIS was mentioned couple of times as the way to go in providing models for all to use. The speaker pointed out how difficult it is to get models today and that IBIS would solve this problem once vendors and tools makers in the industry participate. I won't make it to the April 1st meeting as I will out to a class. I would be very interested to find the status of the Cook Book. Regards, Syed Huq National Semiconductor Corp Santa Clara, CA From contec!contec.COM!maah@netcom.com Thu Mar 31 15:37:23 1994 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25988; Thu, 31 Mar 94 15:37:23 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id PAA14476; Thu, 31 Mar 1994 15:16:50 -0800 Received: from contec4.contec.COM ([192.9.200.168]) by contec.COM (4.1/SMI-4.1) id AA11112; Thu, 31 Mar 94 14:31:17 PST Date: Thu, 31 Mar 94 14:31:17 PST From: maah@contec.COM Message-Id: <9403312231.AA11112@contec.COM> To: ibis@vhdl.org Subject: Next IBIS Open Forum meeting Gentle IBIS folk: I heard that about 30 percent of businesses will be closed on April 1, 1994, for the Good Friday holiday. Also a couple of guys from abroad will not be able to attend our next IBIS Open Forum meeting because of this holiday. Should we delay the April 1, 1994 IBIS Open Forum meeting for a few days, maybe until Friday of next week? Maah Sango Contec Microelectronics USA Inc. From bward@sugar.NeoSoft.COM Thu Mar 31 16:55:55 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26433; Thu, 31 Mar 94 16:55:55 PST Received: by sugar.NeoSoft.COM id AA05674 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 31 Mar 1994 18:52:40 -0600 Message-Id: <199404010052.AA05674@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Delaying tomorrow's forum meeting Date: Thu, 31 Mar 94 18:52:34 CST All - There has been some discussion of delaying the forum meeting from tomorrow to the following Friday. I will be in the Modelling Council meeting next Friday and so would request some other day than that if it must be delayed. While we are also closed for the hol;iday, I will be in plant tomorrow anyway, so holding it tomorrow as scheduled is not a problem for me. Thanks, Bob bward@neosoft.com From Will_Hobbs@ccm2.jf.intel.com Thu Mar 31 20:33:43 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28053; Thu, 31 Mar 94 20:33:43 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 31 Mar 94 20:31:06 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Thu, 31 Mar 94 20:30:49 -0800 Received: from ccMail by jfsmt2.intel.com id AA765174672 Thu, 31 Mar 94 20:31:12 PST Date: Thu, 31 Mar 94 20:31:12 PST From: "Hobbs, Will" Message-Id: <9402317651.AA765174672@jfsmt2.intel.com> To: maah@contec.COM, ibis@vhdl.org Subject: Next IBIS Open Forum meeting Maah and others, Unfortunately, I won't be available next Friday. I suggest we meet as scheduled and make that our first topic. We can see what we can get done, and if the number of people absent warrents a re-convening, either reschedule in a couple of weeks and a couple of weeks after that to get back on track, or pick another day than Friday. Will Gentle IBIS folk: I heard that about 30 percent of businesses will be closed on April 1, 1994, for the Good Friday holiday. Also a couple of guys from abroad will not be able to attend our next IBIS Open Forum meeting because of this holiday. Should we delay the April 1, 1994 IBIS Open Forum meeting for a few days, maybe until Friday of next week? Maah Sango Contec Microelectronics USA Inc.