From owner-ibis Thu Aug 6 14:09:42 1998 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21817 for ; Thu, 6 Aug 1998 14:09:41 -0700 (PDT) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.8.8/8.7.3) with SMTP id RAA08862 for ; Thu, 6 Aug 1998 17:04:52 -0400 (EDT) Received: by fishbowl02.emc.com with VINES-ISMTP; Thu, 6 Aug 98 17:05:05 -0400 Date: Thu, 6 Aug 98 16:59:42 -0400 Message-ID: X-Priority: 3 (Normal) To: From: "fabrizio zanella" Reply-To: Errors-to: Subject: non-monotonicity X-Incognito-SN: 1467 X-Incognito-Version: 4.11.23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii IBIS experts/users: I have a question regarding monotonicity of IBIS model curves. I have encountered some logic IBIS models (clock drivers) which pass the golden parser (with some warnings), but do not pass the IBIS parser within my simulator. The error I get is 'the sum of the maximum clamp curves and the pullup curve is non-monotonic at -0.5 volts'. I know for a fact that another simulator we have in house parsed these models. My question is, do some devices naturally have non-monotonic curves, and should an IBIS simulator accept this as a standard condition? Does anyone have experience modifying IBIS models to remove the non-monotonicity? Thank you very much, Fabrizio Zanella Hardware Engineering email: fzanella@emc.com (508) 435-1000 Ext. 4645 Fax: (508) 435-8949 EMC Corporation 171 South Street Hopkinton, MA 01748-9103 From owner-ibis Thu Aug 6 14:57:24 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21962 for ; Thu, 6 Aug 1998 14:57:24 -0700 (PDT) Received: (from smtp@localhost) by relayhost.vlsi.com (SMI-8.6/) id OAA18741; Thu, 6 Aug 1998 14:53:04 -0700 Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0) id xma018725; Thu, 6 Aug 98 14:52:45 -0700 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 31ZQYXAG; Thu, 6 Aug 1998 14:53:32 -0700 Sender: dsession@vlsi.com Message-ID: <35CA25AB.6FCBD6FF@vlsi.com> Date: Thu, 06 Aug 1998 14:52:43 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: fabrizio=zanella%eng%emchop1@fishbowl02.lss.emc.com CC: ibis@vhdl.org Subject: Re: non-monotonicity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit fabrizio zanella wrote: > > IBIS experts/users: > I have a question regarding monotonicity of IBIS model curves. I have > encountered some logic IBIS models (clock drivers) which pass the golden > parser (with some warnings), but do not pass the IBIS parser within my > simulator. The error I get is > 'the sum of the maximum clamp curves and the pullup curve is non-monotonic > at -0.5 volts'. > I know for a fact that another simulator we have in house parsed these > models. My question is, do some devices naturally have non-monotonic > curves, and should an IBIS simulator accept this as a standard condition? > Does anyone have experience modifying IBIS models to remove the > non-monotonicity? Some drivers really do have non-monotonic curves. We have some which are protected against certain power states by having a line-operated turnoff device on the driver gates, for instance; these have slope reversals in their V/I curves. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Aug 6 15:56:49 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA22042 for ; Thu, 6 Aug 1998 15:56:48 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id PAA05824; Thu, 6 Aug 1998 15:52:59 -0700 (PDT) Received: from milliways.cadence.com(158.140.142.7) by mailgate.cadence.com via smap (mjr-v1.2) id xma902443976.005800; Thu, 6 Aug 98 15:52:56 -0700 Received: (from geoff@localhost) by milliways.Cadence.COM (8.7.3/8.7.3) id PAA09805; Thu, 6 Aug 1998 15:52:05 -0700 (PDT) Date: Thu, 6 Aug 1998 15:52:05 -0700 (PDT) From: Geoffrey Ellis Message-Id: <199808062252.PAA09805@milliways.Cadence.COM> To: fzanella@emc.com Subject: RE: non-monotonicity Cc: ibis@vhdl.org A clamp curve characterizes a clamp diode. This curve should be absolutely monotonic in forward bias region. In the reverse bias (nano-amp leakage) region, the curve might not be monotonic. Pullup and pulldown curves are not always monotonic. *********************************************************************** * Geoffrey Ellis * * Cadence Design Systems phone: 831-685-6559 * * 9057 Soquel Drive fax: 831-685-6556 * * Aptos, CA 95003 E-mail: geoff@cadence.com * *********************************************************************** From owner-ibis Thu Aug 6 17:33:26 1998 Received: from ns1.digital.com.sg (ns1.digital.com.sg [203.127.158.130]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA22191 for ; Thu, 6 Aug 1998 17:33:24 -0700 (PDT) Received: from zpopf1.zpo.dec.com (zpopf1.zpo.dec.com [16.178.16.251]) by ns1.digital.com.sg (8.8.8/8.8.8/WV1.0c) with ESMTP id IAA08788; Fri, 7 Aug 1998 08:28:19 +0800 (SST) Received: by zpopf1.zpo.dec.com with Internet Mail Service (5.5.1960.3) id ; Fri, 7 Aug 1998 08:28:30 +0800 Message-ID: <2689006BD5ACD011AE890000F82295EB0165C747@taoexc1.tao.dec.com> From: John Lin - TAO To: "'si-list@silab.Eng.Sun.COM'" , "'ibis@vhdl.org'" Cc: Hwcheng , Jj Leu , Steve Ting Subject: Minimum or Maximum package for SI Worst Case simulation? Date: Fri, 7 Aug 1998 08:28:15 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Dear SI experts, When doing the worst case simulation of signal integrated for a design, how shall I use the IBIS models? Here, the worst case means the maximum amount for overshoot, undershoot and ringback. I know that I shall use the IBIS models with Max V-I table and Minimum C_comp. I am not sure if use minimum package(R,L,C) or maximum package(R,L,C) information. One article says the minimum package information shall be used to do the worst case analysis. (the article is on http://www.eia.org/eig/ibis/intel.htm ) Can somebody explain why? Thanks, JOHNLIN From owner-ibis Thu Aug 6 19:21:19 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA22355 for ; Thu, 6 Aug 1998 19:21:19 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id TAA08477; Thu, 6 Aug 1998 19:17:29 -0700 (PDT) Message-Id: <3.0.5.32.19980806191235.00e23430@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Aug 1998 19:12:35 -0700 To: John Lin - TAO , "'si-list@silab.Eng.Sun.COM'" , "'ibis@vhdl.org'" From: Kellee Crisafulli Subject: Re: Minimum or Maximum package for SI Worst Case simulation? Cc: Hwcheng , Jj Leu , Steve Ting In-Reply-To: <2689006BD5ACD011AE890000F82295EB0165C747@taoexc1.tao.dec.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi John, At 08:28 AM 8/7/98 +0800, John Lin - TAO wrote: >When doing the worst case simulation of signal integrated for a design, >how shall I use the IBIS models? Here, the worst case means the maximum >amount for overshoot, undershoot and ringback. >I know that I shall use the IBIS models with Max V-I table and Minimum >C_comp. Actually this is a valid assumption only for outputs, for inputs you should use max C_comp and minimum V-I for the clamps to get the biggest reflection. >I am not sure if use minimum package(R,L,C) or maximum package(R,L,C) >information. Min/max pin information should only be used if the pin specific information is not provided. The pin specific informaiton has not min/max data. If no pin specific information is provided than use the R,L,C min to get the largest signal launched (i.e. most energy for reflections). Use the R,L,C maximum for the worst step into the line and most local ringing at the device. >One article says the minimum package information shall be used to do the >worst case analysis. (the article is on >http://www.eia.org/eig/ibis/intel.htm > ) > >Can somebody explain why? > > > > Thanks, > >JOHNLIN > > > ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Fri Aug 7 08:31:45 1998 Received: from mail-gw2.pacbell.net (mail-gw2.pacbell.net [206.13.28.53]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA23781 for ; Fri, 7 Aug 1998 08:31:43 -0700 (PDT) Received: from pacbell.net (ppp-209-79-182-246.vntrcs.pacbell.net [209.79.182.246]) by mail-gw2.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id IAA16051; Fri, 7 Aug 1998 08:27:43 -0700 (PDT) Message-ID: <35CB1C16.EB3072D4@pacbell.net> Date: Fri, 07 Aug 1998 08:24:06 -0700 From: Jon Powell Reply-To: jonp@qdt.com Organization: Viewlogic Consulting Services X-Mailer: Mozilla 4.04 [en]C-PBI-NC404 (Win95; I) MIME-Version: 1.0 To: fabrizio=zanella%eng%emchop1@fishbowl02.lss.emc.com CC: ibis@vhdl.org Subject: Re: non-monotonicity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There are 3 issues (I am aware of) on monotonicity: 1) The measuring technique used in making models can sometime lead to non-monotonicity through round off error (though this is usually so far from the operating region that you don't care much). 2) The non-monotonicity could be extremely small and caused by small noise oscillations in a spice simulation in an area that was supposed to be flat. 3) The device is really non-monotonic in the operating range. If this is true, this implies the device is using some active feedback technique. If THIS is true then there is some implied delay in the feedback loop. This feedback delay is not modeled by IBIS. The IBIS committee has requested IC vendors to come forward with SPICE circuit examples of devices that exhibit this effect so that we can figure out a behavioral mechanism to describe it but (at least to my current knowledge) no such circuit has been delivered. So your choices are: Ignore the non-monotonicity (that is, remove it from the IV curve) or simulate with the non-montonicity but with no info about the delay. Depending on how the circuit works, either of these could the best approach and I believe different EDA vendors have made different decisions on what is most appropriate in their simulators. I think people who have problems with IBIS models showing this effect should go ask their EDA vendors what is the appropriate solution for a given model. regards jon From owner-ibis Fri Aug 7 09:31:35 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA23902 for ; Fri, 7 Aug 1998 09:31:35 -0700 (PDT) Received: (from smtp@localhost) by relayhost.vlsi.com (SMI-8.6/) id JAA11549; Fri, 7 Aug 1998 09:27:12 -0700 Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0) id xma011539; Fri, 7 Aug 98 09:27:01 -0700 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 31ZQYXHL; Fri, 7 Aug 1998 09:27:48 -0700 Sender: dsession@vlsi.com Message-ID: <35CB2AD4.486C087E@vlsi.com> Date: Fri, 07 Aug 1998 09:27:00 -0700 From: "D. C. Sessions" Reply-To: ibis@eda.org Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ibis@vhdl.org CC: jonp@qdt.com Subject: Re: non-monotonicity References: <35CB1C16.EB3072D4@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jon Powell wrote: > 3) The device is really non-monotonic in the operating range. If this is > true, this implies the device is using some active feedback technique. > If THIS is true then there is some implied delay in the feedback loop. > This feedback delay is not modeled by IBIS. The IBIS committee has > requested IC vendors to come forward with SPICE circuit examples of > devices that exhibit this effect so that we can figure out a behavioral > mechanism to describe it but (at least to my current knowledge) no such > circuit has been delivered. So your choices are: Ignore the > non-monotonicity (that is, remove it from the IV curve) or simulate with > the non-montonicity but with no info about the delay. Depending on how > the circuit works, either of these could the best approach and I believe > different EDA vendors have made different decisions on what is most > appropriate in their simulators. Missed the request, Jon. Here's one: .SUBCKT od_drvr i pad vdd vss R1 pad rpad 200 MN1 pad ngate vss vss NCH L=0.5u W=200u MN2 ngate rpad vss vss NCH L=1.0u W=6u MN3 rpad vss vss vss NCH L=0.5u W=40u MN4 ngate i vss vss NCH L=0.4u W=50u MP4 ngate i vdd vdd PCH L=0.4u W=120u .ENDS od_drvr Use just about any 0.35u process models. You'll find that the V/I curve becomes nonmonotonic at higher voltages. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Fri Aug 7 10:06:37 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA23961 for ; Fri, 7 Aug 1998 10:06:36 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA15842; Fri, 7 Aug 1998 10:02:15 -0700 (PDT) Received: from kappa2.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA11124; Fri, 7 Aug 1998 10:02:14 -0700 (PDT) Received: by localhost with Microsoft MAPI; Fri, 7 Aug 1998 09:58:23 -0700 Message-ID: <01BDC1E9.E9D60520.tom_dagostino@mentorg.com> From: tomda To: "'Geoffrey Ellis'" , "fzanella@emc.com" Cc: "ibis@vhdl.org" Subject: RE: non-monotonicity Date: Fri, 7 Aug 1998 09:58:22 -0700 Organization: Mentor Graphics X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It would be nice if the world was perfect. After measuring 1000's of I/O pins I can say with much certainty that not all clamp "diodes" behave monotonically in the "forward bias region". Typical of this behavior are ground protection devices that show abrupt increases in current when swept from a negative voltage to ground. Tom Dagostino Mentor Graphics Zeelan Model Libraries -----Original Message----- From: Geoffrey Ellis [SMTP:geoff@cadence.com] Sent: Thursday, August 06, 1998 3:52 PM To: fzanella@emc.com Cc: ibis@vhdl.org Subject: RE: non-monotonicity A clamp curve characterizes a clamp diode. This curve should be absolutely monotonic in forward bias region. In the reverse bias (nano-amp leakage) region, the curve might not be monotonic. Pullup and pulldown curves are not always monotonic. *********************************************************************** * Geoffrey Ellis * * Cadence Design Systems phone: 831-685-6559 * * 9057 Soquel Drive fax: 831-685-6556 * * Aptos, CA 95003 E-mail: geoff@cadence.com * *********************************************************************** From owner-ibis Fri Aug 7 15:42:34 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA24627 for ; Fri, 7 Aug 1998 15:42:34 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA08814; Fri, 7 Aug 1998 15:38:14 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA28746; Fri, 7 Aug 1998 15:38:13 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA03626; Fri, 7 Aug 98 15:38:12 PDT Date: Fri, 7 Aug 98 15:38:12 PDT Message-Id: <9808072238.AA03626@bob> To: ibis@eda.org Subject: BIRD53 - IBIS FILE CHARACTER SET To All: Per discussion at the August 7, 1998 IBIS meeting, Geoffrey Ellis has submitted BIRD53. It will be scheduled for a vote at the August 28, 1998 meeting. Bob Ross Interconnectix/Mentor Graphics Buffer Issue Resolution Document (BIRD) BIRD ID#: 53 ISSUE TITLE: IBIS File Character Set REQUESTOR: Geoffrey Ellis, Cadence Design Systems DATE SUBMITTED: 7 August 1998 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: While the general syntax rules and guidelines say, "The file must have no more than 80 characters per line," the rules to not say which character sequences are legal to terminate a line, e.g. "\r\n" (carriage return followed by new-line), etc. Also, the Specification does not say whether or not the line termination haracter(s) count against the 80 character limit. Also, the Specification does not state which characters are legal in an IBIS file, other than that it is an ASCII file. Although ASCII is a 7-bit code ("US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986"), some published standards make reference to "8-bit ASCII characters", for example "File Transfer Protocol RFC 542 NIC 17759". The IBIS Specification should make clear that neither 8-bit characters nor ASCII controls (other than tabs and line terminators) are allowed in an IBIS file. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The "General Syntax Rules and Guidelines" section contains 13 numbered items, including item 4 which states: 4) The file must have no more than 80 characters per line. We propose to modify item 4, and to add item 14, as follows: 4) A line of the file may have at most 80 characters, followed by a line termination sequence. The line termination sequence must be one of the sequences "\n" (new-line character) or "\r\n" (carriage rerturn followed by new-line character). 14) Only ASCII characters, as defined in ANSI Standard X3.4-1986, may be used in an IBIS file. ASCII is a 7-bit code; 8-bit characters are not allowed. Also, ASCII control characters (those numerically less than hex 20) are not allowed, except for tabs or in a line termination sequence. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: At the lowest level of detail, the IBIS Specification needs to say which characters are legal, and what constitutes a "line". ASCII files produces in a Microsoft/PC environment have lines which end with "\r\n", while ASCII files produced on UNIX have lines which end with "\n". An IBIS parser should accept either line termination sequence, regardless of the environment in which the parser runs. Any other line termination sequence should be ruled out. We have already seen one IBIS file on the Web with lines ending in just \r. This raised BUG30 against the parser. At Cadence, we have seen an IBIS file containing 8-bit characters, supplied by a customer. Since ASCII control characters (with exceptions noted) were never intended to be allowed in an IBIS file, the IBIS specification should rule these out. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From owner-ibis Mon Aug 10 00:45:47 1998 Received: from alcatel.fr (news2.alcatel.fr [194.133.58.131]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA27885 for ; Mon, 10 Aug 1998 00:45:45 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (ALCANET/SMTP) with ESMTP id JAA11380; Mon, 10 Aug 1998 09:47:50 +0200 Received: from aifhs1.alcatel.fr (aifhs1.alcatel.fr [155.132.180.86]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA27767; Mon, 10 Aug 1998 09:34:46 +0200 (MET DST) Received: from aifhs2.alcatel.fr (localhost [127.0.0.1]) by aifhs1.alcatel.fr (8.8.8/8.8.8) with ESMTP id JAA13205; Mon, 10 Aug 1998 09:37:00 +0200 (MET DST) Received: from las40334.ln.cit.alcatel.fr (las40334.ln.cit.alcatel.fr [155.132.226.32]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id JAA27506; Mon, 10 Aug 1998 09:34:08 +0200 (MET DST) Received: from las41247.ln.cit.alcatel.fr by las40334.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01772; Mon, 10 Aug 98 09:45:12 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00331; Mon, 10 Aug 98 09:45:39 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <35CEA523.167EB0E7@ln.cit.alcatel.fr> Date: Mon, 10 Aug 1998 09:45:39 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@eda.org Cc: Bob Ross Subject: Re: BIRD53 - IBIS FILE CHARACTER SET References: <9808072238.AA03626@bob> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Only ASCII characters, as defined in ANSI Standard X3.4-1986, may > be used in an IBIS file. ASCII is a 7-bit code; 8-bit characters > are not allowed. Is there a technical reason to restrict IBIS to 7-bit codes? Our in-house IBIS models can contain 8-bit characters - those generated by a standard French keyboard - usually in comment fields, or under [Source] and [Notes]. I hope that if BIRD53 is accepted, these files will pass ibischk, with at worst, the accents being flagged simply for information purposes. From owner-ibis Mon Aug 10 11:11:44 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29324 for ; Mon, 10 Aug 1998 11:11:44 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id LAA06289; Mon, 10 Aug 1998 11:07:53 -0700 (PDT) Received: from milliways.cadence.com(158.140.142.7) by mailgate.cadence.com via smap (mjr-v1.2) id xma902772471.006283; Mon, 10 Aug 98 11:07:51 -0700 Received: (from geoff@localhost) by milliways.Cadence.COM (8.7.3/8.7.3) id LAA00245; Mon, 10 Aug 1998 11:06:59 -0700 (PDT) Date: Mon, 10 Aug 1998 11:06:59 -0700 (PDT) From: Geoffrey Ellis Message-Id: <199808101806.LAA00245@milliways.Cadence.COM> To: fitzpat1@ln.cit.alcatel.fr, ibis@eda.org Subject: RE: Re: BIRD53 - IBIS FILE CHARACTER SET This should make an interesting discussion at the next IBIS Open Forum. My goal is to have a standard which clearly states which characters are allowed in an IBIS file. At present, the standard says ASCII, which is a 7-bit code. Therefore, the wording in this BIRD regarding ASCII is a clarification of the existing standard, not a change. Perhaps we should change from ASCII to ISO 8859-1, which supports accented characters as well (8-bit codes, with the first 128 codes the same as ASCII). However, this brings up some issues: - Will your text editor handle such a file? Apparently recent versions of emacs to have ISO 8859-1 support. Also vi on SunOS can handle these, if the command setenv LC_CTYPE iso_8859_1 is given before editing. However, use of the LC_CTYPE environment variable is not well documented by Sun. Users in the USA would no doubt find many difficulties editing such files. - Can 8-bit characters appear in the filenames? Yes, if the local OS accepts such filenames. Apparently SunOS does. I am not sure about other OS's, in particular MS-DOS. Note that item 3 of the general syntax rules and guidelines says that filenames "must conform to DOS rules". - Will you be able to print such a file? Very few printers in the USA directly understand the ISO 8859-1 character set. For some printers, including Postscript printers, it will be possible to print the file using a special filter. Other printers will not be able to print them. - Will you be able to E-mail such a file? Yes, as long as your E-mail system accepts attachments of binary files. Any proposal to change the character set from ASCII to ISO 8859-1 should address these issues. *********************************************************************** * Geoffrey Ellis * * Cadence Design Systems phone: 831-685-6559 * * 9057 Soquel Drive fax: 831-685-6556 * * Aptos, CA 95003 E-mail: geoff@cadence.com * *********************************************************************** >> Only ASCII characters, as defined in ANSI Standard X3.4-1986, may >> be used in an IBIS file. ASCII is a 7-bit code; 8-bit characters >> are not allowed. > >Is there a technical reason to restrict IBIS to 7-bit codes? > >Our in-house IBIS models can contain 8-bit characters - those generated >by a standard French keyboard - usually in comment fields, or under >[Source] and [Notes]. I hope that if BIRD53 is accepted, these >files will pass ibischk, with at worst, the accents being flagged >simply for information purposes. From owner-ibis Mon Aug 10 14:49:49 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA29743 for ; Mon, 10 Aug 1998 14:49:48 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id OAA12809 for ; Mon, 10 Aug 1998 14:45:52 -0700 (PDT) Received: from gda.cadence.com(158.140.106.10) by mailgate.cadence.com via smap (mjr-v1.2) id xma902785548.012771; Mon, 10 Aug 98 14:45:49 -0700 Received: from pc-toddw (d158140105175 [158.140.105.175]) by gda.Cadence.COM (8.8.8/8.8.5) with SMTP id RAA28688; Mon, 10 Aug 1998 17:45:40 -0400 (EDT) Message-Id: <3.0.3.32.19980810174235.0094b5d0@gda.cadence.com> X-Sender: toddw@gda.cadence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Aug 1998 17:42:35 -0400 To: ibis@vhdl.org From: Todd Westerhoff Subject: Beyond simple thresholds - adjusting flight time measurements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" During last Friday's IBIS committee meeting, the issue of correcting/adjusting signal quality simulations based on receiver behavior came up. The issue is that current SI tools typically use simple thresholds (VIL/VIH) when performing flight time measurements, and the more subtle issues of input-receiver hysteresis are left unaddressed. For instance, if the signal at the receiver's input buffer crosses the VIL threshold on a rising edge, goes "flat" for a long period of time, then rises again and crosses VIH, how should the flight time be measured? Similarly, once the signal rises significantly above VIH, receivers may be immune to negative voltage "spikes" that cause the signal at the receiver input to dip below VIH (or, for that matter, VIL), as long as the "spikes" are sufficiently short in duration. As long as the spike is fast enough, it represents insufficient energy to cause the receiver's buffer to change state (this is the classic "area-under-the-curve" problem). For IBIS's purposes, how does one go about quantifying these effects, and go about setting guidelines for simulation? Intel developed a set of guidelines for dealing with these issues when simulating the Pentium Pro(R) processor. The flight time measurement guidelines for the GTL+ bus can be found at: ftp://download.intel.com/design/pro/manuals/24269001.PDF Interested readers can download this Adobe Acrobat document, where GTL+ flight time measurement issues are addressed in Chapter 12. In the past, some customers have automated these types of measurements with custom modeling and scripting. Many of these techniques call for establishing two different sets of logic thresholds, usually referred to as the "logic thresholds" and the "SI thresholds". Depending on the simulator used, multiple "phantom" receivers can be placed in the circuit to measure the signal's behavior at different points and voltage levels. What happens next is also simulator-specific. Depending on the nature and detail of the post-simulation reports produced by the simulator, many of the characteristics of the waveform can be deduced, and the application of signal-quality-driven timing correction criteria can be automated. The advantage of post-processing text reports (instead of waveforms) is that the post-processing task is simplified, therefore faster. The risk is that much of the actual waveform data is lost by reducing the simulation to reports, and not all issues can be detected/corrected. Alternatively, the simulation results can be saved as pure waveforms, which can be post-processed to apply arbitrary correction criteria. This provides improved accuracy, at the expense of greater programming efforts (graphic waveform post-processing) and greater data storage requirements. Hopefully, this will serve as a starting point for discussions. Todd. From owner-ibis Mon Aug 10 16:47:54 1998 Received: from mail-gw3.pacbell.net (mail-gw3.pacbell.net [206.13.28.55]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA29978 for ; Mon, 10 Aug 1998 16:47:53 -0700 (PDT) Received: from pacbell.net (ppp-209-79-182-149.vntrcs.pacbell.net [209.79.182.149]) by mail-gw3.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id QAA28450; Mon, 10 Aug 1998 16:43:46 -0700 (PDT) Message-ID: <35CF84D5.94251FEB@pacbell.net> Date: Mon, 10 Aug 1998 16:40:06 -0700 From: Jon Powell Reply-To: jonp@qdt.com Organization: Viewlogic Consulting Services X-Mailer: Mozilla 4.04 [en]C-PBI-NC404 (Win95; I) MIME-Version: 1.0 To: tomda CC: "'Geoffrey Ellis'" , "fzanella@emc.com" , "ibis@vhdl.org" Subject: Re: non-monotonicity References: <01BDC1E9.E9D60520.tom_dagostino@mentorg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Dagostino wrote: After measuring 1000's of I/O pins I can say with much certainty that not all clamp "diodes" behave monotonically in the "forward bias region". Typical of this behavior are ground protection devices that show abrupt increases in current when swept from a negative voltage to ground. Jon replies: Actually, I think we cover this (at least attemp to) using Transit Time. (we did put that in, didn't we?). jon powell Viewlogic From owner-ibis Tue Aug 11 08:23:11 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA02054 for ; Tue, 11 Aug 1998 08:23:07 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA23477; Tue, 11 Aug 1998 15:18:58 GMT Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA22729; Tue, 11 Aug 1998 08:18:54 -0700 (PDT) Received: from ichips.intel.com by xtg801.pdx.intel.com (8.8.8/WW2.2 (Jones Farm)) id IAA23335; Tue, 11 Aug 1998 08:18:53 -0700 (PDT) Message-Id: <199808111518.IAA23335@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: jonp@qdt.com cc: tomda , "'Geoffrey Ellis'" , "fzanella@emc.com" , "ibis@vhdl.org" Subject: Re: non-monotonicity In-reply-to: Your message of "Mon, 10 Aug 1998 16:40:06 PDT." <35CF84D5.94251FEB@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Aug 1998 08:18:52 -0700 From: Stephen Peters > Tom Dagostino wrote: > > After measuring 1000's of I/O pins I can say with much certainty that > not > all clamp "diodes" behave monotonically in the "forward bias region". > Typical of this behavior are ground protection devices that show abrupt > > increases in current when swept from a negative voltage to ground. > > > Jon replies: > Actually, I think we cover this (at least attemp to) using Transit Time. > > (we did put that in, didn't we?). > > > jon powell > Viewlogic > To which Stephen responded: Yes, transit time is in the spec....although I thought that Tom was referring to I/V sweeps that were slow enough not to show transit time effects. Regards, Stephen Peters Intel Corp. From owner-ibis Tue Aug 11 15:00:53 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA02881 for ; Tue, 11 Aug 1998 15:00:49 -0700 (PDT) Received: from tensor (tensor [209.20.148.75]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id OAA25544 for ; Tue, 11 Aug 1998 14:56:58 -0700 Message-Id: <3.0.5.32.19980811145659.00a10ca0@mail.nwlink.com> X-Sender: mbflora@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 11 Aug 1998 14:56:59 +0000 To: ibis@eda.org From: Matthew Flora Subject: IBIS Open Forum Minutes 7 Aug 1998 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 8/11/98 SUBJECT: 8/7/98 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1998 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Norio Matsui, Raj Raghuram* Cadence Design (& UniCAD) C. Kumar, Don Telian, Patrick Riffault, Craig Lewis, Greg Fitzgerald, Paul Galloway, Patrick Dos Santos, Catherine Weiss, Alain Tribaudot, Geoffrey Ellis*, Todd Westerhoff* Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu, Greg Edlund, Bob Haller Hewlett Packard (EEsof, etc.) Karl Kachigan, Henry Wu, Paul Gregory High Design Technology Razvan Ene HyperLynx Kellee Crisafulli, Matthew Flora* Incases Olaf Rethmeier, Scott Jacobson, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, (& formerly NCR) Will Hobbs, Prakash Radhakrishnan, Mohammed Hawana, Martin Chang, Dave Moxley Mentor Graphics (Zeelan, Bob Ross*, George Opsahl, Mark Noneman, Interconnectix, etc.) Tom Dagostino, Karine Loudet, Jean Oudinot, Manuel De Almeida, Stephane Rousseau, Neven Orhanovic, Mohamed Mahmoud Mitsubishi Hoang Nguyen, Tam Cao Motorola (Ron Werner) National Semiconductor Syed Huq*, Cheng-Yang Kao, John Goldie, Ikchang Song, Milt Schwartz* North East Systems Associates Edward Sayre, Kathy Breda (NESA) NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Symbios Logic Larry Barnes Texas Instruments Thomas Fisher, Harvey Stiegler, Vincent Chang, Jean-Claude Perrin*, Peter Forstner Thomson-CSF Jean-Marc Claveau, Laurent Duzaic, Saverio Lerose, Benoit Meyniel, Jean Lefebvre Viewlogic Jon Powell, Chris Rokusek, Guy de Burgh, Gary Mandel VeriBest Ian Dodd, David Weins, Ian Gabbitas VLSI Technology D.C. Sessions* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1998: Actel Eric Tardif, Emmonvelle Gaudin Aerospatiale Lionel Dreux, Claude Huet Alcatel (Bell, Espace, etc.) John Fitzpatrick, W. Temmerman, Laure Bessettes, Jean-Claude Pourtau, Daniel Peron ALS Design Yves Mouquet Ansoft Eric Bogatin Apple Fred Floresca, Danny Itani Apteq Design Systems Dan FitzPatrick Atmel Ali Baktashian Avanti Nik Bannov CERN Olivier Clere, Jean-Michel Sainson, Rudi Zurbroken Compaq Shariq Rahma Crucial Technology Rathna Reddy EIA Patti Rusher* EMC Fawn Engelmann, Fabrizio Zanella ENST, Paris Jean-Jacques Charlot European CAD Standardization Adam Morawiec Intitiative (ECSI) Fairchild Semiconductor Peter LaFlamme H.A.S Electronics Haruny Said IBM Richard Steinle, Kevin Jackson Intracon Design Ltd. Derek Laidlaw Philips Semiconductor Todd Andersen Scottish Electronics Robert Easson Manufacturing Center (SEMC) Seagate Vanessa Howard SGS-Thomson Philippe Lefevre Siemens Gerald Bannert, Bernhard Unger, Christian Marot, Miguel Hernandez, Gil Russell Sun Microsystems Lam Dong, Kevin Ko Symmetry Andy Hughes Tektronix Nassrin Ghahyasi Ultratest International Chris O'Connor Xilinx Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode August 28, 1998 (916) 356-9200 2-264211 2623135 September 18, 1998 (916) 356-9200 1-249623 2581644 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Todd Westerhoff from Cadence is a Product Marketing Manager for high speed design and is working with IBIS models in the products. Milt Schwartz of National Semiconductor is working with Syed Huq on IBIS model development and validation for new products. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher reported all payments have been received. There are no membership updates. REVIEW OF MINUTES AND AR'S No corrections were noted. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Syed Huq reported some EIA IBIS Home Page updates including a link to IBIS Version 3.1 and roster updates for National Semiconductor and Zuken-Redac. Bob Ross reported that the article "Board-level Signal-integrity Analysis: Sooner is Better" by Jim Lipman, in the July 16, 1998 issue of EDN, pp. 83-94 talks about simulator products and contains plenty of references to IBIS. Also, Bob mentioned the article "Integrated Simulation Technicque Pinpoints Signal Interconnection Problems up Front" by Stan Harris and Ted Lin in the July 1998 issue of Computer Design mentions IBIS. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that IBIS models for Lucent Technologies FPGAs are at: http://www.lucent.com/micro/fpga/ibis.html Also, Actel has buffer models at http://www.actel.com/user/ibis/IBIS.html OPENS FOR NEW ISSUES Bob Ross: BUG30 - [Pin Mapping] Checks are too Simplistic Bob Ross: BUG31 - Error for [Pulldown] Decreasing Current Should be Warning INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Patti Rusher expects action at the IEC meeting in September, 1998 in London. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuit (IMIC) - Raj Raghuram had no further progress report at this time, but possibly will have more information at the next meeting. - IEC 93/67/NP IBIS and EMC Simulation - Jean Claude Perrin reported that a new document has been submitted to the secretary in Paris for distribution and for review at the September IEC meeting in London. - JC-16.2 Subcommittee: Modeling and Test - D.C. Sessions had no further report. Patti Rusher reported the resolution of a JEDEC, Compact Modeling Council and EIA/EIG scope statement issue regarding what appeared to be overlapping scopes. The scope statements of other groups involved software and CAD development. The resolution clarified roles and involved no change in the IBIS Committee positioning under EIA/EIG. - IEEE Standard Component Data Sheet - No report. Bob Ross noted that Stephen Peters is monitoring the activity and Bob Davis of the IEEE committee has been invited to phone in. IBIS (EAST) USERS GROUP MEETINGS Bob Ross stated that the next meeting is scheduled on Thursday, August 20, 1998 at Stratus Computer. IBIS SUMMIT MEETINGS PLANS Bob Ross listed the IBIS Summit Meetings planned through mid-next year: PCB CONFERENCE EAST Thursday, October 15, 1998 Stratus Computer, Marlborough, Massachusetts. Coordinator: Kathy Breda of NESA Initial Details and a Call for Papers will be sent out next week. Focus will be on IBIS Accuracy and Validation, Connectors, and IBIS Tutorial. PCB Conference (Royal Plaza Trade Center) October 12-16, 1998 URL: http://www/pcbdcon.com/pcbeast AR - Bob Ross and Kathy Breda send out initial details of meeting. JEDEC JC16.2 Joint Meeting with IBIS (and JC42 Meeting December 7-9, 1998) IBIS SUMMIT: Wednesday, December 9, 1998 Kona Kai Continental Hotel San Diego, CA URL for JC42 Schedule: http://www.jedec.org DESIGNCON99 (February 1-4, 1999) IBIS SUMMIT: Monday, February 1, 1999 Westin Hotel Santa Clara, CA DesignCon Location: Santa Clara Convention Center, Santa Clara, CA DesignCon URL: http://designcon.com DATE99 - (Design Automation and Test in Europe, March 9-12. 1999) IBIS SUMMIT: Friday, March 12, 1999 Astron Hotel Munich, Germany PCB Symposium: Thursday, March 11, 1999 at DATE99 Location DATE99 Site: International Congress Center, Munich, Germany DATE99 URL: http://www.date-conference.com DAC99 (Design Automation Conference June 21-25, 1999) IBIS SUMMIT: Thursday, June 24, 1999 Location to be determined New Orleans, Louisiana DAC99 Location" Ernest N. Morial Convention Center, New Orleans, LA. DAC URL: http://www.dac.com Note, D.C. Sessions stated that Monday may be a better day to hold the IBIS meeting and also visit the show. Bob Ross stated that Monday may also be better for him to avoid conflict with some personal plans. EDITING COMMITTEE No Report. The editing committee BNF AR remains. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 (an IBIS Version 3.0 ratification AR). IBISCHK2+ (VER 2.1.16) PROGRESS Matthew Flora reported that he and Chris Rokusek sent the ibischk2+ source code to Atul Agarwal. However it is not clear who is doing the ibischk2+ upgrade to Version 2.1.16 with the fixes that have been implemented in ibischk3, Version 3.1.0. Matthew thought that he and Chris would make the changes. The AR remains unchanged. AR - Matthew Flora, Chris Rokusek, and Bob Ross work together to (1) add all of the changes done in the ibischk3 code relative to bug fixes to the ibischk2+ source code, (2) Chris Rokusek generate executables, (3) and Bob Ross upload the executables on eda.org. Also, Syed Huq will generate a Linux executable. Syed Huq asked if the ibischk2 executables would be obsoleted with the release of ibischk3. Bob Ross responded that the executables would still be made available. Matthew Flora asked if the ibischk2+ version 2.1.16 release is necessary since the fixes for ibischk2+ are in the ibischk3 release. Bob responded that we want to make a final release ibischk2+ to include the 10 or so bug fixes. We are still supporting IBIS Version 2.1 (still the official ANSI/EIA-656 version) and are still offering the source code license to its parser. VERSION 3.1/3.2 PARSER DEVELOPMENT Patti Rusher reported that all of the parser payments have been received. Bob Ross reported that the wire transfer of payment has been completed to Atul Agarwal. Bob also reported that Atul will provide latest Version 3.1.0 file this week with integrated ibischk2+ code received from Matthew Flora and Chris Rokusek. In response to a question from Syed Huq, Bob noted that the group will produce and upload a number of executables for free distribution on eda.org. Atul is looking at the BIRDs for ibischk3 Version 3.2.0 and will send a list of questions for clarification to Bob Ross. COOKBOOK No report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora reported no activity since last meeting. He still plans to send out a note to the reflector. His contact address is repeated below: Matthew Flora, HyperLynx mbflora@hyperlynx.com AR - Matthew Flora issue to the IBIS reflector a short writeup on the IBIS IBIS Model Review committee. BUG29 - \n, \r. \r\n Line Terminators Need to be Handled Geoffrey Ellis mentioned that IBIS files may exist with the following line termination formats: LF, CR/LF and CR. Bob Ross asked and Geoffrey responded that LF was typical in UNIX data and CR/LF in DOS data. CR has also appeared in data, but the group did not know where those files originated. Geoffrey noted that the CR termination files can be imported into Word 7.0 and then saved as .txt files to convert the CR to CR/LF. Bob noted Chris Rokusek has been in contact with the vendor providing the data, and the vendor plans to change the file. Bob was concerned that the if the ibischk3 parser were upgraded, it might report as good some IBIS files that some commercial products may not be able to read (without the commercial products being modified). So while fixing BUG29 may be a good idea, it may have practical implications. Geoffrey noted that the IBIS document does not specify the appropriate terminations. So a BIRD is needed to clarify what line are acceptable in IBIS files. Bob classified BUG29 as an Enhancement, Low priority, and Open. The action, however, is for Geoffrey to introduce a BIRD to explicitly state the acceptable IBIS file terminations. Bob noted that a statement could be proposed in Section 3, General Syntax Rules and Guidelines as item 14. In issuing the BIRD, Geoffrey could state either the two or three methods above, but the IBIS Forum would decide what to accept. AR - Geoffrey Ellis create a BIRD regarding the acceptable line terminations in IBIS files. [Done - issued as BIRD53] No action will be taken on BUG29 at this time. How BUG29 is handled will depend on how the proposed BIRD is resolved. BUG30 - [Pin Mapping] Checks are too Simplistic Bob Ross introduced BUG30 that was generated by Atul Agarwal. Bob indicated that the ibischk2+ and ibischk3 parsers do not test for some simple bus name limitations under [Pin Mapping] that exist in the IBIS document. Atul listed the proposed checks to see that the [Pin Mapping] tables contained meaningful entries (e.g., the power bus connections to a pin are also attached to the power pin.) Bob classified this as an Enhancement, Medium priority, and Open. Bob felt that Atul could implement the fix, but on a lower priority basis than for the Version 3.2 extensions on the IBIS parser. (Bob suspects that the fix will not take a long time.) BUG31 - Error for [Pulldown] Decreasing Current Should be Warning Bob Ross introduced BUG31 that was issued by John Keifer (of Intel). Bob summarized the problem that while BUG31 referred to a specific device, the general problem is that some devices now have clamps for I/O and 3-state devices that appear only in the Non-Driving mode. The recommended way for IBIS Version 2.1 level files to deal with this situation is to put in a compensating current in the [Pulldown] and [Pullup] tables so that the summation of the clamping currents and these tables will produce a summed table without the clamping effects. However, these compensating currents creates non-monotonic tables and also may cause the endpoints of the table to fail the ibischk2+ polarity test. BUG31 proposes that the reported Error be changed to a Warning. The IBIS model should function in most simulators since the summation of currents tables is still monotonic. Matthew Flora questioned whether the "monotonicity" test in ibischk2+ tests tables individually, point-by-point, or just looks at the endpoints as Bob stated. Bob mentioned that this needs to be checked. (The endpoint test exists and reports an ERROR such as [Pulldown] has Decreasing Current. A point-by-point monotonicity test also exists which reports a WARNING for any non-monotonic data in any table. BUG31 is concerned with the endpoint test.) After studying the example file in BUG31, Bob was not sure that the data was not actually bad. So the particular BUG31 problem needs to be researched further. Bob noted that the IBIS Specification itself prescribes reporting an ERROR if the endpoint test fails. Bob classified BUG31 as an Enhancement, Medium, and Open. However, it needs further research before we precede on it. The proposed resolution may require issuing a BIRD to change the specification. So the action is to research BUG31 further before deciding whether to change the ibischk3 parser. INPUT ENHANCEMENTS As a continuation of the discussion at the last meeting, D.C. Sessions briefly reintroduced the need of more Input information detail as the semiconductor technologies are advancing. Plenty of detail exists for output buffer specifications. Details of input specifications are needed such as thresholds as a percentage of Vcc, how to deal with flat spots at the input, etc. D.C. mentioned equations, as a possibility. Todd Westerhoff shared some of his experiences on these issues, especially with Pentium Pro input characterization. Stephen Peters gave some background that some of the input rules were derived from a large number of Spice simulation results. The rules do relate to energy limits under the curve. D.C. discussed ground bounce SSO interactions as an emerging issue. Bob Ross noted that how this is handled may take time to resolve and is a candidate for IBIS Version 4.0 extensions - as discussed at the IBIS Summit Meeting on June 18, 1998. Todd's discussion involved some specification extensions that do not include SSO interactions. Todd plans to comment on the issue on the IBIS reflector and search for possible reference documents on the internet. Much of the basis for a possible extension is already contained in published data books. Bob noted that while the functionality of IBIS Version 3.2 has been decided, a few additions to the [Model Spec] keyword could be added if they are done quickly. NEXT MEETING: The next meeting will be on Friday, August 28, 1998 from 8:00 AM to 10:00 AM. (BIRD53 is scheduled for a vote.) ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentorg.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Wed Aug 12 10:04:39 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA04995 for ; Wed, 12 Aug 1998 10:04:38 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA10559; Wed, 12 Aug 1998 10:00:15 -0700 (PDT) Received: from kappa2.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA24735; Wed, 12 Aug 1998 10:00:13 -0700 (PDT) Received: by localhost with Microsoft MAPI; Wed, 12 Aug 1998 09:56:08 -0700 Message-ID: <01BDC5D7.6DB10480.tom_dagostino@mentorg.com> From: tomda To: "'jonp@qdt.com'" , tomda Cc: "'Geoffrey Ellis'" , "fzanella@emc.com" , "ibis@vhdl.org" Subject: RE: non-monotonicity Date: Wed, 12 Aug 1998 09:56:06 -0700 Organization: Mentor Graphics X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe transient time covers AC characteristic of the protection device. The phenomenon I have seen is a DC characteristic, those that one would typically see on a curve tracer. Tom Dagostino -----Original Message----- From: Jon Powell [SMTP:jonp@pacbell.net] Sent: Monday, August 10, 1998 4:40 PM To: tomda Cc: 'Geoffrey Ellis'; fzanella@emc.com; ibis@vhdl.org Subject: Re: non-monotonicity Tom Dagostino wrote: After measuring 1000's of I/O pins I can say with much certainty that not all clamp "diodes" behave monotonically in the "forward bias region". Typical of this behavior are ground protection devices that show abrupt increases in current when swept from a negative voltage to ground. Jon replies: Actually, I think we cover this (at least attemp to) using Transit Time. (we did put that in, didn't we?). jon powell Viewlogic From owner-ibis Thu Aug 13 08:08:16 1998 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA07744 for ; Thu, 13 Aug 1998 08:08:15 -0700 (PDT) Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id PAA10411; Thu, 13 Aug 1998 15:03:47 GMT Message-Id: <199808131503.PAA10411@thalia.fm.intel.com> Received: by FMSMSX18 with Internet Mail Service (5.5.1960.3) id ; Thu, 13 Aug 1998 08:03:41 -0700 From: "Muranyi, Arpad" To: "\"'jonp@qdt.com'\" " , "\"tomda\" " Cc: "\"'Geoffrey Ellis'\" " , "\"fzanella@emc.com\" " , "\"ibis@vhdl.org\" " Subject: RE: non-monotonicity Date: Thu, 13 Aug 1998 08:02:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain I have also seen such I-V curves, but I would question whether these are "static" behavior. Such curves happen mostly with bipolar devices and with those the output current may have an effect on the internal currents of the device causing it to switch or do similar unpredictable things. Also, in some cases the device maybe in the breakdown mode at higher voltages/currents. All I am trying to say is that these may not necessarily be DC I-V curves of a static circuit, or circuit element even though one may think so. In order to decide, one would need to know more about the part in question and its I-V curve. Arpad Muranyi Intel Corporation ============================================================================ == I believe transient time covers AC characteristic of the protection device. The phenomenon I have seen is a DC characteristic, those that one would typically see on a curve tracer. Tom Dagostino -----Original Message----- From: Jon Powell [SMTP:jonp@pacbell.net] Sent: Monday, August 10, 1998 4:40 PM To: tomda Cc: 'Geoffrey Ellis'; fzanella@emc.com; ibis@vhdl.org Subject: Re: non-monotonicity Tom Dagostino wrote: After measuring 1000's of I/O pins I can say with much certainty that not all clamp "diodes" behave monotonically in the "forward bias region". Typical of this behavior are ground protection devices that show abrupt increases in current when swept from a negative voltage to ground. Jon replies: Actually, I think we cover this (at least attemp to) using Transit Time. (we did put that in, didn't we?). jon powell Viewlogic From owner-ibis Thu Aug 13 09:23:53 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA07954 for ; Thu, 13 Aug 1998 09:23:52 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id JAA28861; Thu, 13 Aug 1998 09:19:29 -0700 (PDT) Received: from kappa2.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA28612; Thu, 13 Aug 1998 09:19:27 -0700 (PDT) Received: by localhost with Microsoft MAPI; Thu, 13 Aug 1998 09:15:18 -0700 Message-ID: <01BDC69A.E39FB600.tom_dagostino@mentorg.com> From: tomda To: "'Muranyi, Arpad'" , "\"'jonp@qdt.com'\" " , "\"tomda\" " Cc: "\"'Geoffrey Ellis'\" " , "\"fzanella@emc.com\" " , "\"ibis@vhdl.org\" " Subject: RE: non-monotonicity Date: Thu, 13 Aug 1998 09:15:16 -0700 Organization: Mentor Graphics X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IV waveforms that I am talking about have typically shown this behavior between -0.8 and -0.4V when the output is in the low state. I don't recall off the top of my head which devices showed this characteristic but they included both CMOS and bipolar devices. Tom Dagostino -----Original Message----- From: Muranyi, Arpad [SMTP:arpad.muranyi@intel.com] Sent: Thursday, August 13, 1998 8:02 AM To: "'jonp@qdt.com'" ; "tomda" Cc: "'Geoffrey Ellis'" ; "fzanella@emc.com" ; "ibis@vhdl.org" Subject: RE: non-monotonicity I have also seen such I-V curves, but I would question whether these are "static" behavior. Such curves happen mostly with bipolar devices and with those the output current may have an effect on the internal currents of the device causing it to switch or do similar unpredictable things. Also, in some cases the device maybe in the breakdown mode at higher voltages/currents. All I am trying to say is that these may not necessarily be DC I-V curves of a static circuit, or circuit element even though one may think so. In order to decide, one would need to know more about the part in question and its I-V curve. Arpad Muranyi Intel Corporation ======================================================================== ==== == I believe transient time covers AC characteristic of the protection device. The phenomenon I have seen is a DC characteristic, those that one would typically see on a curve tracer. Tom Dagostino -----Original Message----- From: Jon Powell [SMTP:jonp@pacbell.net] Sent: Monday, August 10, 1998 4:40 PM To: tomda Cc: 'Geoffrey Ellis'; fzanella@emc.com; ibis@vhdl.org Subject: Re: non-monotonicity Tom Dagostino wrote: After measuring 1000's of I/O pins I can say with much certainty that not all clamp "diodes" behave monotonically in the "forward bias region". Typical of this behavior are ground protection devices that show abrupt increases in current when swept from a negative voltage to ground. Jon replies: Actually, I think we cover this (at least attemp to) using Transit Time. (we did put that in, didn't we?). jon powell Viewlogic From owner-ibis Thu Aug 13 12:02:47 1998 Received: from wile.nesa.com ([204.240.29.30]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA08264; Thu, 13 Aug 1998 12:02:44 -0700 (PDT) Received: (from mail@localhost) by wile.nesa.com (8.8.5/8.8.5) id OAA14703; Thu, 13 Aug 1998 14:34:01 -0400 Received: from porky.nesa.com(204.240.29.45) by wile.nesa.com via smap (V1.3) id sma014698; Thu Aug 13 14:33:31 1998 Message-Id: <3.0.3.32.19980813143321.006ad9d4@mail.nesa.com> X-Sender: breda@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 13 Aug 1998 14:33:21 -0400 To: ibis-users@eda.org, ibis@eda.org From: Kathy Breda Subject: IBIS SUMMIT MEETING - 10/15/98 - call for participation & presentations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS & SPONSORSHIP!!!! ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Thursday, October 15, 1998 Location: Boxboro Holiday Inn. One Adams Place, Boxboro, MA Tel: (978) 263-8701 Fax: (978) 263-0518 Content: IBIS Tutorial Review, Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), IBIS Users Group, we are looking for other sponsors! PCB Conference: October 12-16, 1998 East Royal Plaza Trade Center Marlborough, Massachusetts See www.pcbdcon.com/pcbeast for more information. BACKGROUND The IBIS Users Group (IBIS East) has been formed under the leadership of Dr. Edward Sayre from North East Systems Associates (NESA) and has been meeting for a year to consider and forward IBIS model user concerns. As a result of regular East coast meetings, the group has developed an IBIS tutorial, has undertaken an IBIS model accuracy and validation project, and is pursuing formatting connector models. These topics and others are expected to be discussed at the IBIS Summit Meeting. This meeting will be conducted as a formal IBIS Summit meeting. Presentation are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Kathy Breda (breda@nesa.com) CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by October 9, 1998. Otherwise the presentor will be expected to provide 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Kathy Breda (breda@nesa.com) AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided). This will be developed as presentation proposals are received. A two-hour IBIS tutorial is planned. LIST OF NEARBY HOTELS Boxboro Holiday Inn. One Adams Place Boxboro, MA Tel: (978) 263-8701 Fax: (978) 263-0518 Royal Plaza Hotel (PCB Conference East Rates guareenteed until September 12, 1998) 181 Boston Post road West Marlborough, MA 01752 Tel: (508) 460-0700 Marlboro Holiday Inn 265 Lakeside Ave. Marlboro, MA Tel: (508)481-3000 Radisson Inn 75 Felton St. Marlboro, MA Tel: (508) 480-0015 Embassy Suites Hotels 123 Boston Post Rd. West Marlboro, MA (508) 485-5900 Amerscot House 61 West Acton Road Stow, MA 01775 email: doreen@amerscot.com, web site http://www.amerscot.com Tel: (508)897-0666, FAX (508)897-6914 Westford Regency Inn 219 Littleton Rd. (exit 32 off I-495) Westford, MA Tel: (978) 692-8200 Directions to IBIS Summit at Boxboro Holiday Inn: ================================================= Boxboro Holiday Inn. One Adams Place, Boxboro, MA Tel: (978) 263-8701 Fax: (978) 263-0518 >From the North: (NH, ME, Northern MA) Route 3 south to route 495 south Route 93 south to route 495 south Route 95 south to route 495 south Exit #28 to Route 111, (Boxboro/Harvard). Turn right off of the ramp, travel over the overpass, and take the first road on the right, (Adams Place) follow entrance signs. ---------------- >From the South: (Cape Cod, South Shore, Rhode Island) Route 3 north to route 95 south to route 495 north Route 295 north to Route 495 north Exit # 28 to Route 111, (Boxboro/Harvard). Turn left off of the ramp, Take the first road on the right, (Adams Place) follow entrance signs. --------------- >From the East: (Boston, North Shore, Waltham, Norwood) Route 128 soute to route 2 west or Route 128 north to route 2 west to Route 111 West Follow route 111 approximately 8 miles. Adams Place will be on the left before crossing route 495. Alternative is to follow route 2 west to 495 south Exit #28 to Route 111, (Boxboro/Harvard). Turn right off of the ramp, travel over the overpass, and take the first road on the right, (Adams Place) follow entrance signs. Route 90 (Mass Pike) west to Route 495 north Exit # 28 to Route 111, (Boxboro/Harvard). Turn left off of the ramp, Take the first road on the right, (Adams Place) follow entrance signs. ---------------- >From the West: (Worcester, Fitchburg & CT) Route 290 East to Route 495 north Exit # 28 to Route 111, (Boxboro/Harvard). Turn left off of the ramp, Take the first road on the right, (Adams Place) follow entrance signs. (CT) Route 84 north to Route 90 (Mass Pike) East to Route 495 north. Exit # 28 to Route 111, (Boxboro/Harvard). Turn left off of the ramp, Take the first road on the right, (Adams Place) follow entrance signs. Route 2 east to route 495 south. Exit #28 to Route 111, (Boxboro/Harvard). Turn right off of the ramp, travel over the overpass, and take the first road on the right, (Adams Place) follow entrance signs. From owner-ibis Fri Aug 21 13:16:34 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA29948 for ; Fri, 21 Aug 1998 13:16:33 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id NAA03079; Fri, 21 Aug 1998 13:12:07 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id NAA09096; Fri, 21 Aug 1998 13:12:05 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA04291; Fri, 21 Aug 98 13:12:05 PDT Date: Fri, 21 Aug 98 13:12:05 PDT Message-Id: <9808212012.AA04291@bob> To: ibis@eda.org Subject: IBIS MEETING AGENDA 8/28/98 IBIS Open Forum Meeting Agenda for 8/28/98 Bridge Number Reservation # Passcode (916) 356-9200 2-264211 2623135 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Rusher - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions - IEEE Standard Component Data Sheet Davis/Peters/Ross IBIS (East) Users Group Meetings Edlund IBISEAST SUMMIT Ross/Breda IBISCHK2+ (Ver 2.117) PROGRESS Flora/Rokusek Version 3.1/3.2 Parser Development Ross - Executables - Version 3.2 Document - Version 3.2 Parser Development Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:00 Technical Discussion BIRD53 - IBIS File Character Set (Vote) Ellis BUG29 - n\, \r, \r\n Line Terminators Need to be Ellis Handled BUG31 - Error for [Pulldown Decreasing Current Should Ross be Warning (more discussion) Input Issues Sessions/Westerhoff New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Tue Aug 25 06:53:19 1998 Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA09979 for ; Tue, 25 Aug 1998 06:53:18 -0700 (PDT) Received: from moody.mchh.siemens.de (moody-i.mchh.siemens.de [194.138.158.26]) by gorilla.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id PAA12305 for ; Tue, 25 Aug 1998 15:49:29 +0200 (MET DST) Received: from vs01.oen.siemens.de (root@vs01.mchh3.oen.siemens.de [132.24.1.144]) by moody.mchh.siemens.de (8.8.7/8.8.7) with SMTP id PAA07213 for ; Tue, 25 Aug 1998 15:53:27 +0200 (MET DST) Received: from oen.siemens.de by vs01.oen.siemens.de (SMI-8.6/SMI-SVR4) id PAA14315; Tue, 25 Aug 1998 15:49:29 +0200 Sender: sw044493@oen.siemens.de Message-ID: <35E2C09B.4CD52198@oen.siemens.de> Date: Tue, 25 Aug 1998 15:48:12 +0200 From: Herr Walter Schneider X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Info - IBIS Content-Type: multipart/alternative; boundary="------------C4CAB0D1BEEE046EF370A3A2" --------------C4CAB0D1BEEE046EF370A3A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello! My name is Walter Schneider. I am a electrical engineer and I am very interested in getting information about IBIS-modelling. Please tell me such information. Thank you very much! -- **************************************************** ** Walter Schneider ** ** Siemens OEN ET D2 ** ** Phone : +49 (0)89 / 722-44493 ** ** email : Walter-Karl.Schneider@oen.siemens.de ** **************************************************** --------------C4CAB0D1BEEE046EF370A3A2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello!

My name is Walter Schneider. I am a electrical engineer and I am very interested
in getting information about IBIS-modelling.
Please tell me such information.

Thank you very much! 

-- 
****************************************************
**  Walter Schneider                              **
**  Siemens OEN ET D2                             **
**  Phone :  +49 (0)89 / 722-44493                **
**  email : Walter-Karl.Schneider@oen.siemens.de  **
****************************************************
  --------------C4CAB0D1BEEE046EF370A3A2-- From owner-ibis Wed Aug 26 11:57:02 1998 Received: from spsem02.sps.mot.com (spsem02.sps.mot.com [192.70.231.5]) by server.eda.org (8.8.5/8.8.3) with SMTP id LAA14549 for ; Wed, 26 Aug 1998 11:57:01 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA01839 for ibis@eda.org; Wed, 26 Aug 98 11:53:00 MST Received: from msgphx1.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA17837 for ibis@eda.org; Wed, 26 Aug 98 11:52:57 MST Received: from email.sps.mot.com ([222.50.10.30]) by msgphx1.sps.mot.com (Netscape Messaging Server 3.01) with ESMTP id AAA7156 for ; Wed, 26 Aug 1998 11:52:43 -0700 Message-Id: <35E4597E.B8968DE@email.sps.mot.com> Date: Wed, 26 Aug 1998 11:54:12 -0700 From: "Paul Shockman" Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.05C-MOTSPS405U (Macintosh; I; PPC) Mime-Version: 1.0 To: ibis@eda.org Subject: subscribe Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 From owner-ibis Fri Aug 28 18:02:39 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA21057 for ; Fri, 28 Aug 1998 18:02:39 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA21806; Fri, 28 Aug 1998 17:58:10 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id RAA16630; Fri, 28 Aug 1998 17:58:08 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA17840; Fri, 28 Aug 98 17:58:08 PDT Date: Fri, 28 Aug 98 17:58:08 PDT Message-Id: <9808290058.AA17840@bob> To: ibis@eda.org Subject: NEW IBISCHK EXECUTABLES To All: New ibischk2, Version 2.1.17 and ibischk3.1.0 executables have been uploaded to eda.org/pub/ibis under the following directories: ibschk2+ ibischk3 Some older versions have been retained in "old" subdirectories in case you need some executables not covered by the listed platforms. Companies which have purchased the ibischk2 source code license can contact me if they need the latest source code. The ibischk3 source code has been distributed to the companies who have purchased the license. Bob Ross Interconnectix/Mentor Graphics