From owner-ibis Sun Jul 1 14:55:55 2001 Received: from amethyst.nstc.com (amethyst.nstc.com [207.166.203.193]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f61Lth7n003365 for ; Sun, 1 Jul 2001 14:55:52 -0700 (PDT) Received: from heorot.lumbercartel.com (03-048.076.popsite.net [64.24.211.48]) (authenticated) by amethyst.nstc.com (8.11.0/8.11.0) with ESMTP id f61Ltbb06862 for ; Sun, 1 Jul 2001 17:55:37 -0400 Received: from frankenstein.lumbercartel.com (frankenstein.lumbercartel.com [192.168.6.2]) by heorot.lumbercartel.com (8.11.3/8.11.3) with SMTP id f61Lv1407445 for ; Sun, 1 Jul 2001 14:57:01 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "D. C. Sessions" Organization: TINLC To: "Ibis@Eda. Org" Subject: Re: Junk mail? Date: Sun, 1 Jul 2001 12:07:39 -0700 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01070112073900.09116@frankenstein.lumbercartel.com> Content-Transfer-Encoding: 8bit On Thursday 21 June 2001 10:48, Chris Rokusek wrote: > I've just recently received a few spam messages at my work address which to > my knowledge is only known by the IBIS and SI-LIST reflectors. I am > concerned over the list's security. Can 3rd parties harvest our email > addresses or post messages to the list without being members? Since the list archives are on the WWW, webcrawler bots will pick up the messages there. Unless we want to lock down access to the archives (NOT a good idea, IMHO) we have the choice between editing them (also NAGI, IMHO) or living with the problem. Then again, I don't munge. I LART. (Sorry to be so slow replying; got back from Tokyo to find a major hardware failure.) -- | I'm old enough that I don't have to pretend to be grown up.| +----------- D. C. Sessions ----------+ From owner-ibis Mon Jul 2 12:06:09 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f62J677n024667 for ; Mon, 2 Jul 2001 12:06:09 -0700 (PDT) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id PAA25308 for ; Mon, 2 Jul 2001 15:06:02 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id PAA28258 for ; Mon, 2 Jul 2001 15:06:00 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.innoveda.com [139.181.194.170]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id MAA28425 for ; Mon, 2 Jul 2001 12:05:48 -0700 (PDT) From: "Chris Rokusek" To: "Ibis@Eda. Org" Subject: RE: Junk mail? Date: Mon, 2 Jul 2001 12:08:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <01070112073900.09116@frankenstein.lumbercartel.com> D.C., You bring up an interesting point. If the names are being stolen from the web archives then why don't we munge all email addresses during the append to web page? If the list archives are being generated on a UNIX system, then we're talking about a one-line "sed" command here to replace addresses of the glob form "*@*." with "*@NoSpam.*" Would this work? Does anyone object? Is it feasible to implement? If yes, I can provide a robust, tested sed command. Chris > -----Original Message----- > From: D. C. Sessions [mailto:ibis@lumbercartel.com] > Sent: Sunday, July 01, 2001 12:08 PM > To: Ibis@Eda. Org > Subject: Re: Junk mail? > > > On Thursday 21 June 2001 10:48, Chris Rokusek wrote: > > > I've just recently received a few spam messages at my work > address which to > > my knowledge is only known by the IBIS and SI-LIST reflectors. I am > > concerned over the list's security. Can 3rd parties harvest our email > > addresses or post messages to the list without being members? > > Since the list archives are on the WWW, webcrawler bots will > pick up the messages there. Unless we want to lock down access > to the archives (NOT a good idea, IMHO) we have the choice > between editing them (also NAGI, IMHO) or living with the problem. > > Then again, I don't munge. I LART. > > (Sorry to be so slow replying; got back from Tokyo to find a > major hardware failure.) > > -- > | I'm old enough that I don't have to pretend to be grown up.| > +----------- D. C. Sessions ----------+ > > From owner-ibis Sun Jul 8 21:39:56 2001 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f694ds7n014598 for ; Sun, 8 Jul 2001 21:39:55 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id VAA18605 for ; Sun, 8 Jul 2001 21:39:47 -0700 (MST)] Received: [from msgtel1.sps.mot.com (msgtel1.sps.mot.com [216.2.95.1]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id VAA18840 for ; Sun, 8 Jul 2001 21:39:46 -0700 (MST)] Received: from email.sps.mot.com ([223.143.95.68]) by msgtel1.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA3B57; Mon, 9 Jul 2001 07:42:50 +0300 Sender: yokede@pobox2.mot.com Message-ID: <3B49358F.44114DCD@email.sps.mot.com> Date: Mon, 09 Jul 2001 07:39:43 +0300 From: "Yoked Erlich (r58559)" X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, "Sofer Sergey (r53493)" Subject: Ibis standard for feedback Content-Type: multipart/mixed; boundary="------------2E03E48FE4C20E2BB202E2E8" This is a multi-part message in MIME format. --------------2E03E48FE4C20E2BB202E2E8 Content-Type: multipart/alternative; boundary="------------5DA3C2352DAD8DEBDE7123FB" --------------5DA3C2352DAD8DEBDE7123FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , As I've seen in 'IBIS forum I/O buffer modeling cookbook - revision 2.0x' paper there are four main different I/O buffers (3-state,input buffer,output buffer,open drain buffer), Is there any specification for buffer that using feedback method in order to reduce noises? Thanks Yoked. -- _____________________________________ E-mail: yokede@msil.sps.mot.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL --------------5DA3C2352DAD8DEBDE7123FB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,

As I've seen in 'IBIS forum I/O buffer modeling cookbook - revision 2.0x'  paper
there are four main different I/O buffers (3-state,input buffer,output buffer,open drain buffer),
Is there any specification for buffer that using feedback method in order to reduce noises?

Thanks

Yoked. 

-- 

_____________________________________
E-mail:       yokede@msil.sps.mot.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP                 
MOTOROLA     SEMICONDUCTOR     ISRAEL
  --------------5DA3C2352DAD8DEBDE7123FB-- --------------2E03E48FE4C20E2BB202E2E8 Content-Type: text/x-vcard; charset=us-ascii; name="r58559.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for yoked erlich Content-Disposition: attachment; filename="r58559.vcf" begin:vcard n:Erlich;Yoked tel;cell:051-957314 tel;fax:09-9522888 tel;home:09-8985166 tel;work:09-9522482 x-mozilla-html:FALSE org:Motorola Semiconductor L.T.D;IO - WIRELESS adr:;;Hadolev 20a;Zuran;;;ISRAEL version:2.1 email;internet:yokede@msil.sps.mot.com x-mozilla-cpt:;-32248 fn:Yoked Erlich end:vcard --------------2E03E48FE4C20E2BB202E2E8-- From owner-ibis Mon Jul 9 05:24:10 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f69CO87n015638 for ; Mon, 9 Jul 2001 05:24:10 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA26588; Mon, 9 Jul 2001 05:23:59 -0700 (PDT) Received: from mentor.com (wv35extra11.soho-wv.mentorg.com [172.16.35.11]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NW3WV8JT; Mon, 9 Jul 2001 05:25:13 -0700 Message-ID: <3B49A24C.C7E59C9A@mentor.com> Date: Mon, 09 Jul 2001 05:23:40 -0700 From: Bob Ross Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Yoked Erlich (r58559)" CC: ibis@eda.org, "Sofer Sergey (r53493)" , "Ross, Bob" Subject: Re: Ibis standard for feedback References: <3B49358F.44114DCD@email.sps.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Yoked: I am not familiar with the specific technical details regarding the feedback method. However, I believe IBIS would not handle it now, but the future IBIS-X macro language would be able to describe such a buffer. Bob Ross Mentor Graphics > "Yoked Erlich (r58559)" wrote: > > Hi , > > As I've seen in 'IBIS forum I/O buffer modeling cookbook - revision 2.0x' > paper > there are four main different I/O buffers (3-state,input buffer,output > buffer,open drain buffer), > Is there any specification for buffer that using feedback method in order to > reduce noises? > > Thanks > > Yoked. > > -- > > _____________________________________ > E-mail: yokede@msil.sps.mot.com > Tel: 972-9-9522482 Fax: 972-9-9522888 > WIRELESS CIRCUIT - IO GROUP > MOTOROLA SEMICONDUCTOR ISRAEL > > From owner-ibis Mon Jul 9 05:47:07 2001 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f69Cl57n015736 for ; Mon, 9 Jul 2001 05:47:06 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA18459 for ; Mon, 9 Jul 2001 05:46:57 -0700 (MST)] Received: [from msgtel1.sps.mot.com (msgtel1.sps.mot.com [216.2.95.1]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA17886 for ; Mon, 9 Jul 2001 05:46:56 -0700 (MST)] Received: from motorola.com ([223.141.95.28]) by msgtel1.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA5FC2; Mon, 9 Jul 2001 15:49:59 +0300 Sender: sergeys@pobox4.mot.com Message-ID: <3B49A7BC.661DC187@motorola.com> Date: Mon, 09 Jul 2001 15:46:52 +0300 From: Sergey Sofer Organization: Motorola Semiconductor Israel Ltd. X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Ross CC: "Yoked Erlich (r58559)" , ibis@eda.org, "Sofer Sergey (r53493)" Subject: Re: Ibis standard for feedback References: <3B49358F.44114DCD@email.sps.mot.com> <3B49A24C.C7E59C9A@mentor.com> Content-Type: text/html; charset=koi8-r Content-Transfer-Encoding: 7bit Hello Bob,

The method specified by Yoked is a kind of model selecting
method, where the control for driving strong or less strong,
comes from pad itself as specific voltage level.

We saw that there is an option to take care on IO buffer with
different driving models connected in parallel, with "model
selector" in the last version of IBIS (3.2).

The Yoked's question may be asked in other words:
Is there any possibility to select models by pad's voltage level?

Regards,
Sergey.
 

Bob Ross wrote:

Hello Yoked:

I am not familiar with the specific technical
details regarding the feedback method.  However,
I believe IBIS would not handle it now, but the
future IBIS-X macro language would be able to
describe such a buffer.

Bob Ross
Mentor Graphics

> "Yoked Erlich (r58559)" wrote:
>
> Hi ,
>
> As I've seen in 'IBIS forum I/O buffer modeling cookbook - revision 2.0x'
> paper
> there are four main different I/O buffers (3-state,input buffer,output
> buffer,open drain buffer),
> Is there any specification for buffer that using feedback method in order to
> reduce noises?
>
> Thanks
>
> Yoked.
>
> --
>
> _____________________________________
> E-mail:       yokede@msil.sps.mot.com
> Tel: 972-9-9522482 Fax: 972-9-9522888
> WIRELESS     CIRCUIT  - IO      GROUP
> MOTOROLA     SEMICONDUCTOR     ISRAEL
>
>

-- 
------------------------------------------
mailto:Sergey.Sofer@motorola.com
Tel: +972-9-9522406   Fax: +972-9-9522888
Motorola Semiconductor Israel Ltd.
  From owner-ibis Mon Jul 9 06:54:45 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f69Dsh7n015931 for ; Mon, 9 Jul 2001 06:54:45 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA10160; Mon, 9 Jul 2001 06:53:43 -0700 (PDT) Received: from mentor.com (wv35extra11.soho-wv.mentorg.com [172.16.35.11]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NW3WV8LN; Mon, 9 Jul 2001 06:54:56 -0700 Message-ID: <3B49B753.9D0C511E@mentor.com> Date: Mon, 09 Jul 2001 06:53:23 -0700 From: Bob Ross Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sergey Sofer CC: Bob Ross , "Yoked Erlich (r58559)" , ibis@eda.org, "Sofer Sergey (r53493)" Subject: Re: Ibis standard for feedback References: <3B49A7BC.661DC187@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Sergey: Based on your description, I believe your question may relate to some dynamic impedance control buffers. IBIS Version 3.2 partially supports feedback through the "Bus_hold" submodel where another buffer can be switched in parallel based on a trigger voltage to increase the overall buffer strength. Because of some polarity considerations, this method may need to be completed for "Reduced_strength" operation based on a trigger voltage. I plan to author a BIRD for this improvement for a pending IBIS Version 4.0. As previously stated, I also believe that such operation could be described in the pending IBIS-X macro language. Bob Mentor Graphics > Sergey Sofer wrote: > > Hello Bob, > > The method specified by Yoked is a kind of model selecting > method, where the control for driving strong or less strong, > comes from pad itself as specific voltage level. > > We saw that there is an option to take care on IO buffer with > different driving models connected in parallel, with "model > selector" in the last version of IBIS (3.2). > > The Yoked's question may be asked in other words: > Is there any possibility to select models by pad's voltage level? > > Regards, > Sergey. From owner-ibis Mon Jul 9 07:26:33 2001 Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f69EQV7n016085 for ; Mon, 9 Jul 2001 07:26:33 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 565451A3; Mon, 9 Jul 2001 09:26:23 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 17C7B359 for ; Mon, 9 Jul 2001 09:26:23 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 9 Jul 2001 10:26:22 -0400 Message-ID: From: "Ingraham, Andrew" To: ibis@eda.org Subject: RE: Ibis standard for feedback Date: Mon, 9 Jul 2001 10:26:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain > The method specified by Yoked is a kind of model selecting > method, where the control for driving strong or less strong, > comes from pad itself as specific voltage level. You are probably right. But the first thing that came to mind, to me, was feedback in the input buffer ... for either hysteresis, or bus-hold. They don't necessarily reduce noise, but may make inputs more immune to noise. Regards, Andy From owner-ibis Tue Jul 10 08:53:33 2001 Received: from ptldpop3.ptld.uswest.net (ptldpop3.ptld.uswest.net [198.36.160.3]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6AFrU7n020124 for ; Tue, 10 Jul 2001 08:53:32 -0700 (PDT) Received: (qmail 75939 invoked by alias); 10 Jul 2001 15:53:21 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 75934 invoked by uid 0); 10 Jul 2001 15:53:21 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop3.ptld.uswest.net with SMTP; 10 Jul 2001 15:53:21 -0000 Message-ID: <3B4B24EC.4D8D51F1@vasthorizons.com> Date: Tue, 10 Jul 2001 08:53:16 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: [Fwd: RE: ICM and connector splits] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: RE: ICM and connector splits Date: Tue, 10 Jul 2001 07:23:25 -0500 From: apanella@molex.com To: "Scott McMorrow" Scott, I am off of the ibis-users reflector... Do you happen to know the location where I should signup... _gus -----Original Message----- From: Scott McMorrow Sent: Tuesday, July 10, 2001 2:58 AM To: apanella; ibis Subject: ICM and connector splits All, I would like to initiate a discussion for ICM concerning connectors that can be split into multiple mating connectors.   Examples of this are pcb headers that can accomodate two or more mating connectors.  Edge card connectors with multiple blades which plug into multiple backplane mates ... etc. In each of these cases, the connector on one subsystem has a larger number of pins than each of the mated subsystems, and multiple subsystems can be mated simultaneously.  Without an ability to take a large connector  and split it from one side to the other, it is not possible to automatically map connector models across a connector in a CAD system. I would propose a connector [Split] keyword that allows a connector to be split into multiple smaller mating ports.  A [Split] would be a new type of mapping function which allows for one input port and multiple output ports.  It might look like this: [SplitMap] MateNumber1 Side1            PinSide1       Side2                PinSide2 ModelMapName1    A1             ModelMapName2        A1 ModelMapName1    A2             ModelMapName2        A2 [End SplitMap] MateNumber1 [SplitMap] MateNumber2 ModelMapName1    A20            ModelMapName3        A1 ModelMapName2    A21            ModelMapName3        A2 ... [End SplitMap] MateNumber2 Matrices on the "left" or "input" side of the split would be of the same size as ModelMapName1 implys. Matrices on the "right" or "output" side of the split would be of the same size as the ModelMapName2 or 3 implys. It is assumed that the ports on the split side of the connector are isolated and as such no coupling exists across the split boundary.  This is the case for many real connector systems, but may pose a limitation for some more complex systems. With a [SplitMap] defined, a split could be accomplished in the following way (Do see my comments on the current ICM specification regarding [Begin Cn Model] blocks to understand the proposed changes I have made to attach multiple ports to sections.  In this case, a Split - EndSplit block is similar to a Fork - Endfork block): Split Example :  (a simple two line model with one section split to two ports) [Begin Cn Model] MyExample1 Cn_Model_Type = SLM Model_Name = MyModel1 Model_PinMap = MyModelPinMapA Model_PinMap = MyModelPinMapB Model_PinMap = MyModelPinMapC GSR = 3:1 MyModelPinMapA Cn_Section 1.0 Diagonal_matrix1 Split MateNumber1 Cn_Section 1.0 Diagonal_matrix2 MyModelPinMapB EndSplit MateNumber1 Split MateNumber2 Cn_Section 1.0 Diagonal_matrix2 MyModelPinMapC EndSplit MateNumber2 [End Cn Model] MyExample1 There may be a more elegant way of doing this. Your comments are welcome. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR  97062-3090 (503) 885-1231 http://www.siqual.com From owner-ibis Thu Jul 12 14:55:39 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6CLtX7n010163 for ; Thu, 12 Jul 2001 14:55:38 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA12303; Thu, 12 Jul 2001 14:55:33 -0700 (PDT) Received: from mentor.com (wv35extra09.soho-wv.mentorg.com [172.16.35.9]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NW3WWH1L; Thu, 12 Jul 2001 14:56:49 -0700 Message-ID: <3B4E1CB8.F1FEF39@mentor.com> Date: Thu, 12 Jul 2001 14:55:04 -0700 From: Bob Ross Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, "Ross, Bob" Subject: Agenda IBIS Meeting 7/20/01 Content-Type: multipart/mixed; boundary="------------823D032AF4E5F2A00C8C367C" This is a multi-part message in MIME format. --------------823D032AF4E5F2A00C8C367C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------823D032AF4E5F2A00C8C367C Content-Type: text/plain; charset=us-ascii; name="agenda.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="agenda.txt" IBIS Open Forum Meeting Agenda for 7/20/01 Bridge Number Reservation # Passcode New Number --> (888) 316-5901 none 8744603 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 Stephen Peters and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Peters - Intros of New IBIS Participants, Meeting Quorum Peters - Membership Update and Treasurers Report Fleming/Ross - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Peters - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Peters - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes DAC 2001 IBIS Summit Meeting Feedback de Burgh/Peters PCBEAST 2001 IBIS Summit Meeting Ross North Carolina State University s2ibis3 Project Steer IBIS Model Review Committee Angulo Majordomo and Spam Mail Update Angulo New Administrative Issues All 8:45 Technical Discussion Connector Proposal Review Peters/Ross IBIS Futures Group Report (IBIS-X, API, BIRDxx) Green/Peters BIRD70.3 - Golden Waveforms Edlund BIRD71 - Timing Test Loads in [Model Spec] to Support Peters PCI & PCI-X Other Pending BIRDS Peters ibischk3 Bug Tracking Ross - BUG57 - Non-Monotonic Table Causes Waveform Endpoint Test to Fail New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off --------------823D032AF4E5F2A00C8C367C-- From owner-ibis Thu Jul 12 14:56:17 2001 Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6CLuF7n010166 for ; Thu, 12 Jul 2001 14:56:16 -0700 (PDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA09736 for ; Thu, 12 Jul 2001 21:56:11 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 12 Jul 2001 21:56:13 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3XG1CZG8>; Thu, 12 Jul 2001 14:56:12 -0700 Message-ID: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: Model name question Date: Thu, 12 Jul 2001 14:56:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" All, I would like to find out whether there is a need to include the component name as part of the buffer names for the [Model] keyword in an IBIS file. The reasoning goes like this: If there are two different IBIS files with buffer names inside them which are the same (while the electrical characteristics of the models are different) and these two models are used in the same simulation, could the tool lose track of which one is which? Do tools make these names unique for simulations to prevent this from happening so that me as a model maker wouldn't have to worry about this? Thanks, Arpad ================================================================= From owner-ibis Thu Jul 12 15:28:24 2001 Received: from ptldpop5.ptld.uswest.net ([198.36.160.5]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6CMSE7n010248 for ; Thu, 12 Jul 2001 15:28:23 -0700 (PDT) Received: (qmail 74606 invoked by alias); 12 Jul 2001 22:28:14 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 74593 invoked by uid 0); 12 Jul 2001 22:28:13 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by 198.36.160.5 with SMTP; 12 Jul 2001 22:28:13 -0000 Message-ID: <3B4E2472.779A6D87@vasthorizons.com> Date: Thu, 12 Jul 2001 15:28:03 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Muranyi, Arpad" CC: "'ibis@eda.org'" Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> Content-Type: multipart/mixed; boundary="------------82CEF66FB196E99E691A4D59" This is a multi-part message in MIME format. --------------82CEF66FB196E99E691A4D59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, I believe many simulator vendors already identify models internally by the following tuple: (component_name, model_name) I would recommend formalizing this in future IBIS specifications. We need not specify the exact format of the naming convention, but we do need to clarify that a model should be identified by component_name and model_name, since model_names are not unique. If we were all real sticklers, we would require tools to identify a model by the following tuple: (component_name, model_name, revision) Many a time I have been bit by multiple revisions of models laying around ... especially with automatic path searches of model directories, where the last model loaded is the one that is used. regards, scott "Muranyi, Arpad" wrote: > All, > > I would like to find out whether there is a need to include the > component name as part of the buffer names for the [Model] > keyword in an IBIS file. The reasoning goes like this: > > If there are two different IBIS files with buffer names inside > them which are the same (while the electrical characteristics > of the models are different) and these two models are used in > the same simulation, could the tool lose track of which one is > which? > > Do tools make these names unique for simulations to prevent > this from happening so that me as a model maker wouldn't have > to worry about this? > > Thanks, > > Arpad > ================================================================= -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com --------------82CEF66FB196E99E691A4D59 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------82CEF66FB196E99E691A4D59-- From owner-ibis Thu Jul 12 15:55:57 2001 Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6CMts7n010291 for ; Thu, 12 Jul 2001 15:55:56 -0700 (PDT) Received: from labonte.com (cerberus.cisco.com [161.44.239.21]) by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f6CKPvs23639; Thu, 12 Jul 2001 13:25:57 -0700 Message-ID: <3B4E2AF5.A71E15D4@labonte.com> Date: Thu, 12 Jul 2001 18:55:49 -0400 From: Mike LaBonte X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Muranyi, Arpad" CC: "'ibis@eda.org'" Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A simulator that works directly from IBIS files is able to employ scoping, so that buffer models are only seen by components in the same file. Simulators that translate the IBIS files and import the data into libraries of some other format may lose that same-file relationship, unless other techniques are employed. One technique is to concatenate the IBIS file name to all buffer model names. So I think the answer to Arpad's question is "yes". Mike "Muranyi, Arpad" wrote: > > All, > > I would like to find out whether there is a need to include the > component name as part of the buffer names for the [Model] > keyword in an IBIS file. The reasoning goes like this: > > If there are two different IBIS files with buffer names inside > them which are the same (while the electrical characteristics > of the models are different) and these two models are used in > the same simulation, could the tool lose track of which one is > which? > > Do tools make these names unique for simulations to prevent > this from happening so that me as a model maker wouldn't have > to worry about this? > > Thanks, > > Arpad > ================================================================= From owner-ibis Thu Jul 12 16:07:18 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6CN7G7n010313 for ; Thu, 12 Jul 2001 16:07:18 -0700 (PDT) Received: from arafiq-u30.cisco.com (arafiq-u30.cisco.com [10.34.20.186]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6CN7KP14387; Thu, 12 Jul 2001 16:07:20 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by arafiq-u30.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA06016; Thu, 12 Jul 2001 16:07:11 -0700 (PDT) Sender: arafiq@cisco.com Message-ID: <3B4E2D9E.51CB77B4@cisco.com> Date: Thu, 12 Jul 2001 16:07:10 -0700 From: Abdulrahman Rafiq Reply-To: arafiq@cisco.com Organization: cisco systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Muranyi, Arpad" CC: "'ibis@eda.org'" Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> Content-Type: multipart/mixed; boundary="------------E0BB871779C591CDC4441C9A" This is a multi-part message in MIME format. --------------E0BB871779C591CDC4441C9A Content-Type: multipart/alternative; boundary="------------684AF2662A011ED21B716716" --------------684AF2662A011ED21B716716 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, Do you mind trying to rephrase your question ? "Muranyi, Arpad" wrote: > All, > > I would like to find out whether there is a need to include the > component name as part of the buffer names for the [Model] > keyword in an IBIS file. The reasoning goes like this: > > If there are two different IBIS files with buffer names inside > them which are the same (while the electrical characteristics > of the models are different) and these two models are used in > the same simulation, could the tool lose track of which one is > which? > > Do tools make these names unique for simulations to prevent > this from happening so that me as a model maker wouldn't have > to worry about this? > > Thanks, > > Arpad > ================================================================= -- ------------------------------------------------------------------------- -------------------------------------- - - | | Abdulrahman A. Rafiq (AKA Abbey) | --- --- | | Hardware Engineer | ------- ------ | | ISBU, Cisco Systems, Inc. | ----------- ---------- | -------------------------------------- ------------------------------ | ------------------------------------------------------------------------- --------------684AF2662A011ED21B716716 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad,

Do you mind trying to rephrase your question ?
 

"Muranyi, Arpad" wrote:

All,

I would like to find out whether there is a need to include the
component name as part of the buffer names for the [Model]
keyword in an IBIS file.  The reasoning goes like this:

If there are two different IBIS files with buffer names inside
them which are the same (while the electrical characteristics
of the models are different) and these two models are used in
the same simulation, could the tool lose track of which one is
which?

Do tools make these names unique for simulations to prevent
this from happening so that me as a model maker wouldn't have
to worry about this?

Thanks,

Arpad
=================================================================

-- 
-------------------------------------------------------------------------
--------------------------------------          -             -          |
| Abdulrahman A. Rafiq (AKA Abbey)   |         ---           ---         | 
| Hardware Engineer                  |       -------        ------       |
| ISBU, Cisco Systems, Inc.          |     -----------    ----------     |
--------------------------------------   ------------------------------  | 
-------------------------------------------------------------------------
  --------------684AF2662A011ED21B716716-- --------------E0BB871779C591CDC4441C9A Content-Type: text/x-vcard; charset=us-ascii; name="arafiq.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Abdulrahman Rafiq Content-Disposition: attachment; filename="arafiq.vcf" begin:vcard n:Rafiq;Abdulrahman tel;pager:408-301-8880 tel;cell:805-708-1976 tel;fax:408-526-5504 tel;home:408-615-8427 tel;work:408-527-5540 x-mozilla-html:FALSE url:United States of America org:Cisco Systems;ISBU/SI and Pkg'ing Design Group/ASIC's SI group version:2.1 email;internet:USA title:Hardware Engineer adr;quoted-printable:;;230 West Tasman Drive=0D=0AMail Stop SJ/G/2/3;San Jose;California;93117;USA note;quoted-printable:My fist name is pronounced as:=0D=0A=0D=0AAb dur Rah man =0D=0A=0D=0AIts Arabic, it means servent of the merciful, where merciful =0D=0Ais one of the 99 (out of 2,999) names of God in the Quran.=0D=0AWhere the remaining 2,900 names are found in the Psalms, Torah (old testtament) and =0D=0ABible (the evangelical or ingeel in arabic.)=0D=0A=0D=0A x-mozilla-cpt:;8048 fn:Abdulrahman Rafiq end:vcard --------------E0BB871779C591CDC4441C9A-- From owner-ibis Thu Jul 12 16:17:03 2001 Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6CNH27n010342 for ; Thu, 12 Jul 2001 16:17:03 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for server.eda.ORG [171.64.101.101]) with SMTP; 12 Jul 2001 23:17:13 UT Received: from hlgw.hyperlynx.com (hlgw.hyperlynx.com [192.168.149.1]) by mail.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id QAA31803 for ; Thu, 12 Jul 2001 16:17:12 -0700 Message-ID: <014801c10b28$c6478da0$90cab58b@redmond.innoveda.com> From: "Matthew Flora" Cc: Received: from no.name.available by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 12 Jul 2001 23:17:12 UT References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <3B4E2472.779A6D87@vasthorizons.com> Subject: Re: Model name question Date: Thu, 12 Jul 2001 16:17:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Scott, Arpad, May I suggest that you are headed toward a slippery slope. One common name conflict with models that the tuples mentioned do not eliminate is second source parts from multiple manufacturers. They might have started with the same model and tweaked it for their process. If you try to come up with a scheme where a single name includes every possible identifying mark, then you'll end up with a ridiculously long name. I suggest leaving it to the tools to keep track of which model they are dealing with. It ain't difficult. Software has had to do this for a long time. It's not new. It's not rocket science. Cheers, Matthew Flora ----- Original Message ----- From: "Scott McMorrow" To: "Muranyi, Arpad" Cc: Sent: Thursday, July 12, 2001 3:28 PM Subject: Re: Model name question > Arpad, > > I believe many simulator vendors already identify models > internally by the following tuple: > > (component_name, model_name) > > I would recommend formalizing this in future IBIS specifications. > We need not specify the exact format of the naming convention, > but we do need to clarify that a model should be identified by > component_name and model_name, since model_names are > not unique. > > If we were all real sticklers, we would require tools to identify > a model by the following tuple: > > (component_name, model_name, revision) > > Many a time I have been bit by multiple revisions of models laying > around ... especially with automatic path searches of model directories, > where the last model loaded is the one that is used. > > regards, > > scott > > > "Muranyi, Arpad" wrote: > > > All, > > > > I would like to find out whether there is a need to include the > > component name as part of the buffer names for the [Model] > > keyword in an IBIS file. The reasoning goes like this: > > > > If there are two different IBIS files with buffer names inside > > them which are the same (while the electrical characteristics > > of the models are different) and these two models are used in > > the same simulation, could the tool lose track of which one is > > which? > > > > Do tools make these names unique for simulations to prevent > > this from happening so that me as a model maker wouldn't have > > to worry about this? > > > > Thanks, > > > > Arpad > > ================================================================= > > -- > Scott McMorrow > Principal Engineer > SiQual, Signal Quality Engineering > 18735 SW Boones Ferry Road > Tualatin, OR 97062-3090 > (503) 885-1231 > http://www.siqual.com > > From owner-ibis Thu Jul 12 17:21:53 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6D0Lp7n010487 for ; Thu, 12 Jul 2001 17:21:52 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6D0K9B10473; Thu, 12 Jul 2001 17:20:09 -0700 (PDT) Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148]) by mira-sjcd-4.cisco.com (Mirapoint) with SMTP id AAY01596; Thu, 12 Jul 2001 17:21:49 -0700 (PDT) Message-Id: <200107130021.AAY01596@mira-sjcd-4.cisco.com> Date: Thu, 12 Jul 2001 17:21:48 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: Re: Model name question To: ibis@eda.org, arpad.muranyi@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mfa3stxR49jG/nVhFpp68Q== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Arpad, To avoid this problem(which can occur in a simulator), we append the Component name to each of the buffer name. That makes the buffer name 'unique'. The user can truncate the name to meet the IBIS requirement. Syed > From: "Muranyi, Arpad" > To: "'ibis@eda.org'" > Subject: Model name question > Date: Thu, 12 Jul 2001 14:56:11 -0700 > MIME-Version: 1.0 > > All, > > I would like to find out whether there is a need to include the > component name as part of the buffer names for the [Model] > keyword in an IBIS file. The reasoning goes like this: > > If there are two different IBIS files with buffer names inside > them which are the same (while the electrical characteristics > of the models are different) and these two models are used in > the same simulation, could the tool lose track of which one is > which? > > Do tools make these names unique for simulations to prevent > this from happening so that me as a model maker wouldn't have > to worry about this? > > Thanks, > > Arpad > ================================================================= > From owner-ibis Thu Jul 12 17:33:59 2001 Received: from ptldpop3.ptld.uswest.net (ptldpop3.ptld.uswest.net [198.36.160.3]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6D0Xv7n010518 for ; Thu, 12 Jul 2001 17:33:58 -0700 (PDT) Received: (qmail 29667 invoked by alias); 13 Jul 2001 00:33:57 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 29655 invoked by uid 0); 13 Jul 2001 00:33:57 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop3.ptld.uswest.net with SMTP; 13 Jul 2001 00:33:57 -0000 Message-ID: <3B4E41EA.3BA1417B@vasthorizons.com> Date: Thu, 12 Jul 2001 17:33:46 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Flora CC: ibis@eda.org Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <3B4E2472.779A6D87@vasthorizons.com> <014801c10b28$c6478da0$90cab58b@redmond.innoveda.com> Content-Type: multipart/mixed; boundary="------------952328500AA4109CBA81A532" This is a multi-part message in MIME format. --------------952328500AA4109CBA81A532 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew, I believe you misunderstood me. Let me quote myself: > We need not specify the exact format of the naming convention, > but we do need to clarify that a model should be identified by > component_name and model_name, since model_names are > not unique. I do not suggest any particular naming and/or scoping convention for IBIS models. I do suggest that it be required that some sort of convention is used and defined by each vendor, so that name space and revision problems are eliminated. I suggest that IBIS specifications require that models be tracked in a way that naming conficts cannot occur and revision control can be facilitated. You have just suggested a further clarification to the model naming problem (i.e. manufacturer). I believe the following will uniquely identify an IBIS model in most all cases: (manufacturer, component_name, model_name, revision) My experience is that what is not specified is what breaks designs. I would much rather err on the specification side after 22 years of design work. I've used way too many components and software which use assumptions which are ill-defined, are unpublished to protect the guility, or are in opposition to common sense. It's time to dispel the assumption that component designers and software vendors will do the right thing. regards, scott Matthew Flora wrote: > Scott, Arpad, > > May I suggest that you are headed toward a slippery slope. One common name > conflict with models that the tuples mentioned do not eliminate is second > source parts from multiple manufacturers. They might have started with the > same model and tweaked it for their process. If you try to come up with a > scheme where a single name includes every possible identifying mark, then > you'll end up with a ridiculously long name. > > I suggest leaving it to the tools to keep track of which model they are > dealing with. It ain't difficult. Software has had to do this for a long > time. It's not new. It's not rocket science. > > Cheers, > Matthew Flora > > ----- Original Message ----- > From: "Scott McMorrow" > To: "Muranyi, Arpad" > Cc: > Sent: Thursday, July 12, 2001 3:28 PM > Subject: Re: Model name question > > > Arpad, > > > > I believe many simulator vendors already identify models > > internally by the following tuple: > > > > (component_name, model_name) > > > > I would recommend formalizing this in future IBIS specifications. > > We need not specify the exact format of the naming convention, > > but we do need to clarify that a model should be identified by > > component_name and model_name, since model_names are > > not unique. > > > > If we were all real sticklers, we would require tools to identify > > a model by the following tuple: > > > > (component_name, model_name, revision) > > > > Many a time I have been bit by multiple revisions of models laying > > around ... especially with automatic path searches of model directories, > > where the last model loaded is the one that is used. > > > > regards, > > > > scott > > > > > > "Muranyi, Arpad" wrote: > > > > > All, > > > > > > I would like to find out whether there is a need to include the > > > component name as part of the buffer names for the [Model] > > > keyword in an IBIS file. The reasoning goes like this: > > > > > > If there are two different IBIS files with buffer names inside > > > them which are the same (while the electrical characteristics > > > of the models are different) and these two models are used in > > > the same simulation, could the tool lose track of which one is > > > which? > > > > > > Do tools make these names unique for simulations to prevent > > > this from happening so that me as a model maker wouldn't have > > > to worry about this? > > > > > > Thanks, > > > > > > Arpad > > > ================================================================= > > > > -- > > Scott McMorrow > > Principal Engineer > > SiQual, Signal Quality Engineering > > 18735 SW Boones Ferry Road > > Tualatin, OR 97062-3090 > > (503) 885-1231 > > http://www.siqual.com > > > > -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com --------------952328500AA4109CBA81A532 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------952328500AA4109CBA81A532-- From owner-ibis Fri Jul 13 06:36:41 2001 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DDad7n012703 for ; Fri, 13 Jul 2001 06:36:40 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA64144 for ; Fri, 13 Jul 2001 09:34:41 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6DDUL9153864 for ; Fri, 13 Jul 2001 09:30:22 -0400 Importance: Normal Subject: Bird 70.3 open issues - 2nd call To: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Fri, 13 Jul 2001 08:36:24 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.7 |March 21, 2001) at 07/13/2001 08:36:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I am resending a note that I sent out before the Summit in hopes of getting further discussion before the Open Forum call on 7/20. I have gotten one response already in the positive. I propose we make the changes mentioned below and vote at the following Open Forum. Greg Issue 1: Different inverting and non-inverting drivers This is a legal scenario within IBIS and should be covered by BIRD 70.3. I propose we add a new subparameter Driver_model_inv under [Test Data]. This subparameter is only legal when Test_data_type is differential. I think this is a pretty straight-forward solution to the issue. Any discussion? Issue 2: Legal combinations of Test_data_type and Test_load_type Here are the possible combinations: Case 1: Test_data_type = Single_ended, Test_load_type = Single_ended Case 2: Test_data_type = Single_ended, Test_load_type = Differential Case 3: Test_data_type = Differential, Test_load_type = Single_ended Case 4: Test_data_type = Differential, Test_load_type = Differential Cases 1, 2 and 4 are clear. Cases 1 and 4 are clearly allowed, and Case 2 is clearly NOT allowed. In my opinion, Case 3 should be illegal. If one wanted to capture singled-ended waveforms for a differential driver, one could use Case 1 and just specify the differential driver. I don't see any differences between Case 1 and Case 3. Are there any? Incidentally, this also implies that [Rising Waveform] (and its companions) is legal only for Test_data_type = Single_ended and [Diff Rising Waveform] is legal only for Test_data_type = Differential. I like this solution. It's simple, and it covers the space defined by IBIS. Al Davis proposed a new keyword, [Common Mode Rising Waveform Near], but my gut reaction to this is negative. First, I want to close the BIRD since it's been on the table a long time and is holding up IBIS 4.0. Second, it seems somewhat verbose. I propose that Cases 1 and 4 be legal but Cases 2 and 3 be illegal. Any objections? Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Fri Jul 13 08:44:22 2001 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DFiI7n013027 for ; Fri, 13 Jul 2001 08:44:20 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA04446; Fri, 13 Jul 2001 15:44:10 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Jul 2001 15:43:56 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1391NH>; Fri, 13 Jul 2001 08:43:55 -0700 Message-ID: <10C8636AE359D4119118009027AE99870C5A7448@FMSMSX34> From: "Muranyi, Arpad" To: "'arafiq@cisco.com'" Cc: "'ibis@eda.org'" Subject: RE: Model name question Date: Fri, 13 Jul 2001 08:43:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BB2.9E3A7540" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10BB2.9E3A7540 Content-Type: text/plain; charset="ISO-8859-1" Many of the responses kind of did that already, but here I go anyway: Will a simulation tool get confused if there are identical model names in two different IBIS files used in the same simulation? Arpad ====================================================== -----Original Message----- From: Abdulrahman Rafiq [mailto:arafiq@cisco.com] Sent: Thursday, July 12, 2001 4:07 PM To: Muranyi, Arpad Cc: 'ibis@eda.org' Subject: Re: Model name question Arpad, Do you mind trying to rephrase your question ? "Muranyi, Arpad" wrote: All, I would like to find out whether there is a need to include the component name as part of the buffer names for the [Model] keyword in an IBIS file. The reasoning goes like this: If there are two different IBIS files with buffer names inside them which are the same (while the electrical characteristics of the models are different) and these two models are used in the same simulation, could the tool lose track of which one is which? Do tools make these names unique for simulations to prevent this from happening so that me as a model maker wouldn't have to worry about this? Thanks, Arpad ================================================================= -- ------------------------------------------------------------------------- -------------------------------------- - - | | Abdulrahman A. Rafiq (AKA Abbey) | --- --- | | Hardware Engineer | ------- ------ | | ISBU, Cisco Systems, Inc. | ----------- ---------- | -------------------------------------- ------------------------------ | ------------------------------------------------------------------------- ------_=_NextPart_001_01C10BB2.9E3A7540 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Many of the=20 responses kind of did that already, but
here I go=20 anyway:  Will a simulation tool get confused
if there are=20 identical model names in two = different
IBIS files=20 used in the same simulation?
 
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
-----Original Message-----
From: Abdulrahman Rafiq=20 [mailto:arafiq@cisco.com]
Sent: Thursday, July 12, 2001 4:07=20 PM
To: Muranyi, Arpad
Cc: = 'ibis@eda.org'
Subject:=20 Re: Model name question

Arpad,=20

Do you mind trying to rephrase your question ?
 =20

"Muranyi, Arpad" wrote:=20

All,=20

I would like to find out whether there is a need to include the=20
component name as part of the buffer names for the [Model] =
keyword in=20 an IBIS file.  The reasoning goes like this:=20

If there are two different IBIS files with buffer names inside =
them=20 which are the same (while the electrical characteristics
of the = models are=20 different) and these two models are used in
the same simulation, = could the=20 tool lose track of which one is
which?=20

Do tools make these names unique for simulations to prevent =
this from=20 happening so that me as a model maker wouldn't have
to worry = about this?=20

Thanks,=20

Arpad=20 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= PRE>--  ------------------------------------------------------------------------= - --------------------------------------     &nbs= p;    = -            = ; -          | | Abdulrahman A. Rafiq (AKA Abbey)   = |         = ---           = ---         |  | Hardware = Engineer          &nbs= p;       = |       = -------        = ------       | | ISBU, Cisco Systems, = Inc.          = |     -----------    = ----------     | --------------------------------------   = ------------------------------  |  ------------------------------------------------------------------------= - =20 ------_=_NextPart_001_01C10BB2.9E3A7540-- From owner-ibis Fri Jul 13 09:27:34 2001 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DGRW7n013150 for ; Fri, 13 Jul 2001 09:27:34 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA23916 for ; Fri, 13 Jul 2001 16:27:32 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Jul 2001 16:27:32 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1NY4HF>; Fri, 13 Jul 2001 09:27:30 -0700 Message-ID: <10C8636AE359D4119118009027AE99870C5A744F@FMSMSX34> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: Model name question Date: Fri, 13 Jul 2001 09:27:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Thank you all for your responses so far. However, I feel that my real question was not answered very clearly. I would like to get a feel for how many tools actually do have a problem with the situation outlined in my original message, and how many tools can handle it gracefully because of their way of dealing with these names. Could the tool vendors respond to this, if no other way at least privately to me? Thanks, Arpad ========================================================== -----Original Message----- From: Scott McMorrow [mailto:scott@vasthorizons.com] Sent: Thursday, July 12, 2001 5:34 PM To: Matthew Flora Cc: ibis@eda.org Subject: Re: Model name question Matthew, I believe you misunderstood me. Let me quote myself: > We need not specify the exact format of the naming convention, > but we do need to clarify that a model should be identified by > component_name and model_name, since model_names are > not unique. I do not suggest any particular naming and/or scoping convention for IBIS models. I do suggest that it be required that some sort of convention is used and defined by each vendor, so that name space and revision problems are eliminated. I suggest that IBIS specifications require that models be tracked in a way that naming conficts cannot occur and revision control can be facilitated. You have just suggested a further clarification to the model naming problem (i.e. manufacturer). I believe the following will uniquely identify an IBIS model in most all cases: (manufacturer, component_name, model_name, revision) My experience is that what is not specified is what breaks designs. I would much rather err on the specification side after 22 years of design work. I've used way too many components and software which use assumptions which are ill-defined, are unpublished to protect the guility, or are in opposition to common sense. It's time to dispel the assumption that component designers and software vendors will do the right thing. regards, scott Matthew Flora wrote: > Scott, Arpad, > > May I suggest that you are headed toward a slippery slope. One common name > conflict with models that the tuples mentioned do not eliminate is second > source parts from multiple manufacturers. They might have started with the > same model and tweaked it for their process. If you try to come up with a > scheme where a single name includes every possible identifying mark, then > you'll end up with a ridiculously long name. > > I suggest leaving it to the tools to keep track of which model they are > dealing with. It ain't difficult. Software has had to do this for a long > time. It's not new. It's not rocket science. > > Cheers, > Matthew Flora > > ----- Original Message ----- > From: "Scott McMorrow" > To: "Muranyi, Arpad" > Cc: > Sent: Thursday, July 12, 2001 3:28 PM > Subject: Re: Model name question > > > Arpad, > > > > I believe many simulator vendors already identify models > > internally by the following tuple: > > > > (component_name, model_name) > > > > I would recommend formalizing this in future IBIS specifications. > > We need not specify the exact format of the naming convention, > > but we do need to clarify that a model should be identified by > > component_name and model_name, since model_names are > > not unique. > > > > If we were all real sticklers, we would require tools to identify > > a model by the following tuple: > > > > (component_name, model_name, revision) > > > > Many a time I have been bit by multiple revisions of models laying > > around ... especially with automatic path searches of model directories, > > where the last model loaded is the one that is used. > > > > regards, > > > > scott > > > > > > "Muranyi, Arpad" wrote: > > > > > All, > > > > > > I would like to find out whether there is a need to include the > > > component name as part of the buffer names for the [Model] > > > keyword in an IBIS file. The reasoning goes like this: > > > > > > If there are two different IBIS files with buffer names inside > > > them which are the same (while the electrical characteristics > > > of the models are different) and these two models are used in > > > the same simulation, could the tool lose track of which one is > > > which? > > > > > > Do tools make these names unique for simulations to prevent > > > this from happening so that me as a model maker wouldn't have > > > to worry about this? > > > > > > Thanks, > > > > > > Arpad > > > ================================================================= > > > > -- > > Scott McMorrow > > Principal Engineer > > SiQual, Signal Quality Engineering > > 18735 SW Boones Ferry Road > > Tualatin, OR 97062-3090 > > (503) 885-1231 > > http://www.siqual.com > > > > -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com From owner-ibis Fri Jul 13 10:08:06 2001 Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DH7r7n013276 for ; Fri, 13 Jul 2001 10:07:58 -0700 (PDT) Received: from hobbes.c207-202-218-223.sea1.cablespeed.com (c207-202-218-223.sea1.cablespeed.com [207.202.218.223]) by mail.cablespeed.com (8.9.3/8.9.3) with SMTP id KAA13734; Fri, 13 Jul 2001 10:07:47 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Al Davis To: Scott McMorrow , "Muranyi, Arpad" Subject: Re: Model name question Date: Fri, 13 Jul 2001 10:04:45 -0700 X-Mailer: KMail [version 1.2] Cc: "'ibis@eda.org'" References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <3B4E2472.779A6D87@vasthorizons.com> In-Reply-To: <3B4E2472.779A6D87@vasthorizons.com> MIME-Version: 1.0 Message-Id: <0107131004450A.11917@hobbes.c207-202-218-223.sea1.cablespeed.com> Content-Transfer-Encoding: 8bit On Thursday 12 July 2001 03:28 pm, Scott McMorrow wrote: > I believe many simulator vendors already identify models > internally by the following tuple: > > (component_name, model_name) Almost. It is: (file_name, model_name) or (file_name, component_name, pin_name) A file can contain more than one [Component] and more than one [Model]. In this case, the [Model]'s are available to all [Component]'s in that file. All of these are placed in the file's global scope, which translates at best to file scope when there is more than one file. The proposed connector spec introduces another scoping mechanism [Cn_Model_Family] (or something like that) which may be worth adopting in general. Still, to avoid confusion the concept of file scope must be continued. From owner-ibis Fri Jul 13 11:17:01 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DIGx7n013419 for ; Fri, 13 Jul 2001 11:17:01 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6DIGo512102; Fri, 13 Jul 2001 14:16:50 -0400 From: "Todd Westerhoff" To: "Muranyi, Arpad" , Cc: Subject: RE: Model name question Date: Fri, 13 Jul 2001 14:17:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C10BA6.90342E20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <10C8636AE359D4119118009027AE99870C5A7448@FMSMSX34> This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C10BA6.90342E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit No, it won't get confused at all. But one of the models will be wrong, unless the toolset has done something to render the component/buffer name associations unique. Like prepending the component name to the buffer name, as in Mike LaBonte's reply. By default, SPECCTRAQuest uses the prepend method, for what it's worth. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com] Sent: Friday, July 13, 2001 11:44 AM To: 'arafiq@cisco.com' Cc: 'ibis@eda.org' Subject: RE: Model name question Many of the responses kind of did that already, but here I go anyway: Will a simulation tool get confused if there are identical model names in two different IBIS files used in the same simulation? Arpad ====================================================== -----Original Message----- From: Abdulrahman Rafiq [mailto:arafiq@cisco.com] Sent: Thursday, July 12, 2001 4:07 PM To: Muranyi, Arpad Cc: 'ibis@eda.org' Subject: Re: Model name question Arpad, Do you mind trying to rephrase your question ? "Muranyi, Arpad" wrote: All, I would like to find out whether there is a need to include the component name as part of the buffer names for the [Model] keyword in an IBIS file. The reasoning goes like this: If there are two different IBIS files with buffer names inside them which are the same (while the electrical characteristics of the models are different) and these two models are used in the same simulation, could the tool lose track of which one is which? Do tools make these names unique for simulations to prevent this from happening so that me as a model maker wouldn't have to worry about this? Thanks, Arpad ================================================================= -- ------------------------------------------------------------------------- -------------------------------------- - - | | Abdulrahman A. Rafiq (AKA Abbey) | --- --- | | Hardware Engineer | ------- ------ | | ISBU, Cisco Systems, Inc. | ----------- ---------- | -------------------------------------- ------------------------------ | ------------------------------------------------------------------------- ------=_NextPart_000_0008_01C10BA6.90342E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No, it=20 won't get confused at all.  But one of the models will be wrong, = unless the=20 toolset has done something to render the component/buffer name = associations=20 unique.  Like prepending the component name to the buffer name, as = in Mike=20 LaBonte's reply.
 
By=20 default, SPECCTRAQuest uses the prepend method, for what it's=20 worth.
 
Todd.
 

Todd Westerhoff
SI Engineer
Hammerhead = Networks
5=20 Federal Street
Billerica, MA  = 01821
twester@hhnetwk.com
ph:=20 978-671-5084

-----Original Message-----
From: Muranyi, Arpad=20 [mailto:arpad.muranyi@intel.com]
Sent: Friday, July 13, 2001 = 11:44=20 AM
To: 'arafiq@cisco.com'
Cc:=20 'ibis@eda.org'
Subject: RE: Model name = question

Many of=20 the responses kind of did that already, but
here I go=20 anyway:  Will a simulation tool get confused
if there=20 are identical model names in two = different
IBIS files=20 used in the same simulation?
 
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
-----Original Message-----
From: Abdulrahman Rafiq=20 [mailto:arafiq@cisco.com]
Sent: Thursday, July 12, 2001 4:07 = PM
To: Muranyi, Arpad
Cc:=20 'ibis@eda.org'
Subject: Re: Model name=20 question

Arpad,=20

Do you mind trying to rephrase your question ?
 =20

"Muranyi, Arpad" wrote:=20

All,=20

I would like to find out whether there is a need to include the=20
component name as part of the buffer names for the [Model] =
keyword=20 in an IBIS file.  The reasoning goes like this:=20

If there are two different IBIS files with buffer names inside =
them=20 which are the same (while the electrical characteristics
of the = models=20 are different) and these two models are used in
the same = simulation,=20 could the tool lose track of which one is
which?=20

Do tools make these names unique for simulations to prevent =
this from=20 happening so that me as a model maker wouldn't have
to worry = about this?=20

Thanks,=20

Arpad=20 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
-- 
-------------------------------------------------------------------------=

--------------------------------------      =
;    =
-            =
 -          |
| Abdulrahman A. Rafiq (AKA Abbey)   =
|         =
---           =
---         | 
| Hardware =
Engineer           =
;       =
|       =
-------        =
------       |
| ISBU, Cisco Systems, =
Inc.          =
|     -----------    =
----------     |
--------------------------------------   =
------------------------------  | 
-------------------------------------------------------------------------=
 =20
------=_NextPart_000_0008_01C10BA6.90342E20-- From owner-ibis Fri Jul 13 18:25:38 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6E1Pa7n014276 for ; Fri, 13 Jul 2001 18:25:37 -0700 (PDT) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id VAA19201; Fri, 13 Jul 2001 21:25:30 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id VAA00453; Fri, 13 Jul 2001 21:25:28 -0400 (EDT) Received: from pcjpowell ([139.181.6.113]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id SAA20184; Fri, 13 Jul 2001 18:24:50 -0700 (PDT) From: "Jon Powell" To: "'Todd Westerhoff'" , Subject: RE: Model name question Date: Fri, 13 Jul 2001 18:22:58 -0700 Message-ID: <001e01c10c03$84d76b70$0201a8c0@pcjpowell> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C10BC8.D8789370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C10BC8.D8789370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You know, The real issue is usually: Does the model and part names match up to the users part names in the schematic capture and layout programs. You get that right and you will just naturally be changing the names in the IBIS models. jon -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Friday, July 13, 2001 11:18 AM To: Muranyi, Arpad; arafiq@cisco.com Cc: ibis@eda.org Subject: RE: Model name question No, it won't get confused at all. But one of the models will be wrong, unless the toolset has done something to render the component/buffer name associations unique. Like prepending the component name to the buffer name, as in Mike LaBonte's reply. By default, SPECCTRAQuest uses the prepend method, for what it's worth. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com] Sent: Friday, July 13, 2001 11:44 AM To: 'arafiq@cisco.com' Cc: 'ibis@eda.org' Subject: RE: Model name question Many of the responses kind of did that already, but here I go anyway: Will a simulation tool get confused if there are identical model names in two different IBIS files used in the same simulation? Arpad ====================================================== -----Original Message----- From: Abdulrahman Rafiq [mailto:arafiq@cisco.com] Sent: Thursday, July 12, 2001 4:07 PM To: Muranyi, Arpad Cc: 'ibis@eda.org' Subject: Re: Model name question Arpad, Do you mind trying to rephrase your question ? "Muranyi, Arpad" wrote: All, I would like to find out whether there is a need to include the component name as part of the buffer names for the [Model] keyword in an IBIS file. The reasoning goes like this: If there are two different IBIS files with buffer names inside them which are the same (while the electrical characteristics of the models are different) and these two models are used in the same simulation, could the tool lose track of which one is which? Do tools make these names unique for simulations to prevent this from happening so that me as a model maker wouldn't have to worry about this? Thanks, Arpad ================================================================= -- ------------------------------------------------------------------------- -------------------------------------- - - | | Abdulrahman A. Rafiq (AKA Abbey) | --- --- | | Hardware Engineer | ------- ------ | | ISBU, Cisco Systems, Inc. | ----------- ---------- | -------------------------------------- ------------------------------ | ------------------------------------------------------------------------- ------=_NextPart_000_001F_01C10BC8.D8789370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You=20 know,
The=20 real issue is usually:
Does=20 the model and part names match up to the users part names in the = schematic=20 capture and layout programs.
You=20 get that right and you will just naturally be changing the names in the = IBIS=20 models.
 
jon
 
 
-----Original Message-----
From: Todd Westerhoff=20 [mailto:twester@hhnetwk.com]
Sent: Friday, July 13, 2001 = 11:18=20 AM
To: Muranyi, Arpad; arafiq@cisco.com
Cc:=20 ibis@eda.org
Subject: RE: Model name = question

No,=20 it won't get confused at all.  But one of the models will be = wrong,=20 unless the toolset has done something to render the component/buffer = name=20 associations unique.  Like prepending the component name to the = buffer=20 name, as in Mike LaBonte's reply.
 
By=20 default, SPECCTRAQuest uses the prepend method, for what it's=20 worth.
 
Todd.
 

Todd Westerhoff
SI Engineer
Hammerhead = Networks
5=20 Federal Street
Billerica, MA  = 01821
twester@hhnetwk.com
ph:=20 978-671-5084

-----Original Message-----
From: Muranyi, Arpad=20 [mailto:arpad.muranyi@intel.com]
Sent: Friday, July 13, = 2001 11:44=20 AM
To: 'arafiq@cisco.com'
Cc:=20 'ibis@eda.org'
Subject: RE: Model name=20 question

Many of=20 the responses kind of did that already, but
here I=20 go anyway:  Will a simulation tool get = confused
if there=20 are identical model names in two = different
IBIS=20 files used in the same simulation?
 
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
-----Original Message-----
From: Abdulrahman = Rafiq=20 [mailto:arafiq@cisco.com]
Sent: Thursday, July 12, 2001 = 4:07=20 PM
To: Muranyi, Arpad
Cc:=20 'ibis@eda.org'
Subject: Re: Model name=20 question

Arpad,=20

Do you mind trying to rephrase your question ?
 =20

"Muranyi, Arpad" wrote:=20

All,=20

I would like to find out whether there is a need to include the =
component name as part of the buffer names for the [Model] =
keyword=20 in an IBIS file.  The reasoning goes like this:=20

If there are two different IBIS files with buffer names inside =
them=20 which are the same (while the electrical characteristics
of = the models=20 are different) and these two models are used in
the same = simulation,=20 could the tool lose track of which one is
which?=20

Do tools make these names unique for simulations to prevent =
this=20 from happening so that me as a model maker wouldn't have
to = worry=20 about this?=20

Thanks,=20

Arpad=20 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
-- 
-------------------------------------------------------------------------=

--------------------------------------      =
;    =
-            =
 -          |
| Abdulrahman A. Rafiq (AKA Abbey)   =
|         =
---           =
---         | 
| Hardware =
Engineer           =
;       =
|       =
-------        =
------       |
| ISBU, Cisco Systems, =
Inc.          =
|     -----------    =
----------     |
--------------------------------------   =
------------------------------  | 
-------------------------------------------------------------------------=
 =20
------=_NextPart_000_001F_01C10BC8.D8789370-- From owner-ibis Mon Jul 16 07:18:31 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6GEIS7n019378 for ; Mon, 16 Jul 2001 07:18:30 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6GEHP504708; Mon, 16 Jul 2001 10:17:25 -0400 From: "Todd Westerhoff" To: "Jon Powell" , Subject: RE: Model name question Date: Mon, 16 Jul 2001 10:18:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C10DE0.9810FC90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <001e01c10c03$84d76b70$0201a8c0@pcjpowell> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C10DE0.9810FC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You're right of course, in that getting the right model to associate with the right part is usually the bigegst problem. But ... I think the original question assumed that the "schematic to packaged part" associations had been made correctly, but that two different devices were using buffer models with the same name, that weren't necessarily the same buffer types. You know, the same problems we had in 1997. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Jon Powell [mailto:jpowell@innoveda.com] Sent: Friday, July 13, 2001 9:23 PM To: 'Todd Westerhoff'; ibis@eda.org Subject: RE: Model name question You know, The real issue is usually: Does the model and part names match up to the users part names in the schematic capture and layout programs. You get that right and you will just naturally be changing the names in the IBIS models. jon -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Friday, July 13, 2001 11:18 AM To: Muranyi, Arpad; arafiq@cisco.com Cc: ibis@eda.org Subject: RE: Model name question No, it won't get confused at all. But one of the models will be wrong, unless the toolset has done something to render the component/buffer name associations unique. Like prepending the component name to the buffer name, as in Mike LaBonte's reply. By default, SPECCTRAQuest uses the prepend method, for what it's worth. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com] Sent: Friday, July 13, 2001 11:44 AM To: 'arafiq@cisco.com' Cc: 'ibis@eda.org' Subject: RE: Model name question Many of the responses kind of did that already, but here I go anyway: Will a simulation tool get confused if there are identical model names in two different IBIS files used in the same simulation? Arpad ====================================================== -----Original Message----- From: Abdulrahman Rafiq [mailto:arafiq@cisco.com] Sent: Thursday, July 12, 2001 4:07 PM To: Muranyi, Arpad Cc: 'ibis@eda.org' Subject: Re: Model name question Arpad, Do you mind trying to rephrase your question ? "Muranyi, Arpad" wrote: All, I would like to find out whether there is a need to include the component name as part of the buffer names for the [Model] keyword in an IBIS file. The reasoning goes like this: If there are two different IBIS files with buffer names inside them which are the same (while the electrical characteristics of the models are different) and these two models are used in the same simulation, could the tool lose track of which one is which? Do tools make these names unique for simulations to prevent this from happening so that me as a model maker wouldn't have to worry about this? Thanks, Arpad ================================================================= -- ------------------------------------------------------------------------- -------------------------------------- - - | | Abdulrahman A. Rafiq (AKA Abbey) | --- --- | | Hardware Engineer | ------- ------ | | ISBU, Cisco Systems, Inc. | ----------- ---------- | -------------------------------------- ------------------------------ | ------------------------------------------------------------------------- ------=_NextPart_000_0002_01C10DE0.9810FC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You're right of course, in that getting the = right model=20 to associate with the right part is usually the bigegst = problem.
 
But=20 ...
 
I=20 think the original question assumed that the "schematic to packaged = part"=20 associations had been made correctly, but that two different devices = were using=20 buffer models with the same name, that weren't necessarily the same = buffer=20 types.
 
You=20 know, the same problems we had in 1997.
 
Todd.
 
Todd = Westerhoff
SI=20 Engineer
Hammerhead Networks
5 Federal Street
Billerica, = MA =20 01821
twester@hhnetwk.com
ph: 978-671-5084
-----Original Message-----
From: Jon Powell=20 [mailto:jpowell@innoveda.com]
Sent: Friday, July 13, 2001 = 9:23=20 PM
To: 'Todd Westerhoff'; ibis@eda.org
Subject: = RE: Model=20 name question

You=20 know,
The=20 real issue is usually:
Does=20 the model and part names match up to the users part names in the = schematic=20 capture and layout programs.
You=20 get that right and you will just naturally be changing the names in = the IBIS=20 models.
 
jon
 
 
-----Original Message-----
From: Todd Westerhoff=20 [mailto:twester@hhnetwk.com]
Sent: Friday, July 13, 2001 = 11:18=20 AM
To: Muranyi, Arpad; arafiq@cisco.com
Cc:=20 ibis@eda.org
Subject: RE: Model name = question

No, it won't get confused at all.  = But one of=20 the models will be wrong, unless the toolset has done something to = render=20 the component/buffer name associations unique.  Like prepending = the=20 component name to the buffer name, as in Mike LaBonte's=20 reply.
 
By=20 default, SPECCTRAQuest uses the prepend method, for what it's=20 worth.
 
Todd.
 

Todd Westerhoff
SI Engineer
Hammerhead = Networks
5=20 Federal Street
Billerica, MA  = 01821
twester@hhnetwk.com
ph:=20 978-671-5084

-----Original Message-----
From: Muranyi, Arpad = [mailto:arpad.muranyi@intel.com]
Sent: Friday, July 13, = 2001=20 11:44 AM
To: 'arafiq@cisco.com'
Cc:=20 'ibis@eda.org'
Subject: RE: Model name=20 question

Many=20 of the responses kind of did that already, but
here I=20 go anyway:  Will a simulation tool get = confused
if=20 there are identical model names in two = different
IBIS=20 files used in the same simulation?
 
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
-----Original Message-----
From: Abdulrahman = Rafiq=20 [mailto:arafiq@cisco.com]
Sent: Thursday, July 12, 2001 = 4:07=20 PM
To: Muranyi, Arpad
Cc:=20 'ibis@eda.org'
Subject: Re: Model name=20 question

Arpad,=20

Do you mind trying to rephrase your question ?
 =20

"Muranyi, Arpad" wrote:=20

All,=20

I would like to find out whether there is a need to include = the=20
component name as part of the buffer names for the [Model]=20
keyword in an IBIS file.  The reasoning goes like this: =

If there are two different IBIS files with buffer names = inside=20
them which are the same (while the electrical = characteristics
of=20 the models are different) and these two models are used in =
the same=20 simulation, could the tool lose track of which one is
which? =

Do tools make these names unique for simulations to prevent =
this=20 from happening so that me as a model maker wouldn't have
to = worry=20 about this?=20

Thanks,=20

Arpad=20 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
-- 
-------------------------------------------------------------------------=

--------------------------------------      =
;    =
-            =
 -          |
| Abdulrahman A. Rafiq (AKA Abbey)   =
|         =
---           =
---         | 
| Hardware =
Engineer           =
;       =
|       =
-------        =
------       |
| ISBU, Cisco Systems, =
Inc.          =
|     -----------    =
----------     |
--------------------------------------   =
------------------------------  | 
-------------------------------------------------------------------------=
 =20
------=_NextPart_000_0002_01C10DE0.9810FC90-- From owner-ibis Mon Jul 16 08:02:29 2001 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6GF2R7n019541; Mon, 16 Jul 2001 08:02:29 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA408306; Mon, 16 Jul 2001 11:00:29 -0400 Received: from d01ml253.pok.ibm.com (d01ml253.pok.ibm.com [9.117.200.16]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6GEu9Z35010; Mon, 16 Jul 2001 10:56:09 -0400 Importance: Normal Subject: Ibis request To: ibis@eda.org, ibis-request@eda.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Michael J Lencioni" Date: Mon, 16 Jul 2001 11:02:18 -0400 X-MIMETrack: Serialize by Router on D01ML253/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/16/2001 11:02:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii This note is a request to become a member of the IBIS Open Forum Reflector as well as the IBIS Users' Group Reflector. Please let me know what is required of me to be added to the distribution list. Thanks, Michael From owner-ibis Mon Jul 16 10:45:41 2001 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6GHjd7n020075 for ; Mon, 16 Jul 2001 10:45:40 -0700 (PDT) Received: from gda.Cadence.COM (gda.Cadence.COM [158.140.106.10]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id KAA19547; Mon, 16 Jul 2001 10:45:37 -0700 (PDT) Received: from pc-lgreen.cadence.com ([158.140.154.202]) by gda.Cadence.COM (8.10.1/8.8.5) with ESMTP id f6GHjSN01462; Mon, 16 Jul 2001 13:45:30 -0400 (EDT) Message-Id: <5.0.2.1.2.20010716103942.00ab88e0@gda.cadence.com> X-Sender: lgreen@gda.cadence.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 16 Jul 2001 10:45:31 -0700 To: Scott McMorrow , "Muranyi, Arpad" From: Lynne Green Subject: Re: Model name question Cc: "'ibis@eda.org'" In-Reply-To: <3B4E2472.779A6D87@vasthorizons.com> References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Received: By mailgate2.Cadence.COM as KAA19547 at Mon Jul 16 10:45:37 2001 Hi, Scott and Arpad, I like the idea of formalizing this. At the same time, should we consider allowing more than 20 characters is a buffer name? Cadence uses COMP + MODEL now, and also makes the combination unique within a simulation (default setting). - Lynne At 03:28 PM 7/12/2001 -0700, Scott McMorrow wrote: >Arpad, > >I believe many simulator vendors already identify models >internally by the following tuple: > >(component_name, model_name) > >I would recommend formalizing this in future IBIS specifications. >We need not specify the exact format of the naming convention, >but we do need to clarify that a model should be identified by >component_name and model_name, since model_names are >not unique. > >If we were all real sticklers, we would require tools to identify >a model by the following tuple: > >(component_name, model_name, revision) > >Many a time I have been bit by multiple revisions of models laying >around ... especially with automatic path searches of model directories, >where the last model loaded is the one that is used. > >regards, > >scott > > >"Muranyi, Arpad" wrote: > > > All, > > > > I would like to find out whether there is a need to include the > > component name as part of the buffer names for the [Model] > > keyword in an IBIS file. The reasoning goes like this: > > > > If there are two different IBIS files with buffer names inside > > them which are the same (while the electrical characteristics > > of the models are different) and these two models are used in > > the same simulation, could the tool lose track of which one is > > which? > > > > Do tools make these names unique for simulations to prevent > > this from happening so that me as a model maker wouldn't have > > to worry about this? > > > > Thanks, > > > > Arpad > > ================================================================= > >-- >Scott McMorrow >Principal Engineer >SiQual, Signal Quality Engineering >18735 SW Boones Ferry Road >Tualatin, OR 97062-3090 >(503) 885-1231 >http://www.siqual.com > From owner-ibis Mon Jul 16 11:14:51 2001 Received: from ptldpop5.ptld.uswest.net ([198.36.160.5]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6GIEn7n020187 for ; Mon, 16 Jul 2001 11:14:51 -0700 (PDT) Received: (qmail 90407 invoked by alias); 16 Jul 2001 18:14:48 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 90392 invoked by uid 0); 16 Jul 2001 18:14:48 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by 198.36.160.5 with SMTP; 16 Jul 2001 18:14:48 -0000 Message-ID: <3B532F04.4360F5CB@vasthorizons.com> Date: Mon, 16 Jul 2001 11:14:28 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lynne Green CC: "Muranyi, Arpad" , "'ibis@eda.org'" Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <5.0.2.1.2.20010716103942.00ab88e0@gda.cadence.com> Content-Type: multipart/mixed; boundary="------------C4E7FF2C7BBE57150D9984A8" This is a multi-part message in MIME format. --------------C4E7FF2C7BBE57150D9984A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lynne, My suggestion is to formalize the concept that a unique model name is described by the following: manufacturer.component.model.revision. ... and that simulator vendors should attempt to manage models down to this level of detail. However, understanding that no vendor currently is capable of doing this, that this is desired for future designs with IBIS-X. It should be recommended that vendors document the current method for model management and acknowledge whatever current flaws and name space colisions which can occur. (this is not to point fingers, but rather so that users can correctly accomodate the various tool "qwirks" and guarantee valid simulations. An example "qwirk" might occur when multiple files are loaded into a simulation tool, both of which have the same component name. This can happen easily when multiple revisions of an IBIS model exist, or when there are multiple vendors for the same component. regards, scott Lynne Green wrote: > Hi, Scott and Arpad, > > I like the idea of formalizing this. At the > same time, should we consider allowing > more than 20 characters is a buffer name? > > Cadence uses COMP + MODEL now, and > also makes the combination unique within > a simulation (default setting). > > - Lynne > > At 03:28 PM 7/12/2001 -0700, Scott McMorrow wrote: > >Arpad, > > > >I believe many simulator vendors already identify models > >internally by the following tuple: > > > >(component_name, model_name) > > > >I would recommend formalizing this in future IBIS specifications. > >We need not specify the exact format of the naming convention, > >but we do need to clarify that a model should be identified by > >component_name and model_name, since model_names are > >not unique. > > > >If we were all real sticklers, we would require tools to identify > >a model by the following tuple: > > > >(component_name, model_name, revision) > > > >Many a time I have been bit by multiple revisions of models laying > >around ... especially with automatic path searches of model directories, > >where the last model loaded is the one that is used. > > > >regards, > > > >scott > > > > > >"Muranyi, Arpad" wrote: > > > > > All, > > > > > > I would like to find out whether there is a need to include the > > > component name as part of the buffer names for the [Model] > > > keyword in an IBIS file. The reasoning goes like this: > > > > > > If there are two different IBIS files with buffer names inside > > > them which are the same (while the electrical characteristics > > > of the models are different) and these two models are used in > > > the same simulation, could the tool lose track of which one is > > > which? > > > > > > Do tools make these names unique for simulations to prevent > > > this from happening so that me as a model maker wouldn't have > > > to worry about this? > > > > > > Thanks, > > > > > > Arpad > > > ================================================================= > > > >-- > >Scott McMorrow > >Principal Engineer > >SiQual, Signal Quality Engineering > >18735 SW Boones Ferry Road > >Tualatin, OR 97062-3090 > >(503) 885-1231 > >http://www.siqual.com > > -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com --------------C4E7FF2C7BBE57150D9984A8 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------C4E7FF2C7BBE57150D9984A8-- From owner-ibis Mon Jul 16 13:45:07 2001 Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6GKj07n020618 for ; Mon, 16 Jul 2001 13:45:06 -0700 (PDT) Received: from hobbes.c207-202-218-223.sea1.cablespeed.com (c207-202-218-223.sea1.cablespeed.com [207.202.218.223]) by mail.cablespeed.com (8.9.3/8.9.3) with SMTP id NAA23675; Mon, 16 Jul 2001 13:44:52 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Al Davis To: Scott McMorrow , Lynne Green Subject: Re: Model name question Date: Mon, 16 Jul 2001 13:41:44 -0700 X-Mailer: KMail [version 1.2] Cc: "Muranyi, Arpad" , "'ibis@eda.org'" References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <5.0.2.1.2.20010716103942.00ab88e0@gda.cadence.com> <3B532F04.4360F5CB@vasthorizons.com> In-Reply-To: <3B532F04.4360F5CB@vasthorizons.com> MIME-Version: 1.0 Message-Id: <01071613414401.27196@hobbes.c207-202-218-223.sea1.cablespeed.com> Content-Transfer-Encoding: 8bit On Monday 16 July 2001 11:14 am, Scott McMorrow wrote: > Lynne, > > My suggestion is to formalize the concept that a unique model name > is described by the following: > > manufacturer.component.model.revision. That doesn't work. Model is not in Component scope. Model and Component are at the same level as far as scoping is concerned. You can have a file ... [Component] [Component] [Component] [Model] [Model] [Component] etc... All models are available to all components in that file. The only scoping we have is by file. Moving forward, it may make sense to introduce a [Namespace] to deal with these scoping issues, but I don't think this will solve the problem either. Should IBIS-X offer nested [Define]s ?? al. From owner-ibis Tue Jul 17 05:32:18 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HCWG7n023302 for ; Tue, 17 Jul 2001 05:32:17 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6HCUU529172; Tue, 17 Jul 2001 08:30:30 -0400 From: "Todd Westerhoff" To: "Al Davis" , "Scott McMorrow" , "Lynne Green" Cc: "Muranyi, Arpad" , Subject: RE: Model name question Date: Tue, 17 Jul 2001 08:31:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <01071613414401.27196@hobbes.c207-202-218-223.sea1.cablespeed.com> You know, you could just put one component per file. That's what I do, for exactly the reason you mention. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Al Davis [mailto:aldavis@ieee.org] Sent: Monday, July 16, 2001 4:42 PM To: Scott McMorrow; Lynne Green Cc: Muranyi, Arpad; 'ibis@eda.org' Subject: Re: Model name question On Monday 16 July 2001 11:14 am, Scott McMorrow wrote: > Lynne, > > My suggestion is to formalize the concept that a unique model name > is described by the following: > > manufacturer.component.model.revision. That doesn't work. Model is not in Component scope. Model and Component are at the same level as far as scoping is concerned. You can have a file ... [Component] [Component] [Component] [Model] [Model] [Component] etc... All models are available to all components in that file. The only scoping we have is by file. Moving forward, it may make sense to introduce a [Namespace] to deal with these scoping issues, but I don't think this will solve the problem either. Should IBIS-X offer nested [Define]s ?? al. From owner-ibis Tue Jul 17 07:55:34 2001 Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HEtR7n023741 for ; Tue, 17 Jul 2001 07:55:33 -0700 (PDT) Received: from labonte.com (dhcp-161-44-239-221.cisco.com [161.44.239.221]) by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f6HCKEs02127; Tue, 17 Jul 2001 05:20:14 -0700 Message-ID: <3B545098.4783E6AA@labonte.com> Date: Tue, 17 Jul 2001 10:50:00 -0400 From: Mike LaBonte X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Al Davis CC: Scott McMorrow , Lynne Green , "Muranyi, Arpad" , "'ibis@eda.org'" Subject: Re: Model name question References: <10C8636AE359D4119118009027AE99870C5A7447@FMSMSX34> <5.0.2.1.2.20010716103942.00ab88e0@gda.cadence.com> <3B532F04.4360F5CB@vasthorizons.com> <01071613414401.27196@hobbes.c207-202-218-223.sea1.cablespeed.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adding more complexity to the name scoping features in IBIS-X may not help. The file level scoping in IBIS works today for tools that work directly from IBIS files, building a simulation model in memory and discarding it when the program exits. It is easy for these to observe the scoping rules, and they may have little trouble adapting to new scoping. It is the tools that save the simulation models in proprietary libraries that need special measures to preserve the model-to-component linkage, because short "nicknames" for models become pretty non-unique when they are all thrown into one big library. An IBIS-X file with flexible scoping may present even more difficulty for these tools, which usually encode enough information into the stored model names to keep the linkage straight later. More complex scoping could lead to less readable model names. It would be nice, of course, if no translation were needed. IBIS-X may be flexible enough to eliminate the need for tools to have their own proprietary formats, but I wouldn't count on that happening for some time. The proprietary libraries can take on a life of their own. Mike LaBonte Al Davis wrote: > > On Monday 16 July 2001 11:14 am, Scott McMorrow wrote: > > Lynne, > > > > My suggestion is to formalize the concept that a unique model name > > is described by the following: > > > > manufacturer.component.model.revision. > > That doesn't work. Model is not in Component scope. Model and > Component are at the same level as far as scoping is concerned. > > You can have a file ... > > [Component] > [Component] > [Component] > [Model] > [Model] > [Component] > > etc... > > All models are available to all components in that file. > > The only scoping we have is by file. > > Moving forward, it may make sense to introduce a [Namespace] to deal > with these scoping issues, but I don't think this will solve the > problem either. > > Should IBIS-X offer nested [Define]s ?? > > al. From owner-ibis Tue Jul 17 08:51:44 2001 Received: from mail-srv1.micron.com (masquerade.micron.com [137.201.242.130]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HFpg7n023846 for ; Tue, 17 Jul 2001 08:51:43 -0700 (PDT) Received: from mail-srv1.micron.com (localhost [127.0.0.1]) by mail-srv1.micron.com (8.9.3/8.9.3) with ESMTP id JAA02770 for ; Tue, 17 Jul 2001 09:51:41 -0600 (MDT) Received: from ntexchange01.micron.com (ntexchange01 [137.201.104.84]) by mail-srv1.micron.com (8.9.3/8.9.3) with ESMTP id JAA02762 for ; Tue, 17 Jul 2001 09:51:41 -0600 (MDT) Received: by ntexchange01.micron.com with Internet Mail Service (5.5.2653.19) id <3M9R82QD>; Tue, 17 Jul 2001 09:51:40 -0600 Message-ID: <7D533CAFAAE3D21192C80008C7B25C930DB643EE@ntexchange11.micron.com> From: rrwolff To: "'ibis@eda.org'" Subject: Stacked TSOP modeling Date: Tue, 17 Jul 2001 09:51:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" I am looking for suggestions on how to model a stacked TSOP (or a TwoSOP) arrangement in IBIS. Functionally, only one component in the stacked arrangement is active at any given time. However, the power and ground clamp diodes as well as the die capacitance of the second component will influence the first componenent's operation. I've thought of two ways to model this so far. The first is with a complex package model with a fork statement describing the trace to the second component and a capacitor for the C_comp of the stacked component. In this method, the [Model] of the original component would not change. The downside of this method is that the power and ground clamp curves of the second component are not modeled. The second method is to model the entire arrangement in SPICE. The loading effect of the stacked component and package would then be included in the I-V and V-T curves of the model. However, with the model used in input mode in a simulator, the effect of the complex package and extra die capacitance would not be modeled correctly. There must be a better way to do this, and I'm sure someone has modeled this situation before with IBIS. So, any help you can give me is greatly appreciated. Thanks, Randy Wolff From owner-ibis Tue Jul 17 09:29:38 2001 Received: from ptldpop5.ptld.uswest.net ([198.36.160.5]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6HGTa7n024003 for ; Tue, 17 Jul 2001 09:29:37 -0700 (PDT) Received: (qmail 31652 invoked by alias); 17 Jul 2001 16:29:34 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 31642 invoked by uid 0); 17 Jul 2001 16:29:34 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by 198.36.160.5 with SMTP; 17 Jul 2001 16:29:34 -0000 Message-ID: <3B5467D8.3242B3B@vasthorizons.com> Date: Tue, 17 Jul 2001 09:29:12 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rrwolff , ibis@eda.org Subject: Re: Stacked TSOP modeling References: <7D533CAFAAE3D21192C80008C7B25C930DB643EE@ntexchange11.micron.com> Content-Type: multipart/mixed; boundary="------------B22BDACA313C7BBB721AA497" This is a multi-part message in MIME format. --------------B22BDACA313C7BBB721AA497 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, Stacked TSOP packages will have some extremely interesting models in reality because of the height above the board for the second device and it's coupling to the neighbor. It's an interesting 3D problem. IBIS does not handle coupled package models well. However, what you can do is to take the model produced by a 3D modeler and for each trace, develop the single ended even and odd mode trace parameters. These can even be done in multiple sections to better model the actual physical situation. Then, this can be converted into an IBIS EBD model. An EBD model will allow you to model multiple model sections and multiple I/O's. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com rrwolff wrote: > I am looking for suggestions on how to model a stacked TSOP (or a TwoSOP) > arrangement in IBIS. Functionally, only one component in the stacked > arrangement is active at any given time. However, the power and ground > clamp diodes as well as the die capacitance of the second component will > influence the first componenent's operation. > > I've thought of two ways to model this so far. The first is with a complex > package model with a fork statement describing the trace to the second > component and a capacitor for the C_comp of the stacked component. In this > method, the [Model] of the original component would not change. The > downside of this method is that the power and ground clamp curves of the > second component are not modeled. > > The second method is to model the entire arrangement in SPICE. The loading > effect of the stacked component and package would then be included in the > I-V and V-T curves of the model. However, with the model used in input mode > in a simulator, the effect of the complex package and extra die capacitance > would not be modeled correctly. > > There must be a better way to do this, and I'm sure someone has modeled this > situation before with IBIS. So, any help you can give me is greatly > appreciated. > > Thanks, > Randy Wolff --------------B22BDACA313C7BBB721AA497 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------B22BDACA313C7BBB721AA497-- From owner-ibis Tue Jul 17 15:24:49 2001 Received: from ptldpop5.ptld.uswest.net ([198.36.160.5]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6HMOm7n024846 for ; Tue, 17 Jul 2001 15:24:49 -0700 (PDT) Received: (qmail 81797 invoked by alias); 17 Jul 2001 22:24:43 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 81777 invoked by uid 0); 17 Jul 2001 22:24:42 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by 198.36.160.5 with SMTP; 17 Jul 2001 22:24:42 -0000 Message-ID: <3B54BB13.C972D0B4@vasthorizons.com> Date: Tue, 17 Jul 2001 15:24:19 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Reid, Chris" , ibis@eda.org Subject: Re: namespace, index, and selector. References: <0EC6ED94FF36D511BCE900508BB83C1D4F6D89@svr-orw-exc-02.wv.mentorg.com> Content-Type: multipart/mixed; boundary="------------9424142FF7F165B9657BB013" This is a multi-part message in MIME format. --------------9424142FF7F165B9657BB013 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, I think that a name space of manufacturer.componentFamily.Component.Model.revision works. The block structure would be something like this: Manufacturer ComponentFamily Component Model End Model End Component End Component Family End Manufacturer Things like REVISION, DATE, INFORMATION ... etc, may then appear anywhere within any of these blocks. For example, in this case Date, Revision and Information fields apply to all the sub-blocks: Manufacturer Date Revision Information ComponentFamily Component Model End Model End Component End Component Family End Manufacturer But in the next case, an override for a component has been made at a lower level, indicating that the second component in the list has been revised: Manufacturer Date Revision 2.0 Information ComponentFamily Component1 Model End Model End Component1 Component2 Revision 2.1 Model End Model End Component2 End Component Family End Manufacturer This structure moves the "[Header]" information where it is often useless, down to the appropriate levels where things like Date and Revision number can be tracked. A Header is no longer needed if the information in the header is placed at the appropriate levels. Manufacturer allows us to group all Component Families by a name which is unique. Component Family allows us to group like things together, such as package options, and even pinout options, or large logic families. For IBIS-X, I can see that an awful large number of things can and will be thrown into one file. Since IBIS-X is a modeling language in it's own right, and supports general modeling of interconnect structures, it is possible to place everything needed for a simulation run into one file, much as one does today with Spice. It can be sort of a super EBD. Right now, things like Date and Revision are at the wrong level. They are global to a file, not local to a particular Component. This poses a problem when one component in a file is changed, (i.e. new package parasitics, or pin list), but the remainder of the Components have not changed. This can be the case when there are a number of alternate package or bond-out options for the same silicon. I'd like to see a much better and logical structuring of the information in IBIS-X models, so that we can have information that is more useful and helpful in tracking the state of models in a simulation environment or even in a directory. I believe that we should not only come up with a reasonable nameSpace for models, but also we should restructure the modeling blocks so that information is applied at the right levels. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com "Reid, Chris" wrote: > Al, > > The ICX tool (maybe this was already stated on this thread) scopes > [model] names by the [component] they are in and [component] names > by the EBD they are in. In other words, the EBD name defines a > name-space for the [component]s it uses, and the [component] name > defines a name-space for the [model]s it uses. This may result it > more [model]s than are actually needed (when two different [component]s > use the same [model]) but it does keep the necessary uniqueness. > > This is at variance with the IBIS specification which implies that the > file should define a name-space implicitly. > > The problem really gets messy when users obtain models from many > sources and name conflicts occur. An explicit name-space will not > solve this problem by itself. > > The Java model may be a good one to adopt. Each model provider could > adopt a top-level name-space, like MyCompany.com, and then define > sub-spaces as necessary. It would be good to make this name-space > definition explicit. It may make it easier for users to manage their > models. > > Thanks, > > Chris > > -----Original Message----- > From: Al Davis [mailto:aldavis@ieee.org] > Sent: Tuesday, July 17, 2001 2:28 AM > To: Lynne Green; 'John Angulo'; aldavis@ieee.org; bob_ross; chris_reid; > ibis@lumbercartel.com; gerald.bannert@icn.siemens.de; > gedlund@us.ibm.com; apanella@molex.com; mhaque@ti.com; > angulo@hyperlynx.com; lgreen@cadence.com; Peters, Stephen; > scott@vasthorizons.com; Steve Kaufer; arpad.muranyi@intel.com > Subject: namespace, index, and selector. > > Recent discussion on the IBIS reflector leads me to believe we need > some kind of namespace specifier. > > The (component, model) tuple doesn't work. > > 1. The model is not in component scope. > > 2. model and component are not keywords. > > Connector has a namespace specifier, [Begin_Cn_model_family] or > something like that. > > We should be consistent. > > ========================= > Also .... > > COnnector has an index section. Do we want one in IBIS-X?? > > 1. I think we should. > 2. At least we should be consistent. > ============================ > We have (old IBIS) [Model Selector]. > > How about [Component Selector], [Cn_Model Selector], [Submodel > Selector] .... > > I think we must. [Model] is not a keyword, so how can we have [Model > Selector]. We need to have a selector for anything that can be > defined. > > Syntax must be identical. --------------9424142FF7F165B9657BB013 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------9424142FF7F165B9657BB013-- From owner-ibis Tue Jul 17 17:02:13 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6I02A7n024949 for ; Tue, 17 Jul 2001 17:02:12 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA04751; Tue, 17 Jul 2001 17:02:10 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:03:34 -0700 Message-ID: <0EC6ED94FF36D511BCE900508BB83C1D4F6D8A@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'Scott McMorrow'" , "Reid, Chris" , ibis@eda.org Subject: RE: namespace, index, and selector. Date: Tue, 17 Jul 2001 17:03:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Scott, I like your proposal. It would definitely solve a lot of problems and make it easy for tools to track the information users really need to manage their models. Al, do you agree? Thanks, Chris -----Original Message----- From: Scott McMorrow [mailto:scott@vasthorizons.com] Sent: Tuesday, July 17, 2001 3:24 PM To: Reid, Chris; ibis@eda.org Subject: Re: namespace, index, and selector. Chris, I think that a name space of manufacturer.componentFamily.Component.Model.revision works. The block structure would be something like this: Manufacturer ComponentFamily Component Model End Model End Component End Component Family End Manufacturer Things like REVISION, DATE, INFORMATION ... etc, may then appear anywhere within any of these blocks. For example, in this case Date, Revision and Information fields apply to all the sub-blocks: Manufacturer Date Revision Information ComponentFamily Component Model End Model End Component End Component Family End Manufacturer But in the next case, an override for a component has been made at a lower level, indicating that the second component in the list has been revised: Manufacturer Date Revision 2.0 Information ComponentFamily Component1 Model End Model End Component1 Component2 Revision 2.1 Model End Model End Component2 End Component Family End Manufacturer This structure moves the "[Header]" information where it is often useless, down to the appropriate levels where things like Date and Revision number can be tracked. A Header is no longer needed if the information in the header is placed at the appropriate levels. Manufacturer allows us to group all Component Families by a name which is unique. Component Family allows us to group like things together, such as package options, and even pinout options, or large logic families. For IBIS-X, I can see that an awful large number of things can and will be thrown into one file. Since IBIS-X is a modeling language in it's own right, and supports general modeling of interconnect structures, it is possible to place everything needed for a simulation run into one file, much as one does today with Spice. It can be sort of a super EBD. Right now, things like Date and Revision are at the wrong level. They are global to a file, not local to a particular Component. This poses a problem when one component in a file is changed, (i.e. new package parasitics, or pin list), but the remainder of the Components have not changed. This can be the case when there are a number of alternate package or bond-out options for the same silicon. I'd like to see a much better and logical structuring of the information in IBIS-X models, so that we can have information that is more useful and helpful in tracking the state of models in a simulation environment or even in a directory. I believe that we should not only come up with a reasonable nameSpace for models, but also we should restructure the modeling blocks so that information is applied at the right levels. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com "Reid, Chris" wrote: > Al, > > The ICX tool (maybe this was already stated on this thread) scopes > [model] names by the [component] they are in and [component] names > by the EBD they are in. In other words, the EBD name defines a > name-space for the [component]s it uses, and the [component] name > defines a name-space for the [model]s it uses. This may result it > more [model]s than are actually needed (when two different [component]s > use the same [model]) but it does keep the necessary uniqueness. > > This is at variance with the IBIS specification which implies that the > file should define a name-space implicitly. > > The problem really gets messy when users obtain models from many > sources and name conflicts occur. An explicit name-space will not > solve this problem by itself. > > The Java model may be a good one to adopt. Each model provider could > adopt a top-level name-space, like MyCompany.com, and then define > sub-spaces as necessary. It would be good to make this name-space > definition explicit. It may make it easier for users to manage their > models. > > Thanks, > > Chris > > -----Original Message----- > From: Al Davis [mailto:aldavis@ieee.org] > Sent: Tuesday, July 17, 2001 2:28 AM > To: Lynne Green; 'John Angulo'; aldavis@ieee.org; bob_ross; chris_reid; > ibis@lumbercartel.com; gerald.bannert@icn.siemens.de; > gedlund@us.ibm.com; apanella@molex.com; mhaque@ti.com; > angulo@hyperlynx.com; lgreen@cadence.com; Peters, Stephen; > scott@vasthorizons.com; Steve Kaufer; arpad.muranyi@intel.com > Subject: namespace, index, and selector. > > Recent discussion on the IBIS reflector leads me to believe we need > some kind of namespace specifier. > > The (component, model) tuple doesn't work. > > 1. The model is not in component scope. > > 2. model and component are not keywords. > > Connector has a namespace specifier, [Begin_Cn_model_family] or > something like that. > > We should be consistent. > > ========================= > Also .... > > COnnector has an index section. Do we want one in IBIS-X?? > > 1. I think we should. > 2. At least we should be consistent. > ============================ > We have (old IBIS) [Model Selector]. > > How about [Component Selector], [Cn_Model Selector], [Submodel > Selector] .... > > I think we must. [Model] is not a keyword, so how can we have [Model > Selector]. We need to have a selector for anything that can be > defined. > > Syntax must be identical. From owner-ibis Wed Jul 18 11:28:35 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IISX7n028000 for ; Wed, 18 Jul 2001 11:28:34 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6IISV532174 for ; Wed, 18 Jul 2001 14:28:31 -0400 From: "Todd Westerhoff" To: Subject: IBIS Site - password protected? Date: Wed, 18 Jul 2001 14:28:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Is it just me? I just went to go the IBIS site to look up usage for a particular keyword, and was greeted with a login request popup. HUH? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 12:07:10 2001 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IJ777n028290 for ; Wed, 18 Jul 2001 12:07:09 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id TAA14985 for ; Wed, 18 Jul 2001 19:07:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 19:07:07 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3ZBJJC1V>; Wed, 18 Jul 2001 12:07:05 -0700 Message-ID: <10C8636AE359D4119118009027AE99870C5A7474@FMSMSX34> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: IBIS Site - password protected? Date: Wed, 18 Jul 2001 12:07:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Me too. Arpad ========= -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Wednesday, July 18, 2001 11:29 AM To: ibis@eda.org Subject: IBIS Site - password protected? Is it just me? I just went to go the IBIS site to look up usage for a particular keyword, and was greeted with a login request popup. HUH? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 12:31:19 2001 Received: from cambridge1-smrly1.gtei.net (cambridge1-smrly1.gtei.net [199.94.215.242]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IJVH7n028359 for ; Wed, 18 Jul 2001 12:31:18 -0700 (PDT) Received: from fairchild-cp-fc.fairchildsemi.com (smtp1-fc.fairchildsemi.com [192.233.132.90]) by cambridge1-smrly1.gtei.net (Postfix) with SMTP id 097035C93 for ; Wed, 18 Jul 2001 19:31:16 +0000 (GMT) Received: FROM dnsbak.fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Wed Jul 18 15:28:48 2001 -0400 Received: from notes.fairchildsemi.com (fsce16.fairchildsemi.com [172.21.18.66]) by dnsbak.fairchildsemi.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14645; Wed, 18 Jul 2001 15:28:59 -0400 (EDT) Subject: Re: IBIS Site - password protected? To: "Todd Westerhoff" Cc: From: Adam.Tambone@fairchildsemi.com Date: Wed, 18 Jul 2001 15:31:09 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 07/18/2001 03:31:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Todd, Not just you. I received same greeting. Adam Tambone "Todd Westerhoff" on 07/18/2001 02:28:59 PM To: cc: Subject: IBIS Site - password protected? Is it just me? I just went to go the IBIS site to look up usage for a particular keyword, and was greeted with a login request popup. HUH? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 12:41:36 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IJfY7n028389 for ; Wed, 18 Jul 2001 12:41:35 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6IJfW501653 for ; Wed, 18 Jul 2001 15:41:32 -0400 From: "Todd Westerhoff" To: Subject: Case sensitivity? Date: Wed, 18 Jul 2001 15:42:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Hi all, I'm using IBISCHK V3.2.5 and have noticed that the handling of the keywords Si_location Timing_location seems to be case sensitive, although the IBIS Spec says that keywords are supposed to be case-insensitive. Anyone else seen the same thing? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 12:54:50 2001 Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IJsm7n028454 for ; Wed, 18 Jul 2001 12:54:50 -0700 (PDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA20128 for ; Wed, 18 Jul 2001 12:54:48 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 18 Jul 2001 12:54:34 -0700 Received: from localhost (il0502a-dhcp141.apple.com [17.205.24.141]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id f6IJsYw02173; Wed, 18 Jul 2001 12:54:34 -0700 (PDT) Message-Id: <200107181954.f6IJsYw02173@scv2.apple.com> Date: Wed, 18 Jul 2001 12:53:32 -0700 From: Kim Helliwell Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: IBIS Site - password protected? Cc: ibis@eda.org To: Todd Westerhoff X-Mailer: Apple Mail (2.387) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit yep, I tried and got the same response. Wot gives? Maybe they are going to make us pay for a login?!? If so, when did they plan to announce this? I hope it's just a mistake. Kim On Wednesday, July 18, 2001, at 11:28 AM, Todd Westerhoff wrote: > Is it just me? > > I just went to go the IBIS site to look up usage for a particular > keyword, > and was greeted with a login request popup. > > HUH? > > Todd. > > Todd Westerhoff > SI Engineer > Hammerhead Networks > 5 Federal Street > Billerica, MA 01821 > twester@hhnetwk.com > ph: 978-671-5084 > Kim Helliwell Apple Computer kimgh@apple.com 408 974 9936 From owner-ibis Wed Jul 18 13:01:39 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IK1b7n028486 for ; Wed, 18 Jul 2001 13:01:39 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA23356; Wed, 18 Jul 2001 13:01:30 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.70.103]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NW3WWS0P; Wed, 18 Jul 2001 13:02:55 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3B55EB19.9D5DFC2@mentor.com> Date: Wed, 18 Jul 2001 13:01:29 -0700 From: Bob Ross X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Todd Westerhoff CC: ibis@eda.org, cfleming@eia.org, danh@eia.org Subject: Re: IBIS Site - password protected? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Todd: I have asked Cecilia Fleming to look into this. The IBIS Web site should not be pasword protected. Bob Ross Mentor Graphics Todd Westerhoff wrote: > > Is it just me? > > I just went to go the IBIS site to look up usage for a particular keyword, > and was greeted with a login request popup. > > HUH? > > Todd. > > Todd Westerhoff > SI Engineer > Hammerhead Networks > 5 Federal Street > Billerica, MA 01821 > twester@hhnetwk.com > ph: 978-671-5084 From owner-ibis Wed Jul 18 12:54:22 2001 Received: from www.sigrity.com ([208.203.156.190]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IJsJ7n028447 for ; Wed, 18 Jul 2001 12:54:21 -0700 (PDT) Received: from si116 ([208.203.156.180]) by www.sigrity.com (8.10.2/8.10.2) with SMTP id f6IJsI218466; Wed, 18 Jul 2001 12:54:18 -0700 From: "Raj Raghuram" To: "Todd Westerhoff" Cc: Subject: RE: IBIS Site - password protected? Date: Wed, 18 Jul 2001 12:54:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 I had the same problem too! Raj Raghuram raghu@sigrity.com 4675 Stevens Creek Blvd. , Ste 130 Santa Clara, CA-95051 PH: 408-260-9344 x116 CELL: 408-390-9614 FAX: 408-260-9342 -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Wednesday, July 18, 2001 11:29 AM To: ibis@eda.org Subject: IBIS Site - password protected? Is it just me? I just went to go the IBIS site to look up usage for a particular keyword, and was greeted with a login request popup. HUH? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 13:21:50 2001 Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IKLm7n028519 for ; Wed, 18 Jul 2001 13:21:49 -0700 (PDT) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id <36J3KTA6>; Wed, 18 Jul 2001 16:21:42 -0400 Message-ID: From: "ruston, matt" To: "'Kim Helliwell'" , Todd Westerhoff Cc: ibis@eda.org Subject: RE: IBIS Site - password protected? Date: Wed, 18 Jul 2001 16:21:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" This happened a few months ago too. By the time that it was pointed out and others tried to logon, it was fixed. It sounds like it is taking a little longer this time. Just a glitch. Matt -----Original Message----- From: Kim Helliwell [mailto:kimgh@apple.com] Sent: Wednesday, July 18, 2001 3:54 PM To: Todd Westerhoff Cc: ibis@eda.org Subject: Re: IBIS Site - password protected? yep, I tried and got the same response. Wot gives? Maybe they are going to make us pay for a login?!? If so, when did they plan to announce this? I hope it's just a mistake. Kim On Wednesday, July 18, 2001, at 11:28 AM, Todd Westerhoff wrote: > Is it just me? > > I just went to go the IBIS site to look up usage for a particular > keyword, > and was greeted with a login request popup. > > HUH? > > Todd. > > Todd Westerhoff > SI Engineer > Hammerhead Networks > 5 Federal Street > Billerica, MA 01821 > twester@hhnetwk.com > ph: 978-671-5084 > Kim Helliwell Apple Computer kimgh@apple.com 408 974 9936 From owner-ibis Wed Jul 18 13:36:21 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IKaI7n028563 for ; Wed, 18 Jul 2001 13:36:20 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6IKYYc21816; Wed, 18 Jul 2001 13:34:34 -0700 (PDT) Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148]) by mira-sjcd-4.cisco.com (Mirapoint) with SMTP id AAY70225; Wed, 18 Jul 2001 13:36:16 -0700 (PDT) Message-Id: <200107182036.AAY70225@mira-sjcd-4.cisco.com> Date: Wed, 18 Jul 2001 13:36:16 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: RE: IBIS Site - password protected? To: ibis@eda.org, arpad.muranyi@intel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1+iv5pqwAszL+DHC6Dftlg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc I have requested EIA to look into this. Will get back to you shortly.. Syed > From: "Muranyi, Arpad" > To: ibis@eda.org > Subject: RE: IBIS Site - password protected? > Date: Wed, 18 Jul 2001 12:07:02 -0700 > MIME-Version: 1.0 > > Me too. > > Arpad > ========= > > -----Original Message----- > From: Todd Westerhoff [mailto:twester@hhnetwk.com] > Sent: Wednesday, July 18, 2001 11:29 AM > To: ibis@eda.org > Subject: IBIS Site - password protected? > > > Is it just me? > > I just went to go the IBIS site to look up usage for a particular keyword, > and was greeted with a login request popup. > > HUH? > > Todd. > > Todd Westerhoff > SI Engineer > Hammerhead Networks > 5 Federal Street > Billerica, MA 01821 > twester@hhnetwk.com > ph: 978-671-5084 > > From owner-ibis Wed Jul 18 13:53:04 2001 Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IKr17n028606 for ; Wed, 18 Jul 2001 13:53:03 -0700 (PDT) Received: from hobbes.c207-202-218-223.sea1.cablespeed.com (c207-202-218-223.sea1.cablespeed.com [207.202.218.223]) by mail.cablespeed.com (8.9.3/8.9.3) with SMTP id NAA10462; Wed, 18 Jul 2001 13:52:54 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Al Davis To: "Todd Westerhoff" , Subject: Re: Case sensitivity? Date: Wed, 18 Jul 2001 13:49:42 -0700 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01071813494201.29930@hobbes.c207-202-218-223.sea1.cablespeed.com> Content-Transfer-Encoding: 8bit On Wednesday 18 July 2001 12:42 pm, Todd Westerhoff wrote: > I'm using IBISCHK V3.2.5 and have noticed that the handling of the > keywords > > Si_location > Timing_location > > seems to be case sensitive, although the IBIS Spec says that > keywords are supposed to be case-insensitive. Anyone else seen the > same thing? "keywords" (those names in square brackets) are case-insensitive. Parameters and attributes (those names not in square brackets) are case sensitive. We had discussions on this in the IBIS-X committee, mostly about what we should do going forward. I also asked users, managers, and software developers for their preference. Overwhelmingly, the preference was for NOT case sensitive. After all that, we decided that IBIS-X would not change the rules. We will continue whatever rules traditional IBIS uses. Personally, I think the existing rules are trouble prone and confusing, but we decided to continue them anyway. Todd, if you (or anyone else) want to change the rules to something more consistent, please introduce a BIRD requesting it. The rest of the world will thank you for it. From owner-ibis Wed Jul 18 14:04:35 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IL4W7n028664 for ; Wed, 18 Jul 2001 14:04:34 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6IL4U503813 for ; Wed, 18 Jul 2001 17:04:30 -0400 From: "Todd Westerhoff" To: Subject: RE: Case sensitivity? Date: Wed, 18 Jul 2001 17:05:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01071813494201.29930@hobbes.c207-202-218-223.sea1.cablespeed.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Oops. What I was trying to say was ... There's evidently a problem with IBISCHK V3.2.5. Sorry for not being clear. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Al Davis [mailto:aldavis@ieee.org] Sent: Wednesday, July 18, 2001 4:50 PM To: Todd Westerhoff; ibis@eda.org Subject: Re: Case sensitivity? On Wednesday 18 July 2001 12:42 pm, Todd Westerhoff wrote: > I'm using IBISCHK V3.2.5 and have noticed that the handling of the > keywords > > Si_location > Timing_location > > seems to be case sensitive, although the IBIS Spec says that > keywords are supposed to be case-insensitive. Anyone else seen the > same thing? "keywords" (those names in square brackets) are case-insensitive. Parameters and attributes (those names not in square brackets) are case sensitive. We had discussions on this in the IBIS-X committee, mostly about what we should do going forward. I also asked users, managers, and software developers for their preference. Overwhelmingly, the preference was for NOT case sensitive. After all that, we decided that IBIS-X would not change the rules. We will continue whatever rules traditional IBIS uses. Personally, I think the existing rules are trouble prone and confusing, but we decided to continue them anyway. Todd, if you (or anyone else) want to change the rules to something more consistent, please introduce a BIRD requesting it. The rest of the world will thank you for it. From owner-ibis Wed Jul 18 14:31:53 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6ILVq7n028723 for ; Wed, 18 Jul 2001 14:31:53 -0700 (PDT) Received: from svr-orw-exc-04.wv.mentorg.com ([147.34.97.65]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA11091; Wed, 18 Jul 2001 14:31:52 -0700 (PDT) Received: by svr-orw-exc-04.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id <3VP334JG>; Wed, 18 Jul 2001 14:32:32 -0700 Message-ID: From: "Beal, Weston" To: "'ibis@eda.org'" Subject: RE: Case sensitivity? Date: Wed, 18 Jul 2001 14:32:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Todd, This is a small problem of semantics. Keywords are case-INsensitive, but keywords are also enclosed in square brackets, []. These words you cited are not in square brackets so they are considered subparameters instead of keywords. Now the rules change. Isn't this fun? :) Later, Weston -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Wednesday, July 18, 2001 12:42 PM To: ibis@eda.org Subject: Case sensitivity? Hi all, I'm using IBISCHK V3.2.5 and have noticed that the handling of the keywords Si_location Timing_location seems to be case sensitive, although the IBIS Spec says that keywords are supposed to be case-insensitive. Anyone else seen the same thing? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 15:34:45 2001 Received: from eia.org (gw.eia.org [207.17.181.50]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6IMYh7n028883 for ; Wed, 18 Jul 2001 15:34:44 -0700 (PDT) Received: from EIADOM-Message_Server by eia.org with Novell_GroupWise; Wed, 18 Jul 2001 18:28:17 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 18 Jul 2001 18:27:39 -0400 From: "Cecilia Fleming" To: , "Dan Heinemeier" , Subject: Re: IBIS Site - password protected? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f6IMZS7n028884 Bob: This is definitely a mistake, I will have it corrected ASAP. Cece >>> Bob Ross 07/18/01 16:15 PM >>> Todd: I have asked Cecilia Fleming to look into this. The IBIS Web site should not be pasword protected. Bob Ross Mentor Graphics Todd Westerhoff wrote: > > Is it just me? > > I just went to go the IBIS site to look up usage for a particular keyword, > and was greeted with a login request popup. > > HUH? > > Todd. > > Todd Westerhoff > SI Engineer > Hammerhead Networks > 5 Federal Street > Billerica, MA 01821 > twester@hhnetwk.com > ph: 978-671-5084 From owner-ibis Wed Jul 18 15:50:31 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IMoT7n028913 for ; Wed, 18 Jul 2001 15:50:31 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f6IMoQ506007 for ; Wed, 18 Jul 2001 18:50:27 -0400 From: "Todd Westerhoff" To: Subject: RE: Case sensitivity? Date: Wed, 18 Jul 2001 18:51:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Euruka! You are absolutely right. You know that this brings up my favorite comment, right? Which, for the uninitiated, can be found at: http://www.cafepress.com/kumar_right Thanks for the feedback. Todd ;-) Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 -----Original Message----- From: Beal, Weston [mailto:weston_beal@mentorg.com] Sent: Wednesday, July 18, 2001 5:33 PM To: 'ibis@eda.org' Subject: RE: Case sensitivity? Todd, This is a small problem of semantics. Keywords are case-INsensitive, but keywords are also enclosed in square brackets, []. These words you cited are not in square brackets so they are considered subparameters instead of keywords. Now the rules change. Isn't this fun? :) Later, Weston -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Wednesday, July 18, 2001 12:42 PM To: ibis@eda.org Subject: Case sensitivity? Hi all, I'm using IBISCHK V3.2.5 and have noticed that the handling of the keywords Si_location Timing_location seems to be case sensitive, although the IBIS Spec says that keywords are supposed to be case-insensitive. Anyone else seen the same thing? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 From owner-ibis Wed Jul 18 16:19:14 2001 Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6INJC7n028944 for ; Wed, 18 Jul 2001 16:19:14 -0700 (PDT) Received: from hobbes.c207-202-218-223.sea1.cablespeed.com (c207-202-218-223.sea1.cablespeed.com [207.202.218.223]) by mail.cablespeed.com (8.9.3/8.9.3) with SMTP id QAA14450; Wed, 18 Jul 2001 16:19:04 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Al Davis To: "Todd Westerhoff" , Subject: Re: Case sensitivity? Date: Wed, 18 Jul 2001 16:15:51 -0700 X-Mailer: KMail [version 1.2] References: In-Reply-To: Cc: "Beal, Weston" MIME-Version: 1.0 Message-Id: <01071816155103.29930@hobbes.c207-202-218-223.sea1.cablespeed.com> Content-Transfer-Encoding: 8bit Of course, sometimes you need to be careful. [Model] is not case sensitive, but Model_type is. Well .... Clearly, [Model] and [mOdEl] are equivalent. They are keywords in traditional IBIS. Clearly, Model_type and Model_tYpE are not. They are subparameters in traditional IBIS. What about Model_type and mOdEl_type ? From owner-ibis Thu Jul 19 01:10:29 2001 Received: from pltdpop4.ptld.uswest.net (ptldpop4.ptld.uswest.net [198.36.160.4]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6J8AP7n000124 for ; Thu, 19 Jul 2001 01:10:28 -0700 (PDT) Received: (qmail 30372 invoked by alias); 19 Jul 2001 08:10:23 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 30361 invoked by uid 0); 19 Jul 2001 08:10:23 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop4.ptld.uswest.net with SMTP; 19 Jul 2001 08:10:23 -0000 Message-ID: <3B5695F0.C05F2662@vasthorizons.com> Date: Thu, 19 Jul 2001 01:10:24 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: [Fwd: IBIS ML comment] Content-Type: multipart/alternative; boundary="------------0B84B3EFBF55230FB0144369" --------------0B84B3EFBF55230FB0144369 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stephen, I've started reviewing the IBIS-X and ML specifications. As I have time, I will prepare a list of comments as I did for the ICM specification. For now, here is the first obivious issue: On page 10 there is an example of a receiver: [Define Model] simple_receiver (pwr, gnd, input) capacitor io_cap (output gnd) C=C_comp resistor term_res (output pwr) R=(R_pullup || open) …MORE NEEDED… [End Model] simple_receiver Since there is no section 9 to define the [Define Model] block I am just guessing here, but ... since your input parameter list is: pwr gnd input the reference to output does not make sense. Shouldn't the model be: [Define Model] simple_receiver (pwr, gnd, input) capacitor io_cap (input gnd) C=C_comp resistor term_res (input pwr) R=(R_pullup || open) …MORE NEEDED… [End Model] simple_receiver regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com --------------0B84B3EFBF55230FB0144369 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stephen,

I've started reviewing the IBIS-X and ML specifications.
As I have time, I will prepare a list of comments as I did
for the ICM specification.

For now, here is the first obivious issue:

On page 10 there is an example of a receiver:
 

[Define Model] simple_receiver (pwr, gnd, input)
capacitor io_cap (output gnd) C=C_comp
resistor term_res (output pwr) R=(R_pullup || open)
…MORE NEEDED…
[End Model] simple_receiver
Since there is no section 9 to define the [Define Model]
block I am just guessing here, but ... since your input
parameter list is:
        pwr
        gnd
        input

the reference to output does not make sense.  Shouldn't
the model be:

[Define Model] simple_receiver (pwr, gnd, input)
capacitor io_cap (input gnd) C=C_comp
resistor term_res (input pwr) R=(R_pullup || open)
…MORE NEEDED…
[End Model] simple_receiver
 

regards,

scott
 

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com
  --------------0B84B3EFBF55230FB0144369-- From owner-ibis Thu Jul 19 01:40:45 2001 Received: from pltdpop4.ptld.uswest.net (ptldpop4.ptld.uswest.net [198.36.160.4]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6J8eh7n000286 for ; Thu, 19 Jul 2001 01:40:44 -0700 (PDT) Received: (qmail 53368 invoked by alias); 19 Jul 2001 08:40:41 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 53358 invoked by uid 0); 19 Jul 2001 08:40:41 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop4.ptld.uswest.net with SMTP; 19 Jul 2001 08:40:41 -0000 Message-ID: <3B569D0A.21CB4AB1@vasthorizons.com> Date: Thu, 19 Jul 2001 01:40:42 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peters, Stephen" , ibis@eda.org Subject: Re: IBIS ML comment References: <7FD5C79AD680D211AC4100A0C96B501C084A7824@orsmsx49.jf.intel.com> <3B569383.5E2FA54D@vasthorizons.com> Content-Type: multipart/mixed; boundary="------------816FD4A3D8E2F66071864ADB" This is a multi-part message in MIME format. --------------816FD4A3D8E2F66071864ADB Content-Type: multipart/alternative; boundary="------------B54F2509340C8E9DB49774AD" --------------B54F2509340C8E9DB49774AD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stephen, In addition in the simple_receiver model is used as follows: [Model] xyz model_type simple_receiver C_comp 3pF 2pF 4pF R_pullup 50 47 55 [Supply Voltage] 3.3v 3.0v 3.6v [Power Clamp] | volts I(typ) I(min) I(max) -3.3v 0.0v 0.5v 0.6v 1.0v 2.5v 3.3v [Gnd Clamp] | volts I(typ) I(min) I(max) -3.3v 100ma 80ma 120ma -2.5v -1.0v -0.6v 0.0v 3.3v [End Model] Now, there is an interesting problem here. In the model definition for simple_receiver, we have defined the nodal connections to power and ground and input( pwr, gnd, input ). However, when we get to the instantiation of that model, these nodes are not carried through ... they are implied! This is very, very, very bad. In fact, there is nothing that explicitly maps the implied power and ground clamps to specific power and ground nodes. Power and ground clamp tables are 2-port elements. As such, there needs to be a definition for the connection of these ports. We cannot continue to leave these to be implied by IBIS-X. We also cannot assume a particular name for the ground and power ports. Or that there will only be two clamp curves maximum and just one I/O node. In this model there are implied connections for all of these lines: [Supply Voltage] 3.3v 3.0v 3.6v [Power Clamp] [Gnd Clamp] What two nodes should the supply voltage be attached to? What two nodes should the power clamp be attached to? What two nodes should the ground clamp be attached to? What happens when there are two input pins, such as on a differential receiver? They need to be explicitly defined and mapped to node names, since implicit naming (as currently used in IBIS) will no longer work. I suggest that I/V curves be considered as 2-port elements, just like a resistor. In this case, the model could be more explicitly stated as follows: [Define Model] simple_receiver (pwr, gnd, input) capacitor io_cap (input gnd) C=C_comp resistor term_res (input pwr) R=(R_pullup || open) ivcurve power_clamp (pwr input) PC=(Power_clamp || open) ivcurve ground_clamp (input gnd) GC=(Gnd_clamp || open) powerSelector voltage_range (pwr gnd) VR=(Supply_voltage) [End Model] simple_receiver [Model] xyz model_type simple_receiver C_comp 3pF 2pF 4pF R_pullup 50 47 55 [Supply Voltage] 3.3v 3.0v 3.6v [Temp] 25 125 0 [Power Clamp] powerClampTable_xyz [Gnd Clamp] groundClampTable_xyz [End Model] One could place the table in model using the "standard fashion" or one could call a named table. [Table] powerClampTable_xyz | volts I(typ) I(min) I(max) -3.3v 0.0v 0.5v 0.6v 1.0v 2.5v 3.3v [End Table] powerClampTable_xyz Since the tables are general, they can be used as a standard matrix element to describe most anything. And ... they are not limited to min typ and max columns. It is certainly possible to extend the table to additional supply voltage and/or temperature corners just by adding columns. This sort of structure would now allow the same IV curves to be shared by multiple models in a component or across multiple components in a component family. This makes sense since many I/O's on a device are identical structures with internal control signal differences (i.e. input, 3-state, I/O ...). regards, scott Scott McMorrow wrote: > Stephen, > > I've started reviewing the IBIS-X and ML specifications. > As I have time, I will prepare a list of comments as I did > for the ICM specification. > > For now, here is the first obivious issue: > > On page 10 there is an example of a receiver: > > > [Define Model] simple_receiver (pwr, gnd, input) > capacitor io_cap (output gnd) C=C_comp > resistor term_res (output pwr) R=(R_pullup || open) > …MORE NEEDED… > [End Model] simple_receiver > > Since there is no section 9 to define the [Define Model] > block I am just guessing here, but ... since your input > parameter list is: > pwr > gnd > input > > the reference to output does not make sense. Shouldn't > the model be: > > [Define Model] simple_receiver (pwr, gnd, input) > capacitor io_cap (input gnd) C=C_comp > resistor term_res (input pwr) R=(R_pullup || open) > …MORE NEEDED… > [End Model] simple_receiver > > > regards, > > scott > > > -- > Scott McMorrow > Principal Engineer > SiQual, Signal Quality Engineering > 18735 SW Boones Ferry Road > Tualatin, OR 97062-3090 > (503) 885-1231 > http://www.siqual.com > -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com --------------B54F2509340C8E9DB49774AD Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stephen,

In addition in the simple_receiver model is used as
follows:

[Model] xyz
model_type simple_receiver
C_comp 3pF 2pF 4pF
R_pullup 50 47 55
[Supply Voltage] 3.3v 3.0v 3.6v
[Power Clamp]
| volts I(typ) I(min) I(max)
-3.3v
0.0v
0.5v
0.6v
1.0v
2.5v
3.3v
[Gnd Clamp]
| volts I(typ) I(min) I(max)
-3.3v 100ma 80ma 120ma
-2.5v
-1.0v
-0.6v
0.0v
3.3v
[End Model]
 

Now, there is an interesting problem here.  In the model definition for
simple_receiver, we have defined the nodal connections to power and
ground and input( pwr, gnd, input ).  However, when we get to the
instantiation of that model, these nodes are not carried through ... they
are implied!   This is very, very, very bad.  In fact, there is nothing that
explicitly maps the implied power and ground clamps to specific power
and ground nodes.

Power and ground clamp tables are 2-port elements.  As such, there
needs to be a definition for the connection of these ports.  We cannot
continue to leave these to be implied by IBIS-X.  We also cannot assume
a particular name for the ground and power ports.  Or that there will
only be two clamp curves maximum and just one I/O node.

In this model there are implied connections for all of these lines:

[Supply Voltage] 3.3v 3.0v 3.6v
[Power Clamp]
[Gnd Clamp]

What two nodes should the supply voltage be attached to?
What two nodes should the power clamp be attached to?
What two nodes should the ground clamp be attached to?
What happens when there are two input pins, such as on
a differential receiver?
They need to be explicitly defined and mapped to node names, since
implicit naming (as currently used in IBIS) will no longer work.

I suggest that I/V curves be considered as 2-port
elements, just like a resistor.  In this case, the model could be
more explicitly stated as follows:

[Define Model] simple_receiver (pwr, gnd, input)
capacitor         io_cap (input gnd) C=C_comp
resistor            term_res (input pwr) R=(R_pullup || open)
ivcurve             power_clamp (pwr input) PC=(Power_clamp || open)
ivcurve             ground_clamp (input gnd) GC=(Gnd_clamp || open)
powerSelector voltage_range (pwr gnd) VR=(Supply_voltage)

[End Model] simple_receiver

[Model] xyz
model_type simple_receiver
C_comp 3pF 2pF 4pF
R_pullup 50 47 55
[Supply Voltage] 3.3v 3.0v 3.6v
[Temp]    25 125 0
[Power Clamp] powerClampTable_xyz
[Gnd Clamp] groundClampTable_xyz
[End Model]
 

One could place the table in model using the "standard fashion"
or one could call a named table.

[Table] powerClampTable_xyz
| volts I(typ) I(min) I(max)
-3.3v
0.0v
0.5v
0.6v
1.0v
2.5v
3.3v
[End Table] powerClampTable_xyz
 

Since the tables are general, they can be used as a standard
matrix element to describe most anything.  And ... they are not
limited to min typ and max columns.  It is certainly possible to
extend the table to additional supply voltage and/or temperature
corners just by adding columns.

This sort of structure would now allow the same IV curves to
be shared by multiple models in a component or across
multiple components in a component family.  This makes sense
since many I/O's on a device are identical structures with
internal control signal differences (i.e. input, 3-state, I/O ...).
 

regards,

scott

Scott McMorrow wrote:

Stephen,

I've started reviewing the IBIS-X and ML specifications.
As I have time, I will prepare a list of comments as I did
for the ICM specification.

For now, here is the first obivious issue:

On page 10 there is an example of a receiver:
 

[Define Model] simple_receiver (pwr, gnd, input)
capacitor io_cap (output gnd) C=C_comp
resistor term_res (output pwr) R=(R_pullup || open)
…MORE NEEDED…
[End Model] simple_receiver
Since there is no section 9 to define the [Define Model]
block I am just guessing here, but ... since your input
parameter list is:
        pwr
        gnd
        input

the reference to output does not make sense.  Shouldn't
the model be:

[Define Model] simple_receiver (pwr, gnd, input)
capacitor io_cap (input gnd) C=C_comp
resistor term_res (input pwr) R=(R_pullup || open)
…MORE NEEDED…
[End Model] simple_receiver
 

regards,

scott
 

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com
 

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com
  --------------B54F2509340C8E9DB49774AD-- --------------816FD4A3D8E2F66071864ADB Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-239-4400 x-mozilla-html:TRUE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@siqual.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------816FD4A3D8E2F66071864ADB-- From owner-ibis Thu Jul 19 06:46:08 2001 Received: from mail.pad.zuken.de (mail.pad.zuken.de [195.124.89.200]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6JDk57n001218 for ; Thu, 19 Jul 2001 06:46:07 -0700 (PDT) Received: from zuken.de (fwpad.pad.zuken.de [195.124.89.194]) by mail.pad.zuken.de (Postfix) with ESMTP id D7D14F3D1; Thu, 19 Jul 2001 15:37:52 +0200 (MET DST) Sender: duffy@pad.zuken.de Message-ID: <3B56E49A.4A57CF8@zuken.de> Date: Thu, 19 Jul 2001 13:46:02 +0000 From: Ralf Bruening Reply-To: ralf.bruening@pad.zuken.de Organization: ZUKEN EMC Center Paderborn X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ibis@vhdl.org" , Dan Heinemeier , Cecilia Fleming Subject: EIA/IBIS Page and Netscape ??? Content-Type: multipart/mixed; boundary="------------7015879016AAEC47CCD39B1A" This is a multi-part message in MIME format. --------------7015879016AAEC47CCD39B1A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, following the discussion about the login request to the EIA pages I have just realized that the new EIA Homepage cannot been viewed with Netscape 4.75 (IE works fine - even as I cannot find the IBIS link). I don't want to start a browser discussion here, but I seriously dislike this as I do not intend to trash my HP just to access soem web pages, I'm even more sur[rised as I'm asked to move to the Microsoft (!) support pages from the CSS Style-Sheet Error which netscape is complaining about for more help - what a funny joke. regards Ralf --------------7015879016AAEC47CCD39B1A Content-Type: text/x-vcard; charset=us-ascii; name="ralf.bruening.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ralf Bruening Content-Disposition: attachment; filename="ralf.bruening.vcf" begin:vcard n:Bruening;Ralf tel;cell:+49 172 9070675 tel;fax:+49 5251 150 700 tel;work:+49 5251 150 621 x-mozilla-html:TRUE url:http://www.zuken.com org:ZUKEN - Be First ! version:2.1 email;internet:ralf.bruening@zuken.de title:Product Manager Board Integrity Solutions adr;quoted-printable:;;EMC Center Paderborn=0D=0AVattmannstrasse 3;33100 Paderborn;;;Germany x-mozilla-cpt:;4600 fn:Ralf Bruening end:vcard --------------7015879016AAEC47CCD39B1A-- From owner-ibis Thu Jul 19 09:27:25 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6JGRN7n001738 for ; Thu, 19 Jul 2001 09:27:24 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6JGRSe15086 for ; Thu, 19 Jul 2001 09:27:28 -0700 (PDT) Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148]) by mira-sjcd-4.cisco.com (Mirapoint) with SMTP id AAY82727; Thu, 19 Jul 2001 09:27:02 -0700 (PDT) Message-Id: <200107191627.AAY82727@mira-sjcd-4.cisco.com> Date: Thu, 19 Jul 2001 09:27:02 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: IBIS website is up.. To: ibis@eda.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0Dv8L8eu+dAuRzAJVWrSyw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Try: http://www.eigroup.org/IBIS/Default.htm Syed. From owner-ibis Thu Jul 19 10:02:48 2001 Received: from eia.org (gw.eia.org [207.17.181.50]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f6JH2g7n001876 for ; Thu, 19 Jul 2001 10:02:45 -0700 (PDT) Received: from EIADOM-Message_Server by eia.org with Novell_GroupWise; Thu, 19 Jul 2001 12:56:02 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 19 Jul 2001 12:55:30 -0400 From: "Cecilia Fleming" To: , Subject: Re: IBIS website is up.. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f6JH5i7n001878 The IBIS Website is back to normal. Regards Cece >>> Syed Huq 07/19/01 12:24 PM >>> Try: http://www.eigroup.org/IBIS/Default.htm Syed. From owner-ibis Fri Jul 20 17:36:57 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6L0at7n006795 for ; Fri, 20 Jul 2001 17:36:56 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com ([147.34.96.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA22589; Fri, 20 Jul 2001 17:36:53 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.70.103]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PKBXTS0X; Fri, 20 Jul 2001 17:38:20 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3B58CEA4.A2AE89F8@mentor.com> Date: Fri, 20 Jul 2001 17:36:52 -0700 From: Bob Ross X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gregory R Edlund CC: ibis@vhdl.org Subject: Re: Bird 70.3 open issues - 2nd call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg: Sorry for the delay in responding to your messages. Per the discussion at the IBIS Meeting today, I am documenting my comments in your text. I hope that they will be considered and that a BIRD70.4 can be issued by next week in time for voting. BIRD70.3 incorrectly documents Test_data_type as a subparameter of [Test Load] in several places. You have agreed to fix this. Bob Ross Mentor Graphics > Gregory R Edlund wrote: > > I am resending a note that I sent out before the Summit in hopes of > getting further discussion before the Open Forum call on 7/20. I have > gotten one response already in the positive. I propose we make the > changes mentioned below and vote at the following Open Forum. > > Greg > > Issue 1: Different inverting and non-inverting drivers > > This is a legal scenario within IBIS and should be covered by BIRD 70.3. I > propose we add a new subparameter Driver_model_inv under [Test Data]. This > subparameter is only legal when Test_data_type is differential. I agree. I would also add for completeness the a Receiver_model_inv subparameter to the [Test Load] keyword in case we have to support unsymetrical receivers with internal terminations. > > I think this is a pretty straight-forward solution to the issue. Any > discussion? > > Issue 2: Legal combinations of Test_data_type and Test_load_type > > Here are the possible combinations: > > Case 1: Test_data_type = Single_ended, Test_load_type = Single_ended > Case 2: Test_data_type = Single_ended, Test_load_type = Differential > Case 3: Test_data_type = Differential, Test_load_type = Single_ended > Case 4: Test_data_type = Differential, Test_load_type = Differential > > Cases 1, 2 and 4 are clear. Cases 1 and 4 are clearly allowed, and Case 2 > is clearly NOT allowed. I agree. > In my opinion, Case 3 should be illegal. If one > wanted to capture singled-ended waveforms for a differential driver, one > could use Case 1 and just specify the differential driver. I would use Case 4, not Case 1 for this. > I don't see any > differences between Case 1 and Case 3. Are there any? I view Case 3 can be a subset of Case 4, but with the Rdiff* entries omitted or set to a high value. Case 3/4 is needed to specify differential drivers. Case 1 should imply only Single_ended nets. The "inverting" side is not given or implied. > > Incidentally, this also implies that [Rising Waveform] (and its companions) > is legal only for Test_data_type = Single_ended and [Diff Rising Waveform] > is legal only for Test_data_type = Differential. I like this solution. > It's simple, and it covers the space defined by IBIS. I think Single_ended golden waveforms should be permitted for the Differential driver case. > > Al Davis proposed a new keyword, [Common Mode Rising Waveform Near], but my > gut reaction to this is negative. First, I want to close the BIRD since > it's been on the table a long time and is holding up IBIS 4.0. Second, it > seems somewhat verbose. I agree. While there may be merit in Al's proposal, it adds another level of complexity beyond the Single_ended and Differential set of validation waveforms. > > I propose that Cases 1 and 4 be legal but Cases 2 and 3 be illegal. Any > objections? I agree. We can live with just Case 1 and Case 4. Case 2 and 3 should be illegal. Case 4 with Rdiff* omitted or set to a large value can be used if Case 3 situations are needed. For Case 1, some added text is needed under [Test Data] and [Test Load] regarding what keywords and subparameters are used. For example, the differential golden waveforms [Diff ...] and the *_inv models and the Rdiff* entries would be ignored. The parser itself can issue a Warning if this data exists. For Case 4, a statement is needed that any Single_ended response for different non-inverting and inverting models (unsymmetrical differential operation) would be referenced to the non-inverting side. If the model provider needed the single-ended inverting golden waveforms, then a different [Test Data] and [Test Load] keyword set would be used, but with the model entries interchanged. So there is no techical limit. Because of symmetry, this is not a concern if the non-inverting and inverting models are identical. This resolution is slightly different than what you proposed. You stated that Case 4 should be for differential golden waveforms only. I am proposing that it support both differential and single-ended waveforms because the EDA tool probably can display and output both at the same time in differential mode. > > Greg Edlund > Electrical Packaging > IBM Server Technology Development > 3605 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com From owner-ibis Mon Jul 23 11:23:05 2001 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6NIN37n012252 for ; Mon, 23 Jul 2001 11:23:04 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA239344 for ; Mon, 23 Jul 2001 14:21:00 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6NIGXq55668 for ; Mon, 23 Jul 2001 14:16:33 -0400 Importance: Normal Subject: BIRD 70.4 To: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Mon, 23 Jul 2001 13:22:47 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.7 |March 21, 2001) at 07/23/2001 01:22:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii ******************************************************************************* ******************************************************************************* BIRD ID#: 70.4 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: March 16, 2001; April 16, 2001; April 18, 2001; May 4, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are eight Wavevform keywords whose scope is local. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: |============================================================================= | | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a set of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Driver_model_inv, Test_load | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "Single_ended" or "Differential." |* The value of Test_data_type must match the value of |* Test_load_type found in the load called by Test_Load. | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] |* name. Driver_model_inv is only legal if Test_data_type is |* Differential. Driver_model_inv is not required but may be |* used in the case in which a differential driver uses two |* different models for the inverting and non-inverting pins. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | |----------------------------------------------------------------------------- | [Test Data] Data1 Test_data_type Single_ended Driver_model Buffer1 Test_load Load1 | |============================================================================= | | Keywords: [Rising Waveform Near], [Falling Waveform Near], | [Rising Waveform Far], [Falling Waveform Far], | [Diff Rising Waveform Near], [Diff Falling Waveform Near], | [Diff Rising Waveform Far], [Diff Falling Waveform Far] | Required: At least one Rising/Falling waveform pair is required under | the scope of the [Test Data] keyword. | Description: Describes the shape of the rising and falling Golden | Waveforms of a given driver and a given [Test Load]. | A model developer may use the [Rising Waveform Near/Far] and | [Falling Waveform Near/Far] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of | SPICE and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |* Both differential and single-ended waveforms are allowed |* regardless of the value of Test_data_type. If Test_data_type |* is Singled_ended then differential waveforms will be ignored. |* If Test_data_type is Differential, a single-ended waveform |* uses the model specified by Driver_model. | |----------------------------------------------------------------------------- | [Rising Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= | | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables correspond to a given [Test Load] which is specified | by the Test_load subparameter under the [Test Data] keyword. | | Sub-Params: Test_load_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, Receiver_model_inv, | R_diff_near, R_diff_far. | | Usage Rules: The Test_load_type subparameter is required, and its value |* must be either "Single_ended" or "Differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_load_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [Voltage Range] keyword. |* If either Rp1_near or Rp1_far is used, then V_term1 must |* also be used. | | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. |* If either Rp2_near or Rp2_far is used, then V_term2 must |* also be used. | | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | |* Receiver_model_inv is not required but may be used in the |* case in which a differential receiver uses two different |* models for the inverting and non-inverting pins. |* Receiver_model_inv is ignored if Test_load_type is |* Single-ended. | |* If Test_load_type is Differential, then the test load is a |* pair of the above circuits. If the R_diff_near or R_diff_far |* subparameter is used, a resistor is connected between the |* near or far nodes of the two circuits. If Test_load_type is |* Single_ended, R_diff_near and R_diff_far are ignored. | |----------------------------------------------------------------------------- | [Test Load] Load1 Test_load_type Single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff_far = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 | |----------------------------------------------------------------------------- ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1/70.2: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Waveform Near/Far]. Changed [Falling Waveform] to [Falling Waveform Near/Far]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the Vx_rise/fall subparameters to indicate the end of a timing interval for timing correlation. 6. Added Tmeas_rise/fall to facilitate timing correlation. 7. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 8. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 9. Moved Driver_model and Test_load under the scope of [Test Data]. 10. R_diff became R_diff_near and R_diff_far. 11. Removed timing-related keywords: Tmeas_rise, Tmeas_fall, Vx_rise, Vx_fall This function can be achieved with less complexity by including a Golden Waveform that represents the standard (timing) test load. 12. Added four differential waveform keywords. Changes between BIRD 70.3 and BIRD 70.4 (see lines beginning with |* ): 1. Added subparameter Driver_model_inv under [Test Data]. 2. Added subparameter Receiver_model_inv under [Test Load]. 3. Added language defining the legal values of Test_data_type. 4. Made Test_load_type a required subparameter. 5. Made Vterm subparameters required if the corresponding resistors are used. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. ****************************************************************************** Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Mon Jul 23 18:36:07 2001 Received: from smtp.huawei.com ([202.96.135.132]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6O1Zl7n013124; Mon, 23 Jul 2001 18:35:49 -0700 (PDT) Received: from l17274b ([10.11.24.20]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GGYETA03.B0S; Tue, 24 Jul 2001 09:29:34 +0800 Message-ID: <00c001c113e1$4b671260$14180b0a@huawei.com> From: "LiuWeidong" To: "Gregory R Edlund" Cc: , References: Subject: about the IBIS "checklist.txt." Date: Tue, 24 Jul 2001 09:38:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by server.eda.org id f6O1cX7n013125 Hello, Greg I have some questions about your IBIS Datasheet Checklist : "3. Has the modeling engineer performed a visual inspection of IV and VT curves to screen for non-monotonicity, discontinuities, and other obvious errors?" If a IV curves is non-monotonicity,How can I deal with it ? Can the model be uesd by the simulation tools? There are so many IBIS models provided by IC venders whose IV curves is non-monotonicity . "8. Does the output reach Vmeas under standard load conditions for rising and falling waveforms?" For this item , I don't think it should be in the IBIS Datasheet Checklist , Whether the output can reach Vmeas under standard load conditions for rising and falling waveforms mainly depend on the output buffer's driving capability . If a buffer's driving capability is very weak, the output maybe can't reach Vmeas under standard load conditions for rising and falling waveforms,but you can't think the IBIS model is wrong. Hope for your reply! Thanks! LiuWeidong ----- Original Message ----- From: Gregory R Edlund To: Cc: Sent: Thursday, May 24, 2001 8:53 PM Subject: Re: Clarification needed. > > Anbazhagan, > > Looks like you're on the right track. I would recommend your ASIC vendor > read the "IBIS Cookbook," which can be found on the IBIS web page: > http://www.eigroup.org/ibis/tools.htm > > As part of the "I/O Buffer Accuracy Handbook" (also available on the IBIS > web page), we published a checklist that should help you. This list was > compiled from suggestions by members of the SI community who have > experience with IBIS. I am attaching the most recent version of this list. > > Bob, Could you please post this list as an ASCII text file under Accuracy? > Pleas name it "checklist.txt." Thanks. > > > IBIS Datasheet Checklist version 1.1, > 05/07/01 > ------------------------ > > > IBIS datasheet: > Component manufacturer: > Component part number: > Engineer verifying this component: > Email address: > Behavioral simulator and version: > Date: > > > Note: If answer is N or N/A, provide explanation. > The user may verify items 1-9 but is unable to verify items 10-20 > because the data involved are only available to the semiconductor > vendor. > > > ___ 1. Does the IBIS datasheet pass the IBIS syntax checker? > (Note: Some models generate warnings for non-monotonicities that > are > actually part of the characteristics of the device. Other non- > monotonicities are so small as to be irrelevant.) > > ___ 2. Is an "I/O Buffer Accuracy Report" available for this component? > (http://www.vhdl.org/pub/ibis/accuracy) > > ___ 3. Has the modeling engineer performed a visual inspection of IV and > VT > curves to screen for non-monotonicity, discontinuities, and other > obvious errors? > > ___ 4. Has the modeling engineer tested the IBIS datasheet using a > behavioral > simulator? > > ___ 5. Do MIN and MAX data exist for all keywords and sub-parameters? > > ___ 6. Does the IBIS datasheet include all four 50 Ohm VT tables as > described > in the IBIS Cookbook? > > ___ 7. Do the keywords Cref, Rref, Vref, and Vmeas match the values > specified > in the component datasheet for all output and bidirectional models? > > ___ 8. Does the output reach Vmeas under standard load conditions for > rising > and falling waveforms? > > ___ 9. Does the pin table match the component datasheet? > > > ___ 10. Do the keywords Vihl and Vinh represent the unity gain points > derived > from the dc transfer characteristics for all inputs? > > ___ 11. Has the modeling engineer verified the accuracy of the C_comp > subparameter? > > ___ 12. Has the modeling engineer verified the accuracy of the R_pkg, > L_pkg, > and C_pkg subparameters? > > ___ 13. For CMOS logic, do all MAX data represent maximum voltage, minimum > temperature, and fast process? > > ___ 14. For CMOS logic, do all MIN data represent minimum voltage, maximum > temperature, and slow process? > > ___ 15. For bipolar logic, do all MAX data represent maximum voltage, > maximum > temperature, and fast process? > > ___ 16. For bipolar logic, do all MIN data represent minimum voltage, > minimum > temperature, and slow process? > > ___ 17. Do the keywords dV/dt_r and dV/dt_f contain the correct 20%-80% > edge > rate data measured using a 50 & load as specified in IBIS? > > ___ 18. If the I/O buffer employs dynamic clamping, does the IBIS datasheet > contain the appropriate keywords and subparameters? > > ___ 19. If the I/O buffer employs a multi-stage driver, does the IBIS > datasheet > contain the appropriate keywords and subparameters? > > ___ 20. If the I/O buffer design employs dynamic edge rate control, dynamic > impedance control, or any form of feedback, has the modeling > engineer > assessed the impact of this circuitry on behavioral model accuracy? > > > Greg Edlund > Electrical Packaging > IBM Server Technology Development > 3605 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > > Anbu@scmmicro.co.in on 05/24/2001 01:48:13 AM > > To: "ibis-users@eda.org": > cc: > Subject: Clarification needed. > > > > Hello Users, > > I am using XTK to simulate a PCBA. The board has a 100pin ASIC. In > order to model the ASIC properly I need the IBIS model of the ASIC which I > can convert it to XTK format. Now if I directly request for an IBIS model > the vendor may hesistate. So I am requesting the following data from the > vendor with which I can create a IBIS model. Below is the data I am > requesting them. Is it OK. Does it cover everything necessary to create a > proper IBIS model?. The ASIC does not have any clamp diodes. Please reply. > The following data whichever is applicable for each pin of the ASIC are > needed > 1. Package parasitics namely, the Resistance, capacitance and Inductance. > Typical, max, min values required. > > 2. Die capacitance as seen at the die pad. Typical, max, min values > required > > 3. Output impedance of the I/O buffers. Typical, max, min values required. > > 4. Rise time and fall time values (dv/dt typical, max, min) of buffers > excluding the effect of packaging but including the effect of die > capacitance. Load conditions required. > > 6. Rising edge and falling edge waveforms (Voltage vs. time curve with the > voltage values having typical, max, min values) of the driver along with > the test conditions. > > 5. V/I characteristics of Pull up and Pull down resistor, if present, when > the buffer is driven high and low respectively. The voltage sweep must be > from ?3.3V to +6.6V. Current measurement with typical, max, min values are > required. > > Thanks, > > Anbazhagan. > > > > > > Test - Please ignore Subject: Test - Please ignore From: Steve Grout (grouts@flash.net) Date: Tue Jul 24 2001 - 10:51:51 PDT Next message: Adam.Tambone@fairchildsemi.com: "Vod and Differential Models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This is a test of the new ibis@eda.org list. Please ignore. --majordom@eda.org -- --Steve Grout CAD Methodologist, Architect, Manager, Individual Contributor - CAD System, Database, Flows, Tools, Integration, and Support for both digital and Analog/Mixed-Signal. 101 Kenneil Court Apex, NC 27502 Phone: 919-303-5066 email: grouts@flash.net http://www.flash.net/~sgrout/Personal/resume2001.txt (or doc,rtf,pdf) Next message: Adam.Tambone@fairchildsemi.com: "Vod and Differential Models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 24 2001 - 10:52:39 PDT Vod and Differential Models Subject: Vod and Differential Models From: Adam.Tambone@fairchildsemi.com Date: Tue Jul 24 2001 - 12:40:33 PDT Next message: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" Previous message: Steve Grout: "Test - Please ignore" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hello IBIS Gurus, I am attempting to understand the following problem. Simulating the below differential network in HSPICE, with IBIS models for driver and receiver, and lossless t-element t-lines, Vod is too small. As opposed to this, simulating the same differential network in HSPICE, with the HSPICE netlists of the driver and receiver, Vod is correct. I am expecting to have a Vod of about 350mV. Can anyone explain this discrepancy? SIMULATION CONDITIONS |\---------O=====O---------|---------------------|\ | \ Zo = 50 \ | \ | \ / Rterm = 100 | \ | / \ | / |/O-------O=====O---------|-------------------O|/ Zo = 50 DRVR RCVR SPICE TO IBIS CONDITIONS FOR OUTPUT BUFFER EXTRACTION _________ + Vfix - __ GND | Rfix = 1MEG | |\-------------| | \ R1 = 50 | \ |------------------ | + | / R2 = 50 Vos = 1.25V |/O----------| | - GND DRVR Thank You, Adam Tambone (See attached file: fin1017m.ibs) | [IBIS Ver] 3.2 | [Comment Char] |_char | [File name] fin1017m.ibs | [File Rev] 1.0 | [Date] 27-Feb-01 10:47:24 AM | [Source] SPICE to IBIS Translation | [Notes] Created by Adam Tambone Modeling Support Engineer | [Disclaimer] Fairchild Semiconductor Corporation hereby grants the user of this IBIS model a non-exclusive, nontransferable license to use this IBIS model under the following terms. Before using this IBIS model, the user should read this license. If the user does not accept these terms, the IBIS model should be returned to Fairchild within 30 days. The user is granted this license only to use the IBIS model and is not granted rights to sell, load, rent, lease or license the IBIS model in whole or in part, or in modified form to anyone other than user. User may modify the IBIS model to suit its specific applications but rights to derivative works and such modifications shall belong to Fairchild. This IBIS model is provided on an "AS IS" basis and Fairchild makes absolutely no warranty with respect to the information contained herein. Fairchild DISCLAIMS AND CUSTOMER WAIVES ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The entire risk as to quality and performance is with the Customer. ACCORDINGLY, IN NO EVENT SHALL THE COMPANY BE LIABLE FOR ANY DAMAGES, WHETHER IN CONTRF OR TORT, INCLUDING ANY LOST PROFITS OR OTHER INCIDENTAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES ARISING OUT OF THE USE OR APPLICATION OF THE IBIS model provided in this package. Further, Fairchild reserves the right to make changes without notice to any product herein to improve reliability, function, or design. Fairchild does not convey any license under patent rights or any other intellectual property rights, including those of third parties. Fairchild is not obligated to provide maintenance or support for the licensed IBIS model. ContF Fairchild at ATTN:LOGIC APPLICATIONS/IBIS MODEF. 333 Western Avenue, M/S 10-26, South Portland, ME 04106 IBIS Open Forum disclaims all warranties. See DISCLAIM.TXT in vhdl.org:/pub/IBIS/modeF for the full disclaimer. | [Copyright] (c) Copyright 2001 Fairchild Semiconductor Corp | [Component] FIN1017M Si_location Pin Timing_location Pin | [Manufacturer] Fairchild Semiconductor Corp. | [Package] R_pkg 80m 80m 80m L_pkg 2.3n 2.3n 2.74n C_pkg 0.06p 0.06p 0.08p | [Pin] signal_name model_name R_pin L_pin C_pin 1 vcc POWER 80m 2.74n 0.08p 2 din data_i 80m 2.30n 0.06p 3 nc NC 80m 2.30n 0.06p 4 gnd GND 80m 2.74n 0.08p 5 nc NC 80m 2.74n 0.08p 6 nc NC 80m 2.30n 0.06p 7 dop data_o_p 80m 2.30n 0.06p 8 don data_o_n 80m 2.74n 0.08p | [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max 7 8 0 0.7n 0.4n 1.0n | [Model] data_i Model_type Input Vinh=2.0 Vinl=0.8 C_comp 3p NA NA | [Temperature Range] 25 85 -40 | [Voltage Range] 3.3 3.0 3.6 | [GND Clamp] -3.300000E+0 -9.934287E+0 -1.023528E+1 -9.732255E+0 -3.200000E+0 -9.528838E+0 -9.829916E+0 -9.321117E+0 -3.100000E+0 -9.123705E+0 -9.424791E+0 -8.910539E+0 -3.000000E+0 -8.718904E+0 -9.019920E+0 -8.500532E+0 -2.900000E+0 -8.314451E+0 -8.615322E+0 -8.091109E+0 -2.800000E+0 -7.910367E+0 -8.211022E+0 -7.682287E+0 -2.700000E+0 -7.506674E+0 -7.807046E+0 -7.274084E+0 -2.600000E+0 -7.103400E+0 -7.403424E+0 -6.866521E+0 -2.500000E+0 -6.700576E+0 -7.000193E+0 -6.459625E+0 -2.400000E+0 -6.298240E+0 -6.597396E+0 -6.053427E+0 -2.300000E+0 -5.896438E+0 -6.195082E+0 -5.647966E+0 -2.200000E+0 -5.495225E+0 -5.793311E+0 -5.243289E+0 -2.100000E+0 -5.094669E+0 -5.392156E+0 -4.839455E+0 -2.000000E+0 -4.694854E+0 -4.991707E+0 -4.436540E+0 -1.900000E+0 -4.295887E+0 -4.592074E+0 -4.034641E+0 -1.800000E+0 -3.897906E+0 -4.193397E+0 -3.633889E+0 -1.700000E+0 -3.501093E+0 -3.795857E+0 -3.234457E+0 -1.600000E+0 -3.105692E+0 -3.399691E+0 -2.836593E+0 -1.500000E+0 -2.712046E+0 -3.005220E+0 -2.440653E+0 -1.400000E+0 -2.320651E+0 -2.612895E+0 -2.047179E+0 -1.300000E+0 -1.932263E+0 -2.223369E+0 -1.657056E+0 -1.200000E+0 -1.548114E+0 -1.837649E+0 -1.271898E+0 -1.100000E+0 -1.170465E+0 -1.457421E+0 -8.948849E-1 -1.000000E+0 -8.037860E-1 -1.085643E+0 -5.342155E-1 -9.000000E-1 -4.595655E-1 -7.285481E-1 -2.204848E-1 -8.000000E-1 -1.769097E-1 -4.018428E-1 -6.538411E-2 -7.000000E-1 -4.273490E-2 -1.527834E-1 -3.059413E-2 -6.000000E-1 -6.584382E-3 -3.977667E-2 -1.417659E-2 -5.000000E-1 -9.526321E-4 -4.382680E-3 -3.644695E-3 -4.000000E-1 -8.345309E-5 -2.172766E-4 -3.004191E-4 -3.000000E-1 -5.103542E-6 -1.045065E-5 -9.730543E-6 -2.000000E-1 -4.333785E-7 -6.295482E-7 -6.766601E-7 -1.000000E-1 -1.253865E-7 -8.769792E-8 -2.672782E-7 4.440892E-16 -1.420895E-10 -4.553402E-10 -2.484108E-11 1.000000E-1 1.190589E-7 6.402011E-8 2.655356E-7 2.000000E-1 2.380983E-7 1.278778E-7 5.310803E-7 3.000000E-1 3.571343E-7 1.917097E-7 7.966250E-7 4.000000E-1 4.761701E-7 2.555397E-7 1.062170E-6 5.000000E-1 5.952061E-7 3.193695E-7 1.327714E-6 6.000000E-1 7.142421E-7 3.831989E-7 1.593259E-6 7.000000E-1 8.332780E-7 4.470288E-7 1.858804E-6 8.000000E-1 9.523139E-7 5.108586E-7 2.124348E-6 9.000000E-1 1.071350E-6 5.746883E-7 2.389893E-6 1.000000E+0 1.190386E-6 6.385179E-7 2.655438E-6 1.100000E+0 1.309420E-6 7.023441E-7 2.920981E-6 1.200000E+0 1.428431E-6 7.661232E-7 3.186512E-6 1.300000E+0 1.547052E-6 8.283195E-7 3.451890E-6 1.400000E+0 1.650101E-6 -5.983113E-7 3.714542E-6 1.500000E+0 -8.416844E-7 -6.846680E-6 3.829374E-6 1.600000E+0 -1.137461E-5 -7.545112E-6 -1.731979E-6 1.700000E+0 -1.258140E-5 -7.669762E-6 -1.898425E-5 1.800000E+0 -1.283199E-5 -7.511168E-6 -2.025927E-5 1.900000E+0 -1.266295E-5 -7.091525E-6 -2.031666E-5 2.000000E+0 -1.222493E-5 -9.460492E-7 -1.985802E-5 2.100000E+0 -1.157340E-5 1.166857E-6 -1.907527E-5 2.200000E+0 -1.063259E-5 1.394419E-6 -1.805195E-5 2.300000E+0 -6.570686E-7 1.467768E-6 -1.682954E-5 2.400000E+0 2.682059E-6 1.532089E-6 -1.541908E-5 2.500000E+0 2.970373E-6 1.595947E-6 -1.371469E-5 2.600000E+0 3.094819E-6 1.659780E-6 7.631993E-7 2.700000E+0 3.214006E-6 1.723614E-6 6.976843E-6 2.800000E+0 3.333048E-6 1.787449E-6 7.432874E-6 2.900000E+0 3.452087E-6 1.851285E-6 7.700764E-6 3.000000E+0 3.571127E-6 1.915124E-6 7.966331E-6 3.100000E+0 3.690167E-6 1.978964E-6 8.231877E-6 3.200000E+0 3.809208E-6 2.042806E-6 8.497422E-6 3.300000E+0 3.928249E-6 2.106651E-6 8.762967E-6 | [POWER Clamp] 0.0 3.928249E-6 1.915124E-6 9.559603E-6 -1.000000E-1 4.047292E-6 1.978964E-6 9.825149E-6 -2.000000E-1 4.166336E-6 2.042806E-6 1.009069E-5 -3.000000E-1 4.285380E-6 2.106651E-6 1.035624E-5 -4.000000E-1 4.404426E-6 2.170499E-6 1.062179E-5 -5.000000E-1 4.523474E-6 2.234350E-6 1.088733E-5 -6.000000E-1 4.642525E-6 2.298205E-6 1.115288E-5 -7.000000E-1 4.761577E-6 2.362065E-6 1.141843E-5 -8.000000E-1 4.880629E-6 2.425928E-6 1.168398E-5 -9.000000E-1 4.999687E-6 2.489799E-6 1.194952E-5 -1.000000E+0 5.118746E-6 2.553672E-6 1.221507E-5 -1.100000E+0 5.237808E-6 2.617553E-6 1.248062E-5 -1.200000E+0 5.356872E-6 2.681443E-6 1.274617E-5 -1.300000E+0 5.475940E-6 2.745339E-6 1.301172E-5 -1.400000E+0 5.595014E-6 2.809243E-6 1.327727E-5 -1.500000E+0 5.714088E-6 2.873156E-6 1.354282E-5 -1.600000E+0 5.833169E-6 2.937079E-6 1.380837E-5 -1.700000E+0 5.952254E-6 3.001013E-6 1.407392E-5 -1.800000E+0 6.071342E-6 3.064958E-6 1.433948E-5 -1.900000E+0 6.190437E-6 3.128915E-6 1.460503E-5 -2.000000E+0 6.309539E-6 3.192885E-6 1.487059E-5 -2.100000E+0 6.428644E-6 3.256867E-6 1.513614E-5 -2.200000E+0 6.547758E-6 3.320866E-6 1.540170E-5 -2.300000E+0 6.666877E-6 3.384879E-6 1.566726E-5 -2.400000E+0 6.786005E-6 3.448908E-6 1.593282E-5 -2.500000E+0 6.905138E-6 3.512957E-6 1.619838E-5 -2.600000E+0 7.024282E-6 3.577020E-6 1.646394E-5 -2.700000E+0 7.143435E-6 3.641105E-6 1.672950E-5 -2.800000E+0 7.262594E-6 3.705210E-6 1.699507E-5 -2.900000E+0 7.381765E-6 3.769337E-6 1.726064E-5 -3.000000E+0 7.500946E-6 3.833487E-6 1.752621E-5 -3.100000E+0 7.620138E-6 3.897659E-6 1.779178E-5 -3.200000E+0 7.739340E-6 3.961857E-6 1.805735E-5 -3.300000E+0 7.858556E-6 4.026081E-6 1.832293E-5 | |[End data_i | |====================================================================== | [Model] data_o_n Model_type Output Polarity Inverting Vref=1.25 Vmeas=1.25 Rref=100 Cref=10p C_comp 4p NA NA | [Temperature Range] 25 85 -40 | [Voltage Range] 3.3 3.0 3.6 | [Pullup] -3.300000E+0 1.476755E-1 1.350986E-1 1.616679E-1 -3.200000E+0 1.444219E-1 1.320865E-1 1.580780E-1 -3.100000E+0 1.411505E-1 1.290463E-1 1.544784E-1 -3.000000E+0 1.378616E-1 1.259830E-1 1.508687E-1 -2.900000E+0 1.345552E-1 1.228988E-1 1.472480E-1 -2.800000E+0 1.312315E-1 1.197952E-1 1.436156E-1 -2.700000E+0 1.278906E-1 1.166737E-1 1.399705E-1 -2.600000E+0 1.245327E-1 1.135355E-1 1.363119E-1 -2.500000E+0 1.211580E-1 1.103818E-1 1.326390E-1 -2.400000E+0 1.177668E-1 1.072138E-1 1.289514E-1 -2.300000E+0 1.143596E-1 1.040324E-1 1.252486E-1 -2.200000E+0 1.109367E-1 1.008387E-1 1.215306E-1 -2.100000E+0 1.074990E-1 9.763377E-2 1.177978E-1 -2.000000E+0 1.040473E-1 9.441875E-2 1.140507E-1 -1.900000E+0 1.005826E-1 9.119485E-2 1.102907E-1 -1.800000E+0 9.710639E-2 8.796339E-2 1.065197E-1 -1.700000E+0 9.362022E-2 8.472589E-2 1.027407E-1 -1.600000E+0 9.012668E-2 8.148445E-2 9.895863E-2 -1.500000E+0 8.663034E-2 7.824237E-2 9.518258E-2 -1.400000E+0 8.313779E-2 7.500458E-2 9.142290E-2 -1.300000E+0 7.965216E-2 7.177552E-2 8.768826E-2 -1.200000E+0 7.617193E-2 6.855550E-2 8.402147E-2 -1.100000E+0 7.270544E-2 6.534425E-2 8.055223E-2 -1.000000E+0 6.928131E-2 6.214707E-2 7.735067E-2 -9.000000E-1 6.597988E-2 5.897696E-2 7.426780E-2 -8.000000E-1 6.292715E-2 5.586161E-2 7.125560E-2 -7.000000E-1 6.009863E-2 5.286156E-2 6.841420E-2 -6.000000E-1 5.739812E-2 5.006133E-2 6.576988E-2 -5.000000E-1 5.486687E-2 4.746312E-2 6.315061E-2 -4.000000E-1 5.239416E-2 4.501689E-2 6.054053E-2 -3.000000E-1 4.993493E-2 4.265094E-2 5.794087E-2 -2.000000E-1 4.748898E-2 4.030510E-2 5.535378E-2 -1.000000E-1 4.505814E-2 3.797364E-2 5.278176E-2 0.0 4.264448E-2 3.565768E-2 5.022773E-2 10.000000E-2 4.025022E-2 3.335826E-2 4.769625E-2 2.000000E-1 3.787625E-2 3.107550E-2 4.518991E-2 3.000000E-1 3.552283E-2 2.880949E-2 4.270933E-2 4.000000E-1 3.319022E-2 2.656031E-2 4.025514E-2 5.000000E-1 3.087861E-2 2.432798E-2 3.782795E-2 6.000000E-1 2.858812E-2 2.211243E-2 3.542835E-2 7.000000E-1 2.631874E-2 1.991349E-2 3.305684E-2 8.000000E-1 2.407022E-2 1.773074E-2 3.071380E-2 9.000000E-1 2.184190E-2 1.556331E-2 2.839936E-2 1.000000E+0 1.963236E-2 1.340929E-2 2.611325E-2 1.100000E+0 1.743852E-2 1.126428E-2 2.385451E-2 1.200000E+0 1.525405E-2 9.121202E-3 2.162082E-2 1.300000E+0 1.306922E-2 6.974465E-3 1.940706E-2 1.400000E+0 1.087653E-2 4.821182E-3 1.720225E-2 1.500000E+0 8.672541E-3 2.659266E-3 1.498782E-2 1.600000E+0 6.454487E-3 4.867326E-4 1.274924E-2 1.700000E+0 4.219180E-3 -1.698230E-3 1.048447E-2 1.800000E+0 1.963060E-3 -3.894882E-3 8.191658E-3 1.900000E+0 -3.175515E-4 -6.095141E-3 5.865089E-3 2.000000E+0 -2.625268E-3 -8.300989E-3 3.497874E-3 2.100000E+0 -4.954666E-3 -1.051033E-2 1.084157E-3 2.200000E+0 -7.287749E-3 -1.269953E-2 -1.379835E-3 2.300000E+0 -9.621159E-3 -1.486620E-2 -3.890409E-3 2.400000E+0 -1.193498E-2 -1.702862E-2 -6.433814E-3 2.500000E+0 -1.418566E-2 -1.919091E-2 -8.974481E-3 2.600000E+0 -1.641681E-2 -2.135414E-2 -1.147860E-2 2.700000E+0 -1.864441E-2 -2.351877E-2 -1.385088E-2 2.800000E+0 -2.087185E-2 -2.568487E-2 -1.617092E-2 2.900000E+0 -2.309845E-2 -2.785228E-2 -1.848008E-2 3.000000E+0 -2.532455E-2 -3.002067E-2 -2.078584E-2 3.100000E+0 -2.755032E-2 -3.218835E-2 -2.309078E-2 3.200000E+0 -2.977575E-2 -3.435409E-2 -2.539330E-2 3.300000E+0 -3.200075E-2 -3.652282E-2 -2.769166E-2 3.400000E+0 -3.422338E-2 -3.879235E-2 -2.998629E-2 3.500000E+0 -3.644141E-2 -4.334025E-2 -3.227747E-2 3.600000E+0 -3.865591E-2 -7.398447E-2 -3.456545E-2 3.700000E+0 -4.088533E-2 -1.599911E-1 -3.684830E-2 3.800000E+0 -4.335358E-2 -2.753006E-1 -3.912335E-2 3.900000E+0 -4.797115E-2 -4.021089E-1 -4.139176E-2 4.000000E+0 -7.720957E-2 -5.344914E-1 -4.369829E-2 4.100000E+0 -1.678474E-1 -6.700802E-1 -4.672887E-2 4.200000E+0 -2.876836E-1 -8.077288E-1 -5.220226E-2 4.300000E+0 -4.177168E-1 -9.468019E-1 -6.002976E-2 4.400000E+0 -5.525010E-1 -1.086920E+0 -8.198781E-2 4.500000E+0 -6.899736E-1 -1.227833E+0 -1.716783E-1 4.600000E+0 -8.291564E-1 -1.369368E+0 -2.949799E-1 4.700000E+0 -9.695243E-1 -1.511405E+0 -4.278904E-1 4.800000E+0 -1.110753E+0 -1.653855E+0 -5.649286E-1 4.900000E+0 -1.252635E+0 -1.796649E+0 -7.042164E-1 5.000000E+0 -1.395030E+0 -1.939737E+0 -8.449056E-1 5.100000E+0 -1.537838E+0 -2.083076E+0 -9.865536E-1 5.200000E+0 -1.680986E+0 -2.226632E+0 -1.128891E+0 5.300000E+0 -1.824417E+0 -2.370380E+0 -1.271751E+0 5.400000E+0 -1.968088E+0 -2.514296E+0 -1.415017E+0 5.500000E+0 -2.111966E+0 -2.658361E+0 -1.558610E+0 5.600000E+0 -2.256023E+0 -2.802561E+0 -1.702470E+0 5.700000E+0 -2.400237E+0 -2.946882E+0 -1.846553E+0 5.800000E+0 -2.544589E+0 -3.091311E+0 -1.990825E+0 5.900000E+0 -2.689063E+0 -3.235840E+0 -2.135258E+0 6.000000E+0 -2.833648E+0 -3.380459E+0 -2.279832E+0 6.100000E+0 -2.978332E+0 -3.525161E+0 -2.424528E+0 6.200000E+0 -3.123105E+0 -3.669939E+0 -2.569332E+0 6.300000E+0 -3.267960E+0 -3.814787E+0 -2.714232E+0 6.400000E+0 -3.412888E+0 -3.959701E+0 -2.859218E+0 6.500000E+0 -3.557885E+0 -4.104675E+0 -3.004281E+0 6.600000E+0 -3.702944E+0 -4.249706E+0 -3.149413E+0 | [Pulldown] -3.300000E+0 -3.698061E+0 -3.810786E+0 -3.579796E+0 -3.200000E+0 -3.552989E+0 -3.665950E+0 -3.434414E+0 -3.100000E+0 -3.407983E+0 -3.521187E+0 -3.289084E+0 -3.000000E+0 -3.263048E+0 -3.376504E+0 -3.143812E+0 -2.900000E+0 -3.118192E+0 -3.231906E+0 -2.998605E+0 -2.800000E+0 -2.973422E+0 -3.087402E+0 -2.853469E+0 -2.700000E+0 -2.828747E+0 -2.943001E+0 -2.708415E+0 -2.600000E+0 -2.684177E+0 -2.798714E+0 -2.563452E+0 -2.500000E+0 -2.539725E+0 -2.654552E+0 -2.418594E+0 -2.400000E+0 -2.395404E+0 -2.510530E+0 -2.273857E+0 -2.300000E+0 -2.251233E+0 -2.366664E+0 -2.129260E+0 -2.200000E+0 -2.107232E+0 -2.222972E+0 -1.984830E+0 -2.100000E+0 -1.963421E+0 -2.079477E+0 -1.840593E+0 -2.000000E+0 -1.819828E+0 -1.936204E+0 -1.696578E+0 -1.900000E+0 -1.676481E+0 -1.793185E+0 -1.552809E+0 -1.800000E+0 -1.533423E+0 -1.650460E+0 -1.409321E+0 -1.700000E+0 -1.390707E+0 -1.508081E+0 -1.266167E+0 -1.600000E+0 -1.248407E+0 -1.366116E+0 -1.123425E+0 -1.500000E+0 -1.106623E+0 -1.224655E+0 -9.812117E-1 -1.400000E+0 -9.654988E-1 -1.083820E+0 -8.396967E-1 -1.300000E+0 -8.252414E-1 -9.437818E-1 -6.991496E-1 -1.200000E+0 -6.861746E-1 -8.047905E-1 -5.600376E-1 -1.100000E+0 -5.488488E-1 -6.672391E-1 -4.232195E-1 -1.000000E+0 -4.142451E-1 -5.317588E-1 -2.906552E-1 -9.000000E-1 -2.844885E-1 -3.995141E-1 -1.681700E-1 -8.000000E-1 -1.652378E-1 -2.729117E-1 -8.131732E-2 -7.000000E-1 -7.616260E-2 -1.580022E-1 -6.015832E-2 -6.000000E-1 -4.753894E-2 -7.283480E-2 -5.186681E-2 -5.000000E-1 -4.248580E-2 -4.245063E-2 -4.581935E-2 -4.000000E-1 -3.950116E-2 -3.755813E-2 -4.212245E-2 -3.000000E-1 -3.674356E-2 -3.490178E-2 -3.911474E-2 -2.000000E-1 -3.399880E-2 -3.234762E-2 -3.613265E-2 -1.000000E-1 -3.125176E-2 -2.980139E-2 -3.313487E-2 4.440892E-16 -2.850398E-2 -2.726083E-2 -3.012260E-2 1.000000E-1 -2.577196E-2 -2.473566E-2 -2.712446E-2 2.000000E-1 -2.306814E-2 -2.223349E-2 -2.416159E-2 3.000000E-1 -2.039181E-2 -1.975416E-2 -2.123240E-2 4.000000E-1 -1.774144E-2 -1.729710E-2 -1.833317E-2 5.000000E-1 -1.511314E-2 -1.486092E-2 -1.545005E-2 6.000000E-1 -1.249060E-2 -1.244157E-2 -1.252234E-2 7.000000E-1 -9.837446E-3 -1.002223E-2 -9.583548E-3 8.000000E-1 -7.198958E-3 -7.599533E-3 -6.671578E-3 9.000000E-1 -4.590173E-3 -5.202889E-3 -3.784346E-3 1.000000E+0 -2.005939E-3 -2.835867E-3 -9.102519E-4 1.100000E+0 5.559515E-4 -4.946313E-4 1.945838E-3 1.200000E+0 3.090112E-3 1.816986E-3 4.781088E-3 1.300000E+0 5.589615E-3 4.095095E-3 7.583665E-3 1.400000E+0 8.027689E-3 6.331540E-3 1.028539E-2 1.500000E+0 1.040329E-2 8.526347E-3 1.287814E-2 1.600000E+0 1.271943E-2 1.068097E-2 1.536947E-2 1.700000E+0 1.497896E-2 1.279715E-2 1.777255E-2 1.800000E+0 1.718447E-2 1.487826E-2 2.010168E-2 1.900000E+0 1.933920E-2 1.693032E-2 2.236753E-2 2.000000E+0 2.144891E-2 1.896192E-2 2.457625E-2 2.100000E+0 2.352119E-2 2.098220E-2 2.672993E-2 2.200000E+0 2.556607E-2 2.299679E-2 2.882986E-2 2.300000E+0 2.759496E-2 2.500824E-2 3.088795E-2 2.400000E+0 2.961538E-2 2.701778E-2 3.292264E-2 2.500000E+0 3.163111E-2 2.902606E-2 3.494569E-2 2.600000E+0 3.364401E-2 3.103346E-2 3.696262E-2 2.700000E+0 3.565508E-2 3.304022E-2 3.897606E-2 2.800000E+0 3.766490E-2 3.504650E-2 4.098735E-2 2.900000E+0 3.967383E-2 3.705242E-2 4.299721E-2 3.000000E+0 4.168209E-2 3.905805E-2 4.500610E-2 3.100000E+0 4.368985E-2 4.106345E-2 4.701428E-2 3.200000E+0 4.569722E-2 4.306867E-2 4.902194E-2 3.300000E+0 4.770427E-2 4.507408E-2 5.102920E-2 3.400000E+0 4.971108E-2 4.708673E-2 5.303615E-2 3.500000E+0 5.171768E-2 4.916676E-2 5.504285E-2 3.600000E+0 5.372412E-2 5.135204E-2 5.704936E-2 3.700000E+0 5.573068E-2 5.360231E-2 5.905571E-2 3.800000E+0 5.774099E-2 5.593125E-2 6.106194E-2 3.900000E+0 5.981686E-2 5.837007E-2 6.306808E-2 4.000000E+0 6.210715E-2 6.091385E-2 6.507432E-2 4.100000E+0 6.459403E-2 6.353272E-2 6.708279E-2 4.200000E+0 6.724162E-2 6.620304E-2 6.911667E-2 4.300000E+0 6.999773E-2 6.891382E-2 7.129658E-2 4.400000E+0 7.282534E-2 7.165855E-2 7.387854E-2 4.500000E+0 7.570763E-2 7.442620E-2 7.675349E-2 4.600000E+0 7.863746E-2 7.720601E-2 7.976082E-2 4.700000E+0 8.161177E-2 7.999326E-2 8.285384E-2 4.800000E+0 8.462200E-2 8.278580E-2 8.601138E-2 4.900000E+0 8.764917E-2 8.558131E-2 8.921939E-2 5.000000E+0 9.068138E-2 8.837726E-2 9.246840E-2 5.100000E+0 9.371488E-2 9.117116E-2 9.575522E-2 5.200000E+0 9.674706E-2 9.396082E-2 9.906612E-2 5.300000E+0 9.977532E-2 9.674427E-2 1.023736E-1 5.400000E+0 1.027975E-1 9.951970E-2 1.056668E-1 5.500000E+0 1.058118E-1 1.022854E-1 1.089448E-1 5.600000E+0 1.088170E-1 1.050394E-1 1.122073E-1 5.700000E+0 1.118124E-1 1.077798E-1 1.154545E-1 5.800000E+0 1.147972E-1 1.105042E-1 1.186865E-1 5.900000E+0 1.177710E-1 1.132097E-1 1.219043E-1 6.000000E+0 1.207332E-1 1.158930E-1 1.251085E-1 6.100000E+0 1.236836E-1 1.185501E-1 1.283001E-1 6.200000E+0 1.266218E-1 1.211731E-1 1.314798E-1 6.300000E+0 1.295480E-1 1.237459E-1 1.346482E-1 6.400000E+0 1.324631E-1 1.262376E-1 1.378059E-1 6.500000E+0 1.353697E-1 1.285807E-1 1.409532E-1 6.600000E+0 1.382709E-1 1.305392E-1 1.440908E-1 | [Ramp] dV/dt_r 1.031E-1/3.059E-10 7.795E-2/4.400E-10 1.325E-1/2.217E-10 dV/dt_f 1.223E-1/2.429E-10 7.849E-2/3.774E-10 1.736E-1/1.512E-10 | [Falling Waveform] R_fixture=100 V_fixture=0 V_fixture_min=0 V_fixture_max=0 0.0 1.413793E+0 1.377608E+0 1.455685E+0 5.050505E-11 1.413800E+0 1.377618E+0 1.455688E+0 1.010101E-10 1.413785E+0 1.377610E+0 1.455672E+0 1.515152E-10 1.413775E+0 1.377597E+0 1.455668E+0 2.020202E-10 1.413772E+0 1.377589E+0 1.455666E+0 2.525253E-10 1.413769E+0 1.377584E+0 1.455672E+0 3.030303E-10 1.413770E+0 1.377581E+0 1.455705E+0 3.535354E-10 1.413785E+0 1.377577E+0 1.455755E+0 4.040404E-10 1.413824E+0 1.377581E+0 1.455813E+0 4.545455E-10 1.413869E+0 1.377596E+0 1.455819E+0 5.050505E-10 1.413915E+0 1.377623E+0 1.455749E+0 5.555556E-10 1.413973E+0 1.377663E+0 1.455650E+0 6.060606E-10 1.414168E+0 1.377707E+0 1.453460E+0 6.565657E-10 1.414707E+0 1.377766E+0 1.433244E+0 7.070707E-10 1.413310E+0 1.377919E+0 1.386434E+0 7.575758E-10 1.397963E+0 1.378214E+0 1.336202E+0 8.080808E-10 1.370900E+0 1.378706E+0 1.297323E+0 8.585859E-10 1.343867E+0 1.378856E+0 1.244573E+0 9.090909E-10 1.317870E+0 1.375803E+0 1.188162E+0 9.595960E-10 1.294423E+0 1.366089E+0 1.140601E+0 1.010101E-9 1.266136E+0 1.353141E+0 1.098324E+0 1.060606E-9 1.232657E+0 1.340455E+0 1.063965E+0 1.111111E-9 1.199343E+0 1.327253E+0 1.044008E+0 1.161616E-9 1.168783E+0 1.313794E+0 1.033979E+0 1.212121E-9 1.142351E+0 1.300244E+0 1.027244E+0 1.262626E-9 1.118520E+0 1.286503E+0 1.024775E+0 1.313131E-9 1.101414E+0 1.271538E+0 1.023495E+0 1.363636E-9 1.087457E+0 1.254853E+0 1.023197E+0 1.414141E-9 1.080846E+0 1.236854E+0 1.023195E+0 1.464646E-9 1.075602E+0 1.218419E+0 1.023465E+0 1.515152E-9 1.073286E+0 1.200318E+0 1.023809E+0 1.565657E-9 1.071527E+0 1.183155E+0 1.024202E+0 1.616162E-9 1.070866E+0 1.167897E+0 1.024604E+0 1.666667E-9 1.070426E+0 1.154345E+0 1.025004E+0 1.717172E-9 1.070392E+0 1.143701E+0 1.025392E+0 1.767677E-9 1.070454E+0 1.134961E+0 1.025751E+0 1.818182E-9 1.070681E+0 1.128851E+0 1.026095E+0 1.868687E-9 1.070937E+0 1.124145E+0 1.026418E+0 1.919192E-9 1.071238E+0 1.121028E+0 1.026725E+0 1.969697E-9 1.071549E+0 1.118724E+0 1.027009E+0 2.020202E-9 1.071872E+0 1.117255E+0 1.027279E+0 2.070707E-9 1.072188E+0 1.116221E+0 1.027534E+0 2.121212E-9 1.072491E+0 1.115616E+0 1.027778E+0 2.171717E-9 1.072786E+0 1.115242E+0 1.028008E+0 2.222222E-9 1.073070E+0 1.115089E+0 1.028228E+0 2.272727E-9 1.073339E+0 1.115055E+0 1.028437E+0 2.323232E-9 1.073592E+0 1.115129E+0 1.028639E+0 2.373737E-9 1.073834E+0 1.115263E+0 1.028832E+0 2.424242E-9 1.074063E+0 1.115449E+0 1.029018E+0 2.474747E-9 1.074279E+0 1.115662E+0 1.029195E+0 2.525253E-9 1.074482E+0 1.115894E+0 1.029366E+0 2.575758E-9 1.074675E+0 1.116135E+0 1.029533E+0 2.626263E-9 1.074858E+0 1.116381E+0 1.029691E+0 2.676768E-9 1.075031E+0 1.116625E+0 1.029841E+0 2.727273E-9 1.075194E+0 1.116864E+0 1.029987E+0 2.777778E-9 1.075349E+0 1.117096E+0 1.030130E+0 2.828283E-9 1.075496E+0 1.117321E+0 1.030263E+0 2.878788E-9 1.075635E+0 1.117536E+0 1.030388E+0 2.929293E-9 1.075768E+0 1.117740E+0 1.030509E+0 2.979798E-9 1.075894E+0 1.117934E+0 1.030628E+0 3.030303E-9 1.076014E+0 1.118120E+0 1.030737E+0 3.080808E-9 1.076128E+0 1.118293E+0 1.030837E+0 3.131313E-9 1.076238E+0 1.118457E+0 1.030934E+0 3.181818E-9 1.076341E+0 1.118611E+0 1.031030E+0 3.232323E-9 1.076440E+0 1.118757E+0 1.031114E+0 3.282828E-9 1.076534E+0 1.118893E+0 1.031190E+0 3.333333E-9 1.076626E+0 1.119022E+0 1.031264E+0 3.383838E-9 1.076712E+0 1.119141E+0 1.031337E+0 3.434343E-9 1.076794E+0 1.119255E+0 1.031398E+0 3.484848E-9 1.076873E+0 1.119361E+0 1.031451E+0 3.535354E-9 1.076950E+0 1.119460E+0 1.031503E+0 3.585859E-9 1.077021E+0 1.119553E+0 1.031556E+0 3.636364E-9 1.077090E+0 1.119642E+0 1.031597E+0 3.686869E-9 1.077156E+0 1.119723E+0 1.031630E+0 3.737374E-9 1.077221E+0 1.119801E+0 1.031664E+0 3.787879E-9 1.077280E+0 1.119873E+0 1.031699E+0 3.838384E-9 1.077337E+0 1.119943E+0 1.031723E+0 3.888889E-9 1.077393E+0 1.120007E+0 1.031740E+0 3.939394E-9 1.077447E+0 1.120068E+0 1.031760E+0 3.989899E-9 1.077496E+0 1.120125E+0 1.031782E+0 4.040404E-9 1.077543E+0 1.120181E+0 1.031792E+0 4.090909E-9 1.077589E+0 1.120232E+0 1.031797E+0 4.141414E-9 1.077635E+0 1.120280E+0 1.031806E+0 4.191919E-9 1.077674E+0 1.120326E+0 1.031818E+0 4.242424E-9 1.077713E+0 1.120371E+0 1.031819E+0 4.292929E-9 1.077751E+0 1.120412E+0 1.031816E+0 4.343434E-9 1.077789E+0 1.120452E+0 1.031819E+0 4.393939E-9 1.077820E+0 1.120489E+0 1.031824E+0 4.444444E-9 1.077851E+0 1.120526E+0 1.031820E+0 4.494949E-9 1.077882E+0 1.120560E+0 1.031812E+0 4.545455E-9 1.077913E+0 1.120593E+0 1.031811E+0 4.595960E-9 1.077937E+0 1.120624E+0 1.031813E+0 4.646465E-9 1.077962E+0 1.120655E+0 1.031806E+0 4.696970E-9 1.077986E+0 1.120683E+0 1.031795E+0 4.747475E-9 1.078011E+0 1.120710E+0 1.031794E+0 4.797980E-9 1.078029E+0 1.120736E+0 1.031795E+0 4.848485E-9 1.078048E+0 1.120762E+0 1.031786E+0 4.898990E-9 1.078067E+0 1.120786E+0 1.031775E+0 4.949495E-9 1.078086E+0 1.120809E+0 1.031775E+0 5.000000E-9 1.078098E+0 1.120832E+0 1.031777E+0 | [Rising Waveform] R_fixture=100 V_fixture=0 V_fixture_min=0 V_fixture_max=0 0.0 1.078168E+0 1.121237E+0 1.031757E+0 5.050505E-11 1.078168E+0 1.121237E+0 1.031757E+0 1.010101E-10 1.078168E+0 1.121237E+0 1.031757E+0 1.515152E-10 1.078168E+0 1.121237E+0 1.031757E+0 2.020202E-10 1.078168E+0 1.121237E+0 1.031757E+0 2.525253E-10 1.078168E+0 1.121237E+0 1.031757E+0 3.030303E-10 1.078168E+0 1.121237E+0 1.031756E+0 3.535354E-10 1.078165E+0 1.121236E+0 1.031749E+0 4.040404E-10 1.078162E+0 1.121235E+0 1.031746E+0 4.545455E-10 1.078157E+0 1.121230E+0 1.031799E+0 5.050505E-10 1.078163E+0 1.121226E+0 1.031932E+0 5.555556E-10 1.078265E+0 1.121227E+0 1.031997E+0 6.060606E-10 1.078416E+0 1.121240E+0 1.031882E+0 6.565657E-10 1.078559E+0 1.121341E+0 1.030553E+0 7.070707E-10 1.078174E+0 1.121503E+0 1.027639E+0 7.575758E-10 1.075678E+0 1.121714E+0 1.029394E+0 8.080808E-10 1.073363E+0 1.121524E+0 1.054945E+0 8.585859E-10 1.083065E+0 1.119749E+0 1.109478E+0 9.090909E-10 1.104371E+0 1.117147E+0 1.176334E+0 9.595960E-10 1.141404E+0 1.119252E+0 1.230291E+0 1.010101E-9 1.186563E+0 1.129367E+0 1.289200E+0 1.060606E-9 1.221562E+0 1.142183E+0 1.350394E+0 1.111111E-9 1.251991E+0 1.160619E+0 1.407863E+0 1.161616E-9 1.285205E+0 1.184177E+0 1.454302E+0 1.212121E-9 1.320947E+0 1.208850E+0 1.483646E+0 1.262626E-9 1.356633E+0 1.230537E+0 1.484899E+0 1.313131E-9 1.390334E+0 1.247234E+0 1.483510E+0 1.363636E-9 1.416631E+0 1.262602E+0 1.481409E+0 1.414141E-9 1.428385E+0 1.279621E+0 1.478773E+0 1.464646E-9 1.433509E+0 1.298903E+0 1.476348E+0 1.515152E-9 1.435890E+0 1.318725E+0 1.474147E+0 1.565657E-9 1.435994E+0 1.338076E+0 1.472141E+0 1.616162E-9 1.435287E+0 1.355212E+0 1.470359E+0 1.666667E-9 1.433967E+0 1.369643E+0 1.468822E+0 1.717172E-9 1.432550E+0 1.379819E+0 1.467496E+0 1.767677E-9 1.431099E+0 1.386747E+0 1.466256E+0 1.818182E-9 1.429747E+0 1.390913E+0 1.465132E+0 1.868687E-9 1.428490E+0 1.393208E+0 1.464165E+0 1.919192E-9 1.427311E+0 1.394311E+0 1.463321E+0 1.969697E-9 1.426225E+0 1.394621E+0 1.462517E+0 2.020202E-9 1.425248E+0 1.394441E+0 1.461782E+0 2.070707E-9 1.424361E+0 1.393955E+0 1.461163E+0 2.121212E-9 1.423528E+0 1.393306E+0 1.460626E+0 2.171717E-9 1.422759E+0 1.392557E+0 1.460107E+0 2.222222E-9 1.422068E+0 1.391756E+0 1.459634E+0 2.272727E-9 1.421437E+0 1.390944E+0 1.459250E+0 2.323232E-9 1.420838E+0 1.390154E+0 1.458922E+0 2.373737E-9 1.420283E+0 1.389387E+0 1.458597E+0 2.424242E-9 1.419786E+0 1.388642E+0 1.458302E+0 2.474747E-9 1.419329E+0 1.387934E+0 1.458077E+0 2.525253E-9 1.418893E+0 1.387273E+0 1.457887E+0 2.575758E-9 1.418489E+0 1.386650E+0 1.457690E+0 2.626263E-9 1.418129E+0 1.386054E+0 1.457513E+0 2.676768E-9 1.417798E+0 1.385497E+0 1.457389E+0 2.727273E-9 1.417480E+0 1.384984E+0 1.457286E+0 2.777778E-9 1.417187E+0 1.384501E+0 1.457167E+0 2.828283E-9 1.416928E+0 1.384041E+0 1.457062E+0 2.878788E-9 1.416690E+0 1.383613E+0 1.456998E+0 2.929293E-9 1.416460E+0 1.383221E+0 1.456944E+0 2.979798E-9 1.416249E+0 1.382852E+0 1.456870E+0 3.030303E-9 1.416066E+0 1.382499E+0 1.456805E+0 3.080808E-9 1.415898E+0 1.382172E+0 1.456772E+0 3.131313E-9 1.415733E+0 1.381873E+0 1.456741E+0 3.181818E-9 1.415584E+0 1.381592E+0 1.456689E+0 3.232323E-9 1.415457E+0 1.381322E+0 1.456643E+0 3.282828E-9 1.415340E+0 1.381072E+0 1.456623E+0 3.333333E-9 1.415224E+0 1.380846E+0 1.456600E+0 3.383838E-9 1.415120E+0 1.380631E+0 1.456557E+0 3.434343E-9 1.415034E+0 1.380424E+0 1.456519E+0 3.484848E-9 1.414954E+0 1.380235E+0 1.456501E+0 3.535354E-9 1.414873E+0 1.380063E+0 1.456479E+0 3.585859E-9 1.414802E+0 1.379901E+0 1.456437E+0 3.636364E-9 1.414746E+0 1.379742E+0 1.456400E+0 3.686869E-9 1.414692E+0 1.379598E+0 1.456381E+0 3.737374E-9 1.414636E+0 1.379470E+0 1.456357E+0 3.787879E-9 1.414589E+0 1.379347E+0 1.456314E+0 3.838384E-9 1.414552E+0 1.379226E+0 1.456278E+0 3.888889E-9 1.414517E+0 1.379117E+0 1.456257E+0 3.939394E-9 1.414479E+0 1.379022E+0 1.456230E+0 3.989899E-9 1.414447E+0 1.378929E+0 1.456188E+0 4.040404E-9 1.414424E+0 1.378837E+0 1.456152E+0 4.090909E-9 1.414401E+0 1.378756E+0 1.456130E+0 4.141414E-9 1.414374E+0 1.378686E+0 1.456103E+0 4.191919E-9 1.414353E+0 1.378617E+0 1.456062E+0 4.242424E-9 1.414339E+0 1.378547E+0 1.456029E+0 4.292929E-9 1.414323E+0 1.378487E+0 1.456008E+0 4.343434E-9 1.414304E+0 1.378436E+0 1.455982E+0 4.393939E-9 1.414288E+0 1.378384E+0 1.455946E+0 4.444444E-9 1.414279E+0 1.378332E+0 1.455917E+0 4.494949E-9 1.414268E+0 1.378288E+0 1.455899E+0 4.545455E-9 1.414253E+0 1.378252E+0 1.455877E+0 4.595960E-9 1.414241E+0 1.378214E+0 1.455846E+0 4.646465E-9 1.414235E+0 1.378174E+0 1.455822E+0 4.696970E-9 1.414226E+0 1.378143E+0 1.455809E+0 4.747475E-9 1.414213E+0 1.378118E+0 1.455791E+0 4.797980E-9 1.414203E+0 1.378090E+0 1.455766E+0 4.848485E-9 1.414198E+0 1.378060E+0 1.455748E+0 4.898990E-9 1.414189E+0 1.378038E+0 1.455740E+0 4.949495E-9 1.414178E+0 1.378021E+0 1.455726E+0 5.000000E-9 1.414173E+0 1.377994E+0 1.455705E+0 | |[End data_o_n | |====================================================================== | [Model] data_o_p Model_type Output Polarity Non-Inverting Vref=1.25 Vmeas=1.25 Rref=100 Cref=10p C_comp 4p NA NA | [Temperature Range] 25 85 -40 | [Voltage Range] 3.3 3.0 3.6 | [Pullup] -3.300000E+0 1.476752E-1 1.350953E-1 1.616678E-1 -3.200000E+0 1.444216E-1 1.320835E-1 1.580779E-1 -3.100000E+0 1.411503E-1 1.290437E-1 1.544783E-1 -3.000000E+0 1.378613E-1 1.259807E-1 1.508686E-1 -2.900000E+0 1.345550E-1 1.228967E-1 1.472479E-1 -2.800000E+0 1.312313E-1 1.197934E-1 1.436155E-1 -2.700000E+0 1.278904E-1 1.166720E-1 1.399704E-1 -2.600000E+0 1.245326E-1 1.135341E-1 1.363118E-1 -2.500000E+0 1.211579E-1 1.103806E-1 1.326390E-1 -2.400000E+0 1.177667E-1 1.072128E-1 1.289513E-1 -2.300000E+0 1.143595E-1 1.040315E-1 1.252486E-1 -2.200000E+0 1.109366E-1 1.008380E-1 1.215306E-1 -2.100000E+0 1.074989E-1 9.763319E-2 1.177978E-1 -2.000000E+0 1.040472E-1 9.441830E-2 1.140507E-1 -1.900000E+0 1.005826E-1 9.119451E-2 1.102907E-1 -1.800000E+0 9.710636E-2 8.796314E-2 1.065197E-1 -1.700000E+0 9.362020E-2 8.472573E-2 1.027407E-1 -1.600000E+0 9.012667E-2 8.148435E-2 9.895863E-2 -1.500000E+0 8.663034E-2 7.824232E-2 9.518258E-2 -1.400000E+0 8.313779E-2 7.500456E-2 9.142290E-2 -1.300000E+0 7.965216E-2 7.177551E-2 8.768826E-2 -1.200000E+0 7.617193E-2 6.855550E-2 8.402147E-2 -1.100000E+0 7.270544E-2 6.534425E-2 8.055223E-2 -1.000000E+0 6.928131E-2 6.214707E-2 7.735067E-2 -9.000000E-1 6.597988E-2 5.897696E-2 7.426780E-2 -8.000000E-1 6.292715E-2 5.586161E-2 7.125560E-2 -7.000000E-1 6.009863E-2 5.286156E-2 6.841420E-2 -6.000000E-1 5.739812E-2 5.006133E-2 6.576988E-2 -5.000000E-1 5.486687E-2 4.746312E-2 6.315061E-2 -4.000000E-1 5.239416E-2 4.501689E-2 6.054053E-2 -3.000000E-1 4.993493E-2 4.265094E-2 5.794087E-2 -2.000000E-1 4.748898E-2 4.030510E-2 5.535378E-2 -1.000000E-1 4.505814E-2 3.797364E-2 5.278176E-2 0.0 4.264448E-2 3.565768E-2 5.022773E-2 10.000000E-2 4.025022E-2 3.335826E-2 4.769625E-2 2.000000E-1 3.787625E-2 3.107550E-2 4.518991E-2 3.000000E-1 3.552283E-2 2.880949E-2 4.270933E-2 4.000000E-1 3.319022E-2 2.656031E-2 4.025514E-2 5.000000E-1 3.087861E-2 2.432798E-2 3.782795E-2 6.000000E-1 2.858812E-2 2.211243E-2 3.542835E-2 7.000000E-1 2.631874E-2 1.991349E-2 3.305684E-2 8.000000E-1 2.407022E-2 1.773074E-2 3.071380E-2 9.000000E-1 2.184190E-2 1.556331E-2 2.839936E-2 1.000000E+0 1.963236E-2 1.340929E-2 2.611325E-2 1.100000E+0 1.743852E-2 1.126428E-2 2.385451E-2 1.200000E+0 1.525405E-2 9.121202E-3 2.162082E-2 1.300000E+0 1.306922E-2 6.974465E-3 1.940706E-2 1.400000E+0 1.087653E-2 4.821182E-3 1.720225E-2 1.500000E+0 8.672541E-3 2.659266E-3 1.498782E-2 1.600000E+0 6.454487E-3 4.867326E-4 1.274924E-2 1.700000E+0 4.219180E-3 -1.698230E-3 1.048447E-2 1.800000E+0 1.963060E-3 -3.894882E-3 8.191658E-3 1.900000E+0 -3.175515E-4 -6.095141E-3 5.865089E-3 2.000000E+0 -2.625268E-3 -8.300989E-3 3.497874E-3 2.100000E+0 -4.954666E-3 -1.051033E-2 1.084157E-3 2.200000E+0 -7.287749E-3 -1.269953E-2 -1.379835E-3 2.300000E+0 -9.621159E-3 -1.486620E-2 -3.890409E-3 2.400000E+0 -1.193498E-2 -1.702862E-2 -6.433814E-3 2.500000E+0 -1.418566E-2 -1.919091E-2 -8.974481E-3 2.600000E+0 -1.641681E-2 -2.135414E-2 -1.147860E-2 2.700000E+0 -1.864441E-2 -2.351877E-2 -1.385088E-2 2.800000E+0 -2.087185E-2 -2.568487E-2 -1.617092E-2 2.900000E+0 -2.309845E-2 -2.785228E-2 -1.848008E-2 3.000000E+0 -2.532455E-2 -3.002067E-2 -2.078584E-2 3.100000E+0 -2.755032E-2 -3.218835E-2 -2.309078E-2 3.200000E+0 -2.977575E-2 -3.435409E-2 -2.539330E-2 3.300000E+0 -3.200075E-2 -3.652282E-2 -2.769166E-2 3.400000E+0 -3.422338E-2 -3.879235E-2 -2.998629E-2 3.500000E+0 -3.644141E-2 -4.334025E-2 -3.227747E-2 3.600000E+0 -3.865591E-2 -7.398447E-2 -3.456545E-2 3.700000E+0 -4.088533E-2 -1.599911E-1 -3.684830E-2 3.800000E+0 -4.335358E-2 -2.753006E-1 -3.912335E-2 3.900000E+0 -4.797115E-2 -4.021089E-1 -4.139176E-2 4.000000E+0 -7.720957E-2 -5.344914E-1 -4.369829E-2 4.100000E+0 -1.678474E-1 -6.700802E-1 -4.672887E-2 4.200000E+0 -2.876836E-1 -8.077288E-1 -5.220226E-2 4.300000E+0 -4.177168E-1 -9.468019E-1 -6.002976E-2 4.400000E+0 -5.525010E-1 -1.086920E+0 -8.198781E-2 4.500000E+0 -6.899736E-1 -1.227833E+0 -1.716783E-1 4.600000E+0 -8.291564E-1 -1.369368E+0 -2.949799E-1 4.700000E+0 -9.695243E-1 -1.511405E+0 -4.278904E-1 4.800000E+0 -1.110753E+0 -1.653855E+0 -5.649286E-1 4.900000E+0 -1.252635E+0 -1.796650E+0 -7.042164E-1 5.000000E+0 -1.395030E+0 -1.939739E+0 -8.449056E-1 5.100000E+0 -1.537839E+0 -2.083080E+0 -9.865536E-1 5.200000E+0 -1.680988E+0 -2.226642E+0 -1.128892E+0 5.300000E+0 -1.824422E+0 -2.370398E+0 -1.271751E+0 5.400000E+0 -1.968101E+0 -2.514328E+0 -1.415019E+0 5.500000E+0 -2.111995E+0 -2.658411E+0 -1.558615E+0 5.600000E+0 -2.256076E+0 -2.802633E+0 -1.702488E+0 5.700000E+0 -2.400325E+0 -2.946979E+0 -1.846602E+0 5.800000E+0 -2.544721E+0 -3.091437E+0 -1.990933E+0 5.900000E+0 -2.689246E+0 -3.235996E+0 -2.135454E+0 6.000000E+0 -2.833887E+0 -3.380648E+0 -2.280138E+0 6.100000E+0 -2.978632E+0 -3.525384E+0 -2.424961E+0 6.200000E+0 -3.123470E+0 -3.670199E+0 -2.569903E+0 6.300000E+0 -3.268392E+0 -3.815084E+0 -2.714947E+0 6.400000E+0 -3.413391E+0 -3.960036E+0 -2.860080E+0 6.500000E+0 -3.558459E+0 -4.105049E+0 -3.005293E+0 6.600000E+0 -3.703592E+0 -4.250119E+0 -3.150576E+0 | [Pulldown] -3.300000E+0 -3.697288E+0 -3.810388E+0 -3.578020E+0 -3.200000E+0 -3.552306E+0 -3.665604E+0 -3.432802E+0 -3.100000E+0 -3.407387E+0 -3.520891E+0 -3.287637E+0 -3.000000E+0 -3.262537E+0 -3.376254E+0 -3.142531E+0 -2.900000E+0 -3.117761E+0 -3.231700E+0 -2.997490E+0 -2.800000E+0 -2.973068E+0 -3.087237E+0 -2.852519E+0 -2.700000E+0 -2.828464E+0 -2.942874E+0 -2.707626E+0 -2.600000E+0 -2.683961E+0 -2.798620E+0 -2.562820E+0 -2.500000E+0 -2.539568E+0 -2.654486E+0 -2.418112E+0 -2.400000E+0 -2.395299E+0 -2.510488E+0 -2.273512E+0 -2.300000E+0 -2.251169E+0 -2.366639E+0 -2.129037E+0 -2.200000E+0 -2.107197E+0 -2.222960E+0 -1.984704E+0 -2.100000E+0 -1.963405E+0 -2.079471E+0 -1.840534E+0 -2.000000E+0 -1.819821E+0 -1.936202E+0 -1.696555E+0 -1.900000E+0 -1.676479E+0 -1.793184E+0 -1.552802E+0 -1.800000E+0 -1.533422E+0 -1.650459E+0 -1.409319E+0 -1.700000E+0 -1.390707E+0 -1.508081E+0 -1.266166E+0 -1.600000E+0 -1.248407E+0 -1.366116E+0 -1.123425E+0 -1.500000E+0 -1.106623E+0 -1.224655E+0 -9.812116E-1 -1.400000E+0 -9.654988E-1 -1.083820E+0 -8.396967E-1 -1.300000E+0 -8.252413E-1 -9.437818E-1 -6.991496E-1 -1.200000E+0 -6.861746E-1 -8.047905E-1 -5.600376E-1 -1.100000E+0 -5.488488E-1 -6.672391E-1 -4.232195E-1 -1.000000E+0 -4.142451E-1 -5.317588E-1 -2.906552E-1 -9.000000E-1 -2.844885E-1 -3.995141E-1 -1.681700E-1 -8.000000E-1 -1.652378E-1 -2.729117E-1 -8.131732E-2 -7.000000E-1 -7.616260E-2 -1.580022E-1 -6.015832E-2 -6.000000E-1 -4.753894E-2 -7.283480E-2 -5.186681E-2 -5.000000E-1 -4.248580E-2 -4.245063E-2 -4.581935E-2 -4.000000E-1 -3.950116E-2 -3.755813E-2 -4.212245E-2 -3.000000E-1 -3.674356E-2 -3.490178E-2 -3.911474E-2 -2.000000E-1 -3.399880E-2 -3.234762E-2 -3.613265E-2 -1.000000E-1 -3.125176E-2 -2.980139E-2 -3.313487E-2 4.440892E-16 -2.850398E-2 -2.726083E-2 -3.012260E-2 1.000000E-1 -2.577196E-2 -2.473566E-2 -2.712446E-2 2.000000E-1 -2.306814E-2 -2.223349E-2 -2.416159E-2 3.000000E-1 -2.039181E-2 -1.975416E-2 -2.123240E-2 4.000000E-1 -1.774144E-2 -1.729710E-2 -1.833317E-2 5.000000E-1 -1.511314E-2 -1.486092E-2 -1.545005E-2 6.000000E-1 -1.249060E-2 -1.244157E-2 -1.252234E-2 7.000000E-1 -9.837446E-3 -1.002223E-2 -9.583548E-3 8.000000E-1 -7.198958E-3 -7.599533E-3 -6.671578E-3 9.000000E-1 -4.590173E-3 -5.202889E-3 -3.784346E-3 1.000000E+0 -2.005939E-3 -2.835867E-3 -9.102519E-4 1.100000E+0 5.559515E-4 -4.946313E-4 1.945838E-3 1.200000E+0 3.090112E-3 1.816986E-3 4.781088E-3 1.300000E+0 5.589615E-3 4.095095E-3 7.583665E-3 1.400000E+0 8.027689E-3 6.331540E-3 1.028539E-2 1.500000E+0 1.040329E-2 8.526347E-3 1.287814E-2 1.600000E+0 1.271943E-2 1.068097E-2 1.536947E-2 1.700000E+0 1.497896E-2 1.279715E-2 1.777255E-2 1.800000E+0 1.718447E-2 1.487826E-2 2.010168E-2 1.900000E+0 1.933920E-2 1.693032E-2 2.236753E-2 2.000000E+0 2.144891E-2 1.896192E-2 2.457625E-2 2.100000E+0 2.352119E-2 2.098220E-2 2.672993E-2 2.200000E+0 2.556607E-2 2.299679E-2 2.882986E-2 2.300000E+0 2.759496E-2 2.500824E-2 3.088795E-2 2.400000E+0 2.961538E-2 2.701778E-2 3.292264E-2 2.500000E+0 3.163111E-2 2.902606E-2 3.494569E-2 2.600000E+0 3.364401E-2 3.103346E-2 3.696262E-2 2.700000E+0 3.565508E-2 3.304022E-2 3.897606E-2 2.800000E+0 3.766490E-2 3.504650E-2 4.098735E-2 2.900000E+0 3.967383E-2 3.705242E-2 4.299721E-2 3.000000E+0 4.168209E-2 3.905805E-2 4.500610E-2 3.100000E+0 4.368985E-2 4.106345E-2 4.701428E-2 3.200000E+0 4.569722E-2 4.306867E-2 4.902194E-2 3.300000E+0 4.770427E-2 4.507408E-2 5.102920E-2 3.400000E+0 4.971108E-2 4.708673E-2 5.303615E-2 3.500000E+0 5.171768E-2 4.916676E-2 5.504285E-2 3.600000E+0 5.372412E-2 5.135204E-2 5.704936E-2 3.700000E+0 5.573068E-2 5.360231E-2 5.905571E-2 3.800000E+0 5.774099E-2 5.593125E-2 6.106194E-2 3.900000E+0 5.981686E-2 5.837007E-2 6.306808E-2 4.000000E+0 6.210715E-2 6.091385E-2 6.507432E-2 4.100000E+0 6.459403E-2 6.353272E-2 6.708279E-2 4.200000E+0 6.724162E-2 6.620304E-2 6.911667E-2 4.300000E+0 6.999773E-2 6.891382E-2 7.129658E-2 4.400000E+0 7.282534E-2 7.165854E-2 7.387854E-2 4.500000E+0 7.570763E-2 7.442619E-2 7.675349E-2 4.600000E+0 7.863746E-2 7.720598E-2 7.976082E-2 4.700000E+0 8.161176E-2 7.999321E-2 8.285384E-2 4.800000E+0 8.462199E-2 8.278571E-2 8.601138E-2 4.900000E+0 8.764914E-2 8.558120E-2 8.921939E-2 5.000000E+0 9.068133E-2 8.837710E-2 9.246840E-2 5.100000E+0 9.371479E-2 9.117095E-2 9.575521E-2 5.200000E+0 9.674693E-2 9.396056E-2 9.906611E-2 5.300000E+0 9.977513E-2 9.674395E-2 1.023736E-1 5.400000E+0 1.027972E-1 9.951932E-2 1.056668E-1 5.500000E+0 1.058114E-1 1.022849E-1 1.089447E-1 5.600000E+0 1.088167E-1 1.050389E-1 1.122072E-1 5.700000E+0 1.118119E-1 1.077792E-1 1.154543E-1 5.800000E+0 1.147967E-1 1.105035E-1 1.186863E-1 5.900000E+0 1.177703E-1 1.132090E-1 1.219040E-1 6.000000E+0 1.207324E-1 1.158923E-1 1.251082E-1 6.100000E+0 1.236827E-1 1.185493E-1 1.282998E-1 6.200000E+0 1.266209E-1 1.211723E-1 1.314794E-1 6.300000E+0 1.295469E-1 1.237451E-1 1.346477E-1 6.400000E+0 1.324619E-1 1.262368E-1 1.378054E-1 6.500000E+0 1.353685E-1 1.285801E-1 1.409527E-1 6.600000E+0 1.382696E-1 1.305388E-1 1.440902E-1 | [Ramp] dV/dt_r 1.016E-1/3.049E-10 7.657E-2/4.413E-10 1.308E-1/2.201E-10 dV/dt_f 1.223E-1/2.426E-10 7.878E-2/3.712E-10 1.741E-1/1.464E-10 | [Falling Waveform] R_fixture=100 V_fixture=0 V_fixture_min=0 V_fixture_max=0 0.0 1.413793E+0 1.377608E+0 1.455685E+0 5.050505E-11 1.413793E+0 1.377608E+0 1.455685E+0 1.010101E-10 1.413793E+0 1.377608E+0 1.455685E+0 1.515152E-10 1.413793E+0 1.377608E+0 1.455685E+0 2.020202E-10 1.413793E+0 1.377608E+0 1.455685E+0 2.525253E-10 1.413793E+0 1.377608E+0 1.455685E+0 3.030303E-10 1.413792E+0 1.377608E+0 1.455684E+0 3.535354E-10 1.413789E+0 1.377608E+0 1.455676E+0 4.040404E-10 1.413785E+0 1.377606E+0 1.455672E+0 4.545455E-10 1.413778E+0 1.377599E+0 1.455730E+0 5.050505E-10 1.413783E+0 1.377592E+0 1.455870E+0 5.555556E-10 1.413898E+0 1.377588E+0 1.455932E+0 6.060606E-10 1.414075E+0 1.377598E+0 1.455769E+0 6.565657E-10 1.414240E+0 1.377718E+0 1.453891E+0 7.070707E-10 1.413676E+0 1.377937E+0 1.449494E+0 7.575758E-10 1.410128E+0 1.378248E+0 1.443256E+0 8.080808E-10 1.404825E+0 1.378056E+0 1.428328E+0 8.585859E-10 1.403421E+0 1.375603E+0 1.376892E+0 9.090909E-10 1.393289E+0 1.371494E+0 1.315204E+0 9.595960E-10 1.365224E+0 1.369031E+0 1.259479E+0 1.010101E-9 1.327027E+0 1.370864E+0 1.198542E+0 1.060606E-9 1.293752E+0 1.367766E+0 1.146504E+0 1.111111E-9 1.259262E+0 1.356811E+0 1.103052E+0 1.161616E-9 1.223226E+0 1.339639E+0 1.068852E+0 1.212121E-9 1.188974E+0 1.319041E+0 1.043961E+0 1.262626E-9 1.157894E+0 1.298052E+0 1.035526E+0 1.313131E-9 1.131000E+0 1.278899E+0 1.030929E+0 1.363636E-9 1.108803E+0 1.259923E+0 1.027908E+0 1.414141E-9 1.095811E+0 1.240590E+0 1.026367E+0 1.464646E-9 1.087573E+0 1.221080E+0 1.025493E+0 1.515152E-9 1.081723E+0 1.202159E+0 1.025212E+0 1.565657E-9 1.078015E+0 1.184318E+0 1.025136E+0 1.616162E-9 1.075557E+0 1.168732E+0 1.025242E+0 1.666667E-9 1.074156E+0 1.155420E+0 1.025418E+0 1.717172E-9 1.073255E+0 1.145124E+0 1.025651E+0 1.767677E-9 1.072780E+0 1.137178E+0 1.025900E+0 1.818182E-9 1.072537E+0 1.131321E+0 1.026162E+0 1.868687E-9 1.072482E+0 1.127005E+0 1.026426E+0 1.919192E-9 1.072515E+0 1.123900E+0 1.026689E+0 1.969697E-9 1.072620E+0 1.121660E+0 1.026950E+0 2.020202E-9 1.072771E+0 1.120054E+0 1.027206E+0 2.070707E-9 1.072952E+0 1.118919E+0 1.027453E+0 2.121212E-9 1.073141E+0 1.118153E+0 1.027693E+0 2.171717E-9 1.073336E+0 1.117646E+0 1.027932E+0 2.222222E-9 1.073537E+0 1.117320E+0 1.028165E+0 2.272727E-9 1.073737E+0 1.117134E+0 1.028386E+0 2.323232E-9 1.073930E+0 1.117062E+0 1.028601E+0 2.373737E-9 1.074117E+0 1.117065E+0 1.028816E+0 2.424242E-9 1.074301E+0 1.117110E+0 1.029024E+0 2.474747E-9 1.074479E+0 1.117195E+0 1.029219E+0 2.525253E-9 1.074648E+0 1.117315E+0 1.029406E+0 2.575758E-9 1.074811E+0 1.117451E+0 1.029595E+0 2.626263E-9 1.074969E+0 1.117588E+0 1.029777E+0 2.676768E-9 1.075121E+0 1.117732E+0 1.029942E+0 2.727273E-9 1.075266E+0 1.117888E+0 1.030100E+0 2.777778E-9 1.075405E+0 1.118040E+0 1.030260E+0 2.828283E-9 1.075539E+0 1.118182E+0 1.030412E+0 2.878788E-9 1.075668E+0 1.118322E+0 1.030546E+0 2.929293E-9 1.075793E+0 1.118465E+0 1.030673E+0 2.979798E-9 1.075912E+0 1.118600E+0 1.030803E+0 3.030303E-9 1.076027E+0 1.118722E+0 1.030923E+0 3.080808E-9 1.076137E+0 1.118841E+0 1.031025E+0 3.131313E-9 1.076245E+0 1.118961E+0 1.031120E+0 3.181818E-9 1.076348E+0 1.119072E+0 1.031219E+0 3.232323E-9 1.076446E+0 1.119171E+0 1.031309E+0 3.282828E-9 1.076541E+0 1.119267E+0 1.031379E+0 3.333333E-9 1.076634E+0 1.119365E+0 1.031445E+0 3.383838E-9 1.076723E+0 1.119455E+0 1.031517E+0 3.434343E-9 1.076807E+0 1.119534E+0 1.031579E+0 3.484848E-9 1.076889E+0 1.119611E+0 1.031621E+0 3.535354E-9 1.076969E+0 1.119691E+0 1.031661E+0 3.585859E-9 1.077046E+0 1.119763E+0 1.031709E+0 3.636364E-9 1.077117E+0 1.119825E+0 1.031747E+0 3.686869E-9 1.077187E+0 1.119888E+0 1.031767E+0 3.737374E-9 1.077256E+0 1.119953E+0 1.031787E+0 3.787879E-9 1.077321E+0 1.120012E+0 1.031816E+0 3.838384E-9 1.077381E+0 1.120062E+0 1.031836E+0 3.888889E-9 1.077439E+0 1.120114E+0 1.031839E+0 3.939394E-9 1.077498E+0 1.120169E+0 1.031844E+0 3.989899E-9 1.077552E+0 1.120217E+0 1.031860E+0 4.040404E-9 1.077602E+0 1.120258E+0 1.031867E+0 4.090909E-9 1.077650E+0 1.120301E+0 1.031858E+0 4.141414E-9 1.077699E+0 1.120347E+0 1.031853E+0 4.191919E-9 1.077744E+0 1.120388E+0 1.031862E+0 4.242424E-9 1.077783E+0 1.120422E+0 1.031861E+0 4.292929E-9 1.077823E+0 1.120459E+0 1.031844E+0 4.343434E-9 1.077863E+0 1.120499E+0 1.031835E+0 4.393939E-9 1.077899E+0 1.120533E+0 1.031840E+0 4.444444E-9 1.077930E+0 1.120562E+0 1.031835E+0 4.494949E-9 1.077961E+0 1.120593E+0 1.031815E+0 4.545455E-9 1.077993E+0 1.120628E+0 1.031805E+0 4.595960E-9 1.078021E+0 1.120658E+0 1.031809E+0 4.646465E-9 1.078044E+0 1.120682E+0 1.031803E+0 4.696970E-9 1.078067E+0 1.120710E+0 1.031783E+0 4.747475E-9 1.078092E+0 1.120741E+0 1.031774E+0 4.797980E-9 1.078113E+0 1.120766E+0 1.031779E+0 4.848485E-9 1.078129E+0 1.120786E+0 1.031774E+0 4.898990E-9 1.078147E+0 1.120811E+0 1.031755E+0 4.949495E-9 1.078166E+0 1.120839E+0 1.031750E+0 5.000000E-9 1.078176E+0 1.120855E+0 1.031763E+0 | [Rising Waveform] R_fixture=100 V_fixture=0 V_fixture_min=0 V_fixture_max=0 0.0 1.078168E+0 1.121237E+0 1.031757E+0 5.050505E-11 1.078186E+0 1.121256E+0 1.031770E+0 1.010101E-10 1.078179E+0 1.121254E+0 1.031762E+0 1.515152E-10 1.078173E+0 1.121246E+0 1.031758E+0 2.020202E-10 1.078167E+0 1.121242E+0 1.031736E+0 2.525253E-10 1.078147E+0 1.121237E+0 1.031696E+0 3.030303E-10 1.078114E+0 1.121229E+0 1.031656E+0 3.535354E-10 1.078072E+0 1.121200E+0 1.031616E+0 4.040404E-10 1.078023E+0 1.121168E+0 1.031571E+0 4.545455E-10 1.077967E+0 1.121132E+0 1.031599E+0 5.050505E-10 1.077875E+0 1.121088E+0 1.031812E+0 5.555556E-10 1.077832E+0 1.121032E+0 1.033077E+0 6.060606E-10 1.078386E+0 1.120952E+0 1.037401E+0 6.565657E-10 1.080597E+0 1.120875E+0 1.045673E+0 7.070707E-10 1.084936E+0 1.121055E+0 1.063053E+0 7.575758E-10 1.089479E+0 1.121691E+0 1.106566E+0 8.080808E-10 1.098634E+0 1.123384E+0 1.161737E+0 8.585859E-10 1.120816E+0 1.125858E+0 1.217189E+0 9.090909E-10 1.156033E+0 1.127863E+0 1.278677E+0 9.595960E-10 1.192380E+0 1.128908E+0 1.340713E+0 1.010101E-9 1.223809E+0 1.131639E+0 1.401826E+0 1.060606E-9 1.256006E+0 1.140573E+0 1.455121E+0 1.111111E-9 1.291645E+0 1.156594E+0 1.480402E+0 1.161616E-9 1.328286E+0 1.177400E+0 1.488192E+0 1.212121E-9 1.363744E+0 1.200441E+0 1.491000E+0 1.262626E-9 1.395701E+0 1.221229E+0 1.489103E+0 1.313131E-9 1.418537E+0 1.237717E+0 1.486251E+0 1.363636E-9 1.435761E+0 1.253013E+0 1.483417E+0 1.414141E-9 1.439935E+0 1.269926E+0 1.480722E+0 1.464646E-9 1.442527E+0 1.289035E+0 1.478406E+0 1.515152E-9 1.441746E+0 1.309142E+0 1.476255E+0 1.565657E-9 1.440657E+0 1.329157E+0 1.474335E+0 1.616162E-9 1.438968E+0 1.347965E+0 1.472563E+0 1.666667E-9 1.437281E+0 1.364717E+0 1.471030E+0 1.717172E-9 1.435602E+0 1.377379E+0 1.469601E+0 1.767677E-9 1.434004E+0 1.387173E+0 1.468289E+0 1.818182E-9 1.432542E+0 1.392862E+0 1.467080E+0 1.868687E-9 1.431156E+0 1.396570E+0 1.466029E+0 1.919192E-9 1.429889E+0 1.398210E+0 1.465047E+0 1.969697E-9 1.428708E+0 1.398936E+0 1.464136E+0 2.020202E-9 1.427648E+0 1.398836E+0 1.463305E+0 2.070707E-9 1.426646E+0 1.398382E+0 1.462587E+0 2.121212E-9 1.425721E+0 1.397635E+0 1.461919E+0 2.171717E-9 1.424863E+0 1.396770E+0 1.461295E+0 2.222222E-9 1.424086E+0 1.395819E+0 1.460735E+0 2.272727E-9 1.423351E+0 1.394853E+0 1.460259E+0 2.323232E-9 1.422664E+0 1.393892E+0 1.459816E+0 2.373737E-9 1.422029E+0 1.392954E+0 1.459400E+0 2.424242E-9 1.421452E+0 1.392048E+0 1.459035E+0 2.474747E-9 1.420905E+0 1.391184E+0 1.458731E+0 2.525253E-9 1.420390E+0 1.390364E+0 1.458448E+0 2.575758E-9 1.419918E+0 1.389588E+0 1.458179E+0 2.626263E-9 1.419486E+0 1.388853E+0 1.457949E+0 2.676768E-9 1.419078E+0 1.388163E+0 1.457763E+0 2.727273E-9 1.418692E+0 1.387515E+0 1.457589E+0 2.777778E-9 1.418341E+0 1.386906E+0 1.457419E+0 2.828283E-9 1.418020E+0 1.386331E+0 1.457279E+0 2.878788E-9 1.417716E+0 1.385794E+0 1.457171E+0 2.929293E-9 1.417427E+0 1.385290E+0 1.457066E+0 2.979798E-9 1.417169E+0 1.384818E+0 1.456959E+0 3.030303E-9 1.416931E+0 1.384371E+0 1.456876E+0 3.080808E-9 1.416707E+0 1.383955E+0 1.456814E+0 3.131313E-9 1.416492E+0 1.383563E+0 1.456750E+0 3.181818E-9 1.416303E+0 1.383198E+0 1.456681E+0 3.232323E-9 1.416129E+0 1.382851E+0 1.456631E+0 3.282828E-9 1.415965E+0 1.382529E+0 1.456595E+0 3.333333E-9 1.415807E+0 1.382225E+0 1.456553E+0 3.383838E-9 1.415671E+0 1.381942E+0 1.456504E+0 3.434343E-9 1.415545E+0 1.381673E+0 1.456470E+0 3.484848E-9 1.415426E+0 1.381424E+0 1.456447E+0 3.535354E-9 1.415311E+0 1.381189E+0 1.456415E+0 3.585859E-9 1.415213E+0 1.380970E+0 1.456376E+0 3.636364E-9 1.415123E+0 1.380761E+0 1.456349E+0 3.686869E-9 1.415037E+0 1.380569E+0 1.456331E+0 3.737374E-9 1.414954E+0 1.380386E+0 1.456302E+0 3.787879E-9 1.414885E+0 1.380217E+0 1.456268E+0 3.838384E-9 1.414821E+0 1.380056E+0 1.456244E+0 3.888889E-9 1.414760E+0 1.379908E+0 1.456225E+0 3.939394E-9 1.414700E+0 1.379767E+0 1.456198E+0 3.989899E-9 1.414652E+0 1.379637E+0 1.456165E+0 4.040404E-9 1.414607E+0 1.379512E+0 1.456142E+0 4.090909E-9 1.414563E+0 1.379398E+0 1.456124E+0 4.141414E-9 1.414520E+0 1.379290E+0 1.456097E+0 4.191919E-9 1.414486E+0 1.379190E+0 1.456066E+0 4.242424E-9 1.414455E+0 1.379094E+0 1.456044E+0 4.292929E-9 1.414423E+0 1.379007E+0 1.456026E+0 4.343434E-9 1.414392E+0 1.378924E+0 1.456000E+0 4.393939E-9 1.414368E+0 1.378847E+0 1.455971E+0 4.444444E-9 1.414346E+0 1.378774E+0 1.455951E+0 4.494949E-9 1.414322E+0 1.378707E+0 1.455934E+0 4.545455E-9 1.414299E+0 1.378644E+0 1.455911E+0 4.595960E-9 1.414282E+0 1.378586E+0 1.455885E+0 4.646465E-9 1.414266E+0 1.378529E+0 1.455868E+0 4.696970E-9 1.414248E+0 1.378479E+0 1.455854E+0 4.747475E-9 1.414230E+0 1.378431E+0 1.455834E+0 4.797980E-9 1.414217E+0 1.378387E+0 1.455812E+0 4.848485E-9 1.414205E+0 1.378344E+0 1.455799E+0 4.898990E-9 1.414190E+0 1.378306E+0 1.455788E+0 4.949495E-9 1.414176E+0 1.378269E+0 1.455771E+0 5.000000E-9 1.414167E+0 1.378234E+0 1.455754E+0 | |[End data_o_p | |====================================================================== [End] application/octet-stream attachment: fin1017m.ibs Next message: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" Previous message: Steve Grout: "Test - Please ignore" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 24 2001 - 12:41:20 PDT Minutes, IBIS Teleconference Meeting 7/20 Subject: Minutes, IBIS Teleconference Meeting 7/20 From: Peters, Stephen (stephen.peters@intel.com) Date: Tue Jul 24 2001 - 12:43:34 PDT Next message: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: Adam.Tambone@fairchildsemi.com: "Vod and Differential Models" Next in thread: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] DATE: 7/24/01 SUBJECT: 7/20/01 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal* Ansoft Corporation (Eric Bracken) Apple Computer John Figueroa Applied Simulation Technology [Raj Raghuram], Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Cadence Design [Ian Dodd], Patrick Dos Santos, Heiko Dudek Lynne Green, Lance Wang Cisco Systems Syed Huq, Lungfu Chen EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone Huawei Technologies Rachild Chen IBM Michael Cohen, Greg Edlund*, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel* Innoveda (& HyperLynx) Guy de Burgh, John Angulo*, Cary Mandel, Matthew Flora, Steve Kaufer Intel Corporation Stephen Peters*, Arpad Muranyi*, Dave Lorang, Michael Mirmak, Qinglun Chen, Will Hobbs, Wei-hsing Huang LSI Logic Larry Barnes Mentor Graphics Bob Ross*, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad, Mohammed Korany, Weston Beal, Chris Swaim, Ali Samii, Eric Ronger, Karine Loudet, Daisaku Shiga, Kenji Kushima Micron Technology Randy Wolff*, Yong Phan* Mitsubishi Pat Hefferan Molex Incorporated Gus Panella, Brian O'Malley National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre Philips Semiconductor Zack Ciccone, Rob Mataheroe Quantic EMC (Mike Ventham) Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz SiQual Scott McMorrow, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar, Jean Claude Perrin, Moshiul Haque Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) John Berrie, Ralf Bruening OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith ASIS Ltd David Wright Brocade Communications Robert Badal BMW Friedrich Hasinger Cereva Networks Bob Haller Compaq [Peter LaFlamme], Ron Bellomio, Quang Dam, Bill Ham Cypress (Rajesh Manapat) EADS Airbus Industry Claude Huet (Aerospatiale) EFM Ekkehard Miersch, Horle Raines EIA Cecilia Fleming Ericsson Radio Systems Anders Ekholm FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fraunhofer Institute Mariusz Faferko, Peter Kralicek Reliability and Integration Fujitsu Ltd Tadashi Arai, Takeshi Murakami Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt Hyundai Electronics Jongho Kang Idaho State University Al Davis Infineon Technologies Christian Sporrer Intrinsix Corporation Steven Chin Motorola (Rick Kingen) National Institute of Applied Etienne Sicard Science (INSA) Nokia Tapani von Ravner, Mika Castren, Janne Uusitalo Nortel Networks Calvin Trowell Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Siemens (& Automotive) AG Bernhard Unger, Helmut Katzier, Katja Koller, Wolfram Meyer, Eckhard Lenski, Gerald Bannert, Burkhard Muller, Christian Marot, Manfred Maurer, Amir Motamedi, Hans Pichlmaier Sigrity Raj Raghuram* Sintecs Hans Klos STMicroelectronics Peter Hirt, Fabrice Boissieres Sun Adrian Udenze Toshiba Corp. Hirokaza Kato, Yuichi Koga, Toshio Sudo 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 10 (877) 299-1938 none 6350164 August 31 (916) 356-2663 2 4779396 Thursday, September 13, 2001 IBIS Summit Meeting, No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum, and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Stephen Peters and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Raj Raghuram, who has been involved for years with IBIS as a model developer and as a tool developer joined Sigrity. Sigrity is involved with power and signal integrity simulations and uses IBIS models. Raj stated that Sigrity plans to become an EIA IBIS Open Forum member. MEMBERSHIP UPDATE AND TREASURER'S REPORT Stephen Peters reported about 28-29 members (down from 30) since there were some payment issues. These are being resolved. Bob Ross reported there are three potential members that are being processed (including Sigrity). So we expect about 32 members, ahead of the 30 member target from which our budget is based. REVIEW OF MINUTES AND AR'S The June 01, 2001 IBIS Minutes were approved without change. Bob Ross submitted a spelling correction for Ralf Bruening of Zuken in the participants list for the June 21, 2001 IBIS Summit Meeting minutes. The Minutes were approved with this change. Bob stated that the uploaded minutes have been corrected. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Stephen Peters stated that several officers have been on vacation, but are now returning. Guy de Burgh will return after July 27, 2001. PRESS AND WEB PAGE UPDATES Stephen Peters reported that Syed Huq made more Roster updates, did an FAQ update (for ibischk3 source code license purchases), uploaded some IBIS Summit presentations, and updated the Upcoming Events link. NEW MODELS AVAILABLE, LIBRARY UPDATE Stephen Peters stated that Roy Leventhal provided more updates as of 6/26/01 on the IBIS Models link. Bob Ross reported that Mindspeed Technologies (a Conexant Business) has IBIS Models under (URL split into two lines to avoid mailer truncation): http://web2.mindspeed.com/default.sph/SaServletEngine.class/Web/products/ documents.jsp?doc_type=27 OPENS FOR NEW ISSUES None. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - No report. Bob Ross stated that the document is probably still in prepublication status. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross still cannot find the new link to the IMIC document. - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal (formerly, IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross stated that Etienne Sicard plans to present work at the September 13, 2001 IBIS Summit meeting. This will be discussed later in the meeting. - JEDEC JC-16 - Modeling and Testing - No report. - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the National Committee for Information Technology (NCITS)) - No report. DESIGN AUTOMATION CONFERENCE 2001 IBIS SUMMIT MEETING FEEDBACK Stephen Peters enjoyed the meeting. However, he felt that we did not have as many questions and interactions as in some other meetings and is looking for suggestions for more interactions. He expected more questions on IBIS-X. Arpad Muranyi reported that some people discussed things after the meeting, but he did not think there was an IBIS-X parser demonstration offered by Al Davis. Several people had to catch plane connections after the meeting. Bob Ross stated that we had more presentations than expected and had to limit questions to keep the meeting going. We did not have copies of all slides available at the meeting. The presentations are all now uploaded under: http://www.eda.org/pub/ibis/summits/jun01/ PCB CONFERENCE EAST 2001 IBIS SUMMIT MEETING PLANS Bob Ross reported that an IBIS Summit Meeting is planned all day on Thursday, September 13, 2001 in Worcester, Massachusetts at the Crowne Plaza Hotel near the PCB Conference East 2001 show. The meeting follows on the next day the trade show portion of the show. The Upcoming events link of the IBIS Home page already contains the sign-up information and hotel information. A free lunch and refreshments are included. Kathy Breda of NESA has been handling the arrangements and signups. She will also coordinate making copies of presentations for the meeting. Bob stated that we need to address the funding issue. In the past the EDA vendors have shared the meeting expenses. So far Bob expects these presentations (titles may change): "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard, National Institute of Applied Science (INSA) in France "A Proposal for s2ibis3", Michael Steer, North Carolina State University Plus IBIS Version 4.0, IBIS-X and IBIS Connector Specification Progress Bob indicated that the IBIS Futures Working Group had discussed demonstrating the IBIS-X parser at the Summit meeting. This follows up on Stephen Peters comment to make the meeting have more interactive and promote more questions and discussions. Bob plans that the first announcement will be sent next week. NORTH CAROLINA STATE UNIVERSITY S2IBIS3 PROJECT Stephen Peters reported that he and Michael Steer of North Carolina State University (NCSU) have made recent contact. NCSU is working on a cell design project under a DARPA contract and is now interested in using IBIS. Michael is interested in developing s2ibis3 as part of this research. His team would be interested in using the ibischk3 as a basis, but Stephen stated that NCSU would have to pay for the source code. NCSU will probably develop their own parser independently. Bob Ross mentioned that NCSU would release s2ibis3 source code and executables under a GPL (GNU public license). Michael Steer is scheduled to discuss the project at the September 13, 2001 IBIS Summit Meeting. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo sent out a model from STMicroelectronics for review. John also has two other models that are being processed prior to being distributed. John stated that he cannot continue heading the IBIS Model Review Committee because of work commitments. He suggested several other people. Stephen Peters will work offline to find a replacement. MAJORDOMO AND SPAM MAIL UPDATE Stephen Peters reported that there seems to be more spam messages on the IBIS reflectors. Possibly someone is harvesting names off the mailing list (which is protected) or off of e-mail correspondence. One solution is to control the messages from a list server such as Majordomo. Using Majordomo, only folks that have subscribed and have known valid e-mail addresses could post to the IBIS reflectors, thus cutting down on SPAM to the list. John Angulo is still working with the eda.org systems administrators on using Majordomo. John would want to set up a test reflector before we actually make the change. There might be more restrictive access. John also noted that some of the spam messages have been sent to the ibis-request and ibis-info addresses. CONNECTOR PROPOSAL REVIEW The Working Group has been meet on June 12, July 3, and July 10, 2001. The attendance was down because of vacations. Stephen Peters summarized that work is continuing on reviewing the Connector Specification to align it with the IBIS document and also with some IBIS-X conventions. This work is proceeding more slowly than expected. Some recent topics include uncoupled and coupled lines, the transmission line syntax and frequency dependent matrices. Bob Ross stated that more people are now involved. Some earlier decisions are subject to review. The original choices included focusing on connector only issues versus trying to make this a combined package/connector model document, and postponing lossy matrices. Arpad Muranyi stated that it might not be difficult to put in frequency dependent matrices. Bob agreed and stated that the earlier consensus continues to implement losses based on matrices as a function of frequency. This is a superset of just assuming skin effect and conductance matrix relationships. Stephen stated that he preferred using the matrix approach as implemented in the document and wanted to proceed in a rapid manner to get the Connector Specification approved by the end of the year. It has been under development for several years. The next meeting is scheduled on July 24, 2001, and they should continue on a weekly basis. IBIS FUTURES (IBIS-X, API, BIRDxx) Stephen Peters summarized the progress based on meetings on June 12, July 3, 10 and 17, 2001. The discussions included the basic elements, some transmission line syntax (similar to the Connector Specification), LRC matrix issues and the Laplace element. John Angulo added that the syntax for controlled sources was discussed at the last meeting. Stephen stated that Scott McMorrow has issued comments on the Connector Specification and now is providing good comments on the IBIS futures documents. Work is continuing and the next meeting is scheduled for July 24, 2001. These should continue on a weekly basis. BIRD70.3 - GOLDEN WAVEFORMS Greg Edlund indicated that he put out several messages on the IBIS reflector in response to comments made at previous meetings. He got one positive comment back. Bob Ross stated that vacations and other IBIS activities prevented him from looking at BIRD70.3 and Greg's comments until now. He summarized his response as follows: He agrees with Issue 1 that a new [Test Data] subparameter Driver_model_inv should be added to support unsymmetrical differential drivers. He suggests that [Test Load] should add the subparamater Receiver_model_inv for completeness and to support unsymmetrical receivers with internal terminations. Bob noted that the [Test Load] subparameter Test_load_type was incorrectly entered as "Test_data_type" in some portions of BIRD70.3. Bob agreed with Greg's proposed Issue 2 restriction that only these combinations of Test_data_type and Test_load_type would be supported: Single_ended, Single_ended Differential, Differential While the combination Differential, Single_ended is also possible, it is not necessary since the Single_ended test load can be created with default large values of Rdiff*. The rules need to be stated for the Single_ended case how to interpret the differential golden waveforms [Diff ...] and the Rdiff* and *_inv parameters. Bob proposed that should be ignored. The parser probably would accept the model, but issue an Warning message. Finally the single_ended golden waveforms given for Test_data_type Differential should be for the non-inverting side of the net when *-inv models are used. The inverting golden waveform data can be obtained by a separate test, but with the inverting and non-inverting models interchanged. If the differential network is symmetrical, this is not an issue since the inverting and non-inverting models are the same. Bob plans to respond on the reflector to Greg's e-mail to capture these points. Greg should review this and issue BIRD70.4 in time for a vote at the next IBIS Meeting. AR - Bob Ross respond to Greg Edlunds comments. Greg issue BIRD70.4 by July 27, 2001 so that it can be presented for a vote at the next IBIS Meeting. BIRD71 - TIMING TEST LOADS IN [Model Spec] TO SUPPORT PCI & PCI-X Stephen Peters stated that there have not been any reflector comments on BIRD71. BIRD71 completes the list of [Model Spec] subparameters in a manner that supports PCI and PCI-X specifications. There have been some concerns on how EDA tools should use the new information. Bob Ross stated that he had questions because some of the new specification subparameters interacted with the model data itself. The loads, for example may be different for the min and max corners. This does not relate to how a physical part is specified or measured since the measurement is set up independent of the electrical characteristics of the component. So there may be some ambiguity on how EDA tools are to process the new subparameters. One suggestion is that the new subparameters is related to the actual model corners and are used to set up best and worst cases. Bob had suggested that there might be some discussion about on this in BIRD71. He did not have specific suggestions. Bob favors adding the subparameters per BIRD71 and letting the EDA tools decide how to process the new information. He will communicate any new ideas, if any, by next week. Stephen proposed that BIRD71 be scheduled for a vote at the next meeting. OTHER PENDING BIRDS Stephen Peters stated that he wanted IBIS Version 4.0 to be finished soon and voted by the end of the year. Votes are planned for BIRD70.4 and BIRD71. All other pending BIRDs need to be issued or deferred until IBIS-X. Bob stated that the SSO improvement proposal is pending, but might be deferred to IBIS-X where structural interactions could be programmed. This improvement may not work in all cases and may open up some technical issues. A fallback submodel BIRD is needed for some existing technologies needs to be generated if it is to be considered. Bob also stated that a clarification BIRD for Series Switch models is being developed by Tom Dagostino (following up on the Ad Hoc presentation at the June 21, 2001 IBIS Summit Meeting). This pending BIRD will make the discussion more general, but will not propose any syntax change. IBISCHK3 BUG TRACKING - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or the [Pullup] table contains non-monotonic data in the clamping regions, and there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an incorrect Error message. The non-monotonic data itself causes ibischk3 to calculate the wrong endpoint values because the algorithm probably has numerical difficulties. It probably starts its convergence calculation at one end of the table rather than from the middle and gets numerically confused with the non-monotonic data. Even though the model is non-monotonic, it may represent real data. Some EDA tools will correctly process the model. However, the recently implemented Waveform endpoint tests now report an Error instead of a Warning, preventing the model to be processed in systems that uses ibischk3 for input model parsing. Bob suggested classifying BUG57 as Annoying, Low, and Open. The problem is how to resolve BUG57. The choices are (1) fix the test, (2) change the Error back to a Warning, or (3) ignore this problem and force the user to modify the IBIS file. Bob suggested that we work on (1) as a low priority activity. If the fix is too difficult, then we might consider (3). No one wanted (2). Stephen Peters suggested that a note could be added to the Warning or Error message to alert the user of a possible reason for the Error Message so that the user could modify the model. Bob suggested that because this is a low priority bug, it should be investigated after all the other open bugs are fixed. Then we can decide how to proceed. END OF MEETING TOPIC Roy Leventhal stated that he talked about signal integrity and IBIS at a recent IPC Design Learning Symposium meeting. He will track their activity. NEXT MEETING: The next teleconference meeting will be on Friday, August 10, 2001, from 8:00 AM to 10:00 AM. BIRD70.4 and BIRD71 are scheduled for a vote. ============================================================================ == NOTES IBIS CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-1831 stephen.peters@intel.com Senior Hardware Engineer, Intel Corporation M/S JF4-215 2111 NE 25th Ave. Hillsboro, OR 97124-5961 VICE CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 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/3 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.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================ == Next message: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: Adam.Tambone@fairchildsemi.com: "Vod and Differential Models" Next in thread: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 24 2001 - 12:45:47 PDT Re: Minutes, IBIS Teleconference Meeting 7/20 Subject: Re: Minutes, IBIS Teleconference Meeting 7/20 From: LiuWeidong (liuweidong@huawei.com) Date: Tue Jul 24 2001 - 18:13:30 PDT Next message: Gregory R Edlund: "Re: about the IBIS "checklist.txt."" Previous message: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" In reply to: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" Next in thread: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] For the message bellow, " Even though the model is non-monotonic, it may represent real data" " (3) ignore this problem and force the user to modify the IBIS file." " Bob suggested that we work on (1) as a low priority activity. If the fix is too difficult, then we might consider (3). No one wanted (2). " I want to ask: It seems that a good model maybe is non-monotonic(right or wrong ?),Then how can we modefy the IBIS file ? Thanks, regards, LiuWeidong ----- Original Message ----- > > > IBISCHK3 BUG TRACKING > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail > Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or > the [Pullup] table contains non-monotonic data in the clamping regions, > and > there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an > incorrect Error message. > > The non-monotonic data itself causes ibischk3 to calculate the wrong > endpoint values because the algorithm probably has numerical difficulties. > It probably starts its convergence calculation at one end of the table > rather than from the middle and gets numerically confused with the > non-monotonic data. > > Even though the model is non-monotonic, it may represent real data. Some > EDA tools will correctly process the model. However, the recently > implemented Waveform endpoint tests now report an Error instead of a > Warning, preventing the model to be processed in systems that uses > ibischk3 > for input model parsing. > > Bob suggested classifying BUG57 as Annoying, Low, and Open. > > The problem is how to resolve BUG57. The choices are (1) fix the test, > (2) > change the Error back to a Warning, or (3) ignore this problem and force > the > user to modify the IBIS file. > > Bob suggested that we work on (1) as a low priority activity. If the fix > is > too difficult, then we might consider (3). No one wanted (2). Stephen > Peters suggested that a note could be added to the Warning or Error > message > to alert the user of a possible reason for the Error Message so that the > user could modify the model. Bob suggested that because this is a low > priority bug, it should be investigated after all the other open bugs are > fixed. Then we can decide how to proceed. > > Next message: Gregory R Edlund: "Re: about the IBIS "checklist.txt."" Previous message: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" In reply to: Peters, Stephen: "Minutes, IBIS Teleconference Meeting 7/20" Next in thread: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 24 2001 - 18:13:02 PDT Re: Minutes, IBIS Teleconference Meeting 7/20 Subject: Re: Minutes, IBIS Teleconference Meeting 7/20 From: Lynne Green (lgreen@cadence.com) Date: Wed Jul 25 2001 - 09:07:10 PDT Next message: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: Gregory R Edlund: "Re: about the IBIS "checklist.txt."" In reply to: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Next in thread: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] The EDA tools have to be able to use these models, which means the models must pass the parser. A smart user will send the model back to the person who made it, to verify whether the non-monotonicity is "real", before proceeding with simulation. - Lynne At 09:13 AM 7/25/2001 +0800, LiuWeidong wrote: >For the message bellow, >" Even though the model is non-monotonic, it may represent real data" >" (3) ignore this problem and force the user to modify the IBIS file." >" Bob suggested that we work on (1) as a low priority activity. If the >fix is too difficult, then we might consider (3). No one wanted (2). " > >I want to ask: >It seems that a good model maybe is non-monotonic(right or wrong ?),Then >how can we modefy the IBIS file ? > >Thanks, >regards, >LiuWeidong > >----- Original Message ----- > > > > > IBISCHK3 BUG TRACKING > > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail > > Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or > > the [Pullup] table contains non-monotonic data in the clamping regions, > > and > > there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an > > incorrect Error message. > > > > The non-monotonic data itself causes ibischk3 to calculate the wrong > > endpoint values because the algorithm probably has numerical > difficulties. > > It probably starts its convergence calculation at one end of the table > > rather than from the middle and gets numerically confused with the > > non-monotonic data. > > > > Even though the model is non-monotonic, it may represent real data. Some > > EDA tools will correctly process the model. However, the recently > > implemented Waveform endpoint tests now report an Error instead of a > > Warning, preventing the model to be processed in systems that uses > > ibischk3 > > for input model parsing. > > > > Bob suggested classifying BUG57 as Annoying, Low, and Open. > > > > The problem is how to resolve BUG57. The choices are (1) fix the test, > > (2) > > change the Error back to a Warning, or (3) ignore this problem and force > > the > > user to modify the IBIS file. > > > > Bob suggested that we work on (1) as a low priority activity. If the fix > > is > > too difficult, then we might consider (3). No one wanted (2). Stephen > > Peters suggested that a note could be added to the Warning or Error > > message > > to alert the user of a possible reason for the Error Message so that the > > user could modify the model. Bob suggested that because this is a low > > priority bug, it should be investigated after all the other open bugs are > > fixed. Then we can decide how to proceed. > > > > Next message: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: Gregory R Edlund: "Re: about the IBIS "checklist.txt."" In reply to: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Next in thread: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Wed Jul 25 2001 - 09:09:17 PDT IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20 Subject: IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20 From: Bob Ross (bob_ross@mentorg.com) Date: Wed Jul 25 2001 - 13:55:24 PDT Next message: Bob Ross: "IBIS Summit Meeting First Announcement 9/13/01" Previous message: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" In reply to: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hello LiuWeidong and Lynne: Let me clarify that the problem in bug57 is not the non-monotonic behavior itself. The issue is that the waveform endpoint test incorrectly fails. The waveform endpoints are actually correct, the the non-monotonic behavior described in bug57 causes the parser itself to not find the correct endpoints. This causes the model to fail because we recently changed the endpoint test (bug47) to issue an Error when the mismatch is greater than 10%. So a good model may be rejected because of the ibischk3 bug. The region where the failure occurs however, is not critical (e.g., in an extended clamping region where no current could possibly flow anyway. The easy (3) fix is just to change the current in that region to be monontonic. This type of change would be on a case-by-case basis based on where the problem is. I suspect that the parser problem is based an algorithm that starts at one end of a table to find a solution. If the algorithm started at the middle to find the solution, this would be less of a problem. See bug57 for a test case and more information: http://www.eda.org/pub/ibis/bugs/ibischk/bug57 Bob Ross Mentor Graphics Lynne Green wrote: > > The EDA tools have to be able to use these models, which means the models > must pass the parser. > > A smart user will send the model back to the person who made it, to verify > whether the non-monotonicity is "real", before proceeding with simulation. > > - Lynne > > At 09:13 AM 7/25/2001 +0800, LiuWeidong wrote: > >For the message bellow, > >" Even though the model is non-monotonic, it may represent real data" > >" (3) ignore this problem and force the user to modify the IBIS file." > >" Bob suggested that we work on (1) as a low priority activity. If the > >fix is too difficult, then we might consider (3). No one wanted (2). " > > > >I want to ask: > >It seems that a good model maybe is non-monotonic(right or wrong ?),Then > >how can we modefy the IBIS file ? > > > >Thanks, > >regards, > >LiuWeidong > > > >----- Original Message ----- > > > > > > > IBISCHK3 BUG TRACKING > > > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail > > > Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or > > > the [Pullup] table contains non-monotonic data in the clamping regions, > > > and > > > there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an > > > incorrect Error message. > > > > > > The non-monotonic data itself causes ibischk3 to calculate the wrong > > > endpoint values because the algorithm probably has numerical > > difficulties. > > > It probably starts its convergence calculation at one end of the table > > > rather than from the middle and gets numerically confused with the > > > non-monotonic data. > > > > > > Even though the model is non-monotonic, it may represent real data. Some > > > EDA tools will correctly process the model. However, the recently > > > implemented Waveform endpoint tests now report an Error instead of a > > > Warning, preventing the model to be processed in systems that uses > > > ibischk3 > > > for input model parsing. > > > > > > Bob suggested classifying BUG57 as Annoying, Low, and Open. > > > > > > The problem is how to resolve BUG57. The choices are (1) fix the test, > > > (2) > > > change the Error back to a Warning, or (3) ignore this problem and force > > > the > > > user to modify the IBIS file. > > > > > > Bob suggested that we work on (1) as a low priority activity. If the fix > > > is > > > too difficult, then we might consider (3). No one wanted (2). Stephen > > > Peters suggested that a note could be added to the Warning or Error > > > message > > > to alert the user of a possible reason for the Error Message so that the > > > user could modify the model. Bob suggested that because this is a low > > > priority bug, it should be investigated after all the other open bugs are > > > fixed. Then we can decide how to proceed. > > > > > > Next message: Bob Ross: "IBIS Summit Meeting First Announcement 9/13/01" Previous message: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" In reply to: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Reply: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Wed Jul 25 2001 - 14:01:25 PDT Re: about the IBIS "checklist.txt." Subject: Re: about the IBIS "checklist.txt." From: Gregory R Edlund (gedlund@us.ibm.com) Date: Wed Jul 25 2001 - 06:50:11 PDT Next message: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Dear LiuWeidong, Please see my answers below your questions. I hope this helps you. Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com "LiuWeidong" on 07/23/2001 08:38:09 PM To: Gregory R Edlund/Rochester/IBM@IBMUS cc: , Subject: about the IBIS "checklist.txt." Hello, Greg I have some questions about your IBIS Datasheet Checklist : "3. Has the modeling engineer performed a visual inspection of IV and VT curves to screen for non-monotonicity, discontinuities, and other obvious errors?" If a IV curves is non-monotonicity,How can I deal with it ? Can the model be used by the simulation tools? There are so many IBIS models provided by IC venders whose IV curves is non-monotonicity . [GREG] Non-monotonicity can be OK in some circumstances. Page 20 of the IBIS Cookbook shows an example of a pull-down curve that becomes non-monotonic after you subtract out the ground clamp current (I believe this is a numerical effect). Once you add the two curves back together, the composite becomes monotonic again, so this is OK. In other circumstances non-monotonicity may be indicative of a circuit feature such as bus hold, which uses a feedback circuit. This can make the simulator fail, so I usually smooth out the non-monotonicity in the IV curve of a circuit that has bus hold. The point is that you need to know what's causing the non-monotonicity. Your IBIS vendor should do this for you. "8. Does the output reach Vmeas under standard load conditions for rising and falling waveforms?" For this item , I don't think it should be in the IBIS Datasheet Checklist , Whether the output can reach Vmeas under standard load conditions for rising and falling waveforms mainly depend on the output buffer's driving capability . If a buffer's driving capability is very weak, the output maybe can't reach Vmeas under standard load conditions for rising and falling waveforms,but you can't think the IBIS model is wrong. [GREG] Vmeas comes from the component datasheet, and so the output better be able to drive it's own standard load. If it can't, there's something seriously wrong with the circuit design. If the behavioral simulations using the IBIS file don't reach Vmeas with the standard load but the real component DOES, then something went wrong during the creation of the IBIS file. Hope for your reply! Thanks! LiuWeidong ----- Original Message ----- From: Gregory R Edlund To: Cc: Sent: Thursday, May 24, 2001 8:53 PM Subject: Re: Clarification needed. > > Anbazhagan, > > Looks like you're on the right track. I would recommend your ASIC vendor > read the "IBIS Cookbook," which can be found on the IBIS web page: > http://www.eigroup.org/ibis/tools.htm > > As part of the "I/O Buffer Accuracy Handbook" (also available on the IBIS > web page), we published a checklist that should help you. This list was > compiled from suggestions by members of the SI community who have > experience with IBIS. I am attaching the most recent version of this list. > > Bob, Could you please post this list as an ASCII text file under Accuracy? > Pleas name it "checklist.txt." Thanks. > > > IBIS Datasheet Checklist version 1.1, > 05/07/01 > ------------------------ > > > IBIS datasheet: > Component manufacturer: > Component part number: > Engineer verifying this component: > Email address: > Behavioral simulator and version: > Date: > > > Note: If answer is N or N/A, provide explanation. > The user may verify items 1-9 but is unable to verify items 10-20 > because the data involved are only available to the semiconductor > vendor. > > > ___ 1. Does the IBIS datasheet pass the IBIS syntax checker? > (Note: Some models generate warnings for non-monotonicities that > are > actually part of the characteristics of the device. Other non- > monotonicities are so small as to be irrelevant.) > > ___ 2. Is an "I/O Buffer Accuracy Report" available for this component? > (http://www.vhdl.org/pub/ibis/accuracy) > > ___ 3. Has the modeling engineer performed a visual inspection of IV and > VT > curves to screen for non-monotonicity, discontinuities, and other > obvious errors? > > ___ 4. Has the modeling engineer tested the IBIS datasheet using a > behavioral > simulator? > > ___ 5. Do MIN and MAX data exist for all keywords and sub-parameters? > > ___ 6. Does the IBIS datasheet include all four 50 Ohm VT tables as > described > in the IBIS Cookbook? > > ___ 7. Do the keywords Cref, Rref, Vref, and Vmeas match the values > specified > in the component datasheet for all output and bidirectional models? > > ___ 8. Does the output reach Vmeas under standard load conditions for > rising > and falling waveforms? > > ___ 9. Does the pin table match the component datasheet? > > > ___ 10. Do the keywords Vihl and Vinh represent the unity gain points > derived > from the dc transfer characteristics for all inputs? > > ___ 11. Has the modeling engineer verified the accuracy of the C_comp > subparameter? > > ___ 12. Has the modeling engineer verified the accuracy of the R_pkg, > L_pkg, > and C_pkg subparameters? > > ___ 13. For CMOS logic, do all MAX data represent maximum voltage, minimum > temperature, and fast process? > > ___ 14. For CMOS logic, do all MIN data represent minimum voltage, maximum > temperature, and slow process? > > ___ 15. For bipolar logic, do all MAX data represent maximum voltage, > maximum > temperature, and fast process? > > ___ 16. For bipolar logic, do all MIN data represent minimum voltage, > minimum > temperature, and slow process? > > ___ 17. Do the keywords dV/dt_r and dV/dt_f contain the correct 20%-80% > edge > rate data measured using a 50 & load as specified in IBIS? > > ___ 18. If the I/O buffer employs dynamic clamping, does the IBIS datasheet > contain the appropriate keywords and subparameters? > > ___ 19. If the I/O buffer employs a multi-stage driver, does the IBIS > datasheet > contain the appropriate keywords and subparameters? > > ___ 20. If the I/O buffer design employs dynamic edge rate control, dynamic > impedance control, or any form of feedback, has the modeling > engineer > assessed the impact of this circuitry on behavioral model accuracy? > > > Greg Edlund > Electrical Packaging > IBM Server Technology Development > 3605 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > > Anbu@scmmicro.co.in on 05/24/2001 01:48:13 AM > > To: "ibis-users@eda.org": > cc: > Subject: Clarification needed. > > > > Hello Users, > > I am using XTK to simulate a PCBA. The board has a 100pin ASIC. In > order to model the ASIC properly I need the IBIS model of the ASIC which I > can convert it to XTK format. Now if I directly request for an IBIS model > the vendor may hesistate. So I am requesting the following data from the > vendor with which I can create a IBIS model. Below is the data I am > requesting them. Is it OK. Does it cover everything necessary to create a > proper IBIS model?. The ASIC does not have any clamp diodes. Please reply. > The following data whichever is applicable for each pin of the ASIC are > needed > 1. Package parasitics namely, the Resistance, capacitance and Inductance. > Typical, max, min values required. > > 2. Die capacitance as seen at the die pad. Typical, max, min values > required > > 3. Output impedance of the I/O buffers. Typical, max, min values required. > > 4. Rise time and fall time values (dv/dt typical, max, min) of buffers > excluding the effect of packaging but including the effect of die > capacitance. Load conditions required. > > 6. Rising edge and falling edge waveforms (Voltage vs. time curve with the > voltage values having typical, max, min values) of the driver along with > the test conditions. > > 5. V/I characteristics of Pull up and Pull down resistor, if present, when > the buffer is driven high and low respectively. The voltage sweep must be > from ?3.3V to +6.6V. Current measurement with typical, max, min values are > required. > > Thanks, > > Anbazhagan. > > > > > > Next message: Lynne Green: "Re: Minutes, IBIS Teleconference Meeting 7/20" Previous message: LiuWeidong: "Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Wed Jul 25 2001 - 06:52:16 PDT IBIS Summit Meeting First Announcement 9/13/01 Subject: IBIS Summit Meeting First Announcement 9/13/01 From: Bob Ross (bob_ross@mentorg.com) Date: Thu Jul 26 2001 - 14:04:16 PDT Next message: Bob Ross: "IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models" Previous message: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT FIRST 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, September 13, 2001 Location: The Crowne Plaza Hotel 10 Lincoln Square Worcester, MA Tel: (508) 791-1600 Fax: (508) 791-1796 Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), IBIS Users Group Others to be determined WE ARE LOOKING FOR ADDITIONAL SPONSORS! (contact Kathy Breda, breda@nesa.com or Bob Ross, bob_ross@mentor.com) PCB Conference: September 10-14, 2001 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ 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, Inc. (NESA) and has been meeting to consider and forward IBIS model user concerns. As a result of East coast meetings, the group has developed an IBIS Accuracy Handbook document and has initiated the project to format Connector Models. These topics plus others of current interest to the EIA IBIS Open Forum will be discussed at this 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 September 7, 2001. Otherwise the presenter will be expected to provide up to 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. So far the following presentatation is planned: "A Proposal for s2ibis3", Michael Steer, North Carolina State University "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard, National Institute of Applied Science (INSA/DEIG), France Plus IBIS Macro Language and demonstration, IBIS Connector Specification, and other IBIS issues. LIST OF NEARBY HOTELS See http://www.pcbeast.com for travel directions, hotels and other information. ************************************************************** Next message: Bob Ross: "IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models" Previous message: Bob Ross: "IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Thu Jul 26 2001 - 14:06:11 PDT IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models Subject: IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models From: Bob Ross (bob_ross@mentorg.com) Date: Thu Jul 26 2001 - 17:42:21 PDT Next message: Todd Westerhoff: "IBIS and device performance" Previous message: Bob Ross: "IBIS Summit Meeting First Announcement 9/13/01" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] To IBIS Committee: Attached is BIRD72 submitted by Tom Dagostino of Mentor Graphics. Bob Ross Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 72 ISSUE TITLE: Accommodating PMOS and NMOS//PMOS Series FET Models REQUESTER: Tom Dagostino, Mentor Graphics DATE SUBMITTED: July 26, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The IBIS FET Bus Switch model assumes a series NMOS FET which has its gate tied to Vdd. We have come across two other topologies for the FET switches, specifically: 1. What appears to be a PMOS device with it's gate tied to ground 2. Parallel NMOS and PMOS devices with gates respectively tied to Vdd and ground. The IBIS Golden Parser produces warnings and errors with models that describe this behavior. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: These models cause issues with the IBIS Golden Parser and, depending on assumptions in the simulator's implementations that support the bus switch, analysis issues. For the single PMOS case: The parser is set up to see increasing current as Vgs increase where Vgs is defined as Vcc - Vsource. Given this definition for Vgs the current Id will decrease as 'Vgs' increases for the PMOS device with its gate to ground. The parser gives an error of decreasing current as 'Vgs' increases. Simulators may make the assumption the FET is a NMOS device and may not handle the characteristics properly if the model gets parsed in. For the dual PMOS/NMOS case: In the case of the dual PMOS/NMOS topology the currents through the parallel FET's will sum and produce an Id curve that: -- starts with significant current at 'Vgs' = 0 (current is flowing through the PMOS device) -- decreases by 10 to 90% at about 40% of 'Vgs' range where both the PMOS and NMOS devices are both on -- increases to a larger value at 'Vgs' = Vdd than at 'Vgs" = 0. This is where the NMOS device is fully on This characteristic has been observed in several devices. This will cause a non-monotonic warning from the parser. It is not known how all simulators will handle this non-monotonic behavior. In general the simulators should be able to handle these characteristics. The IV curves define the device's characteristics and the simulator should just work with that definition. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following changes are proposed: The definition of Voltage in the IV table changes. Vgs has been Vcc - Vsource assuming the gate was tied to Vcc. IBIS should now assume the voltage in the IV table is really Vcc minus the FET's source voltage (Voltage = Vcc - Vsource). This makes old models compatible and no change in the model format is required. Decreasing current vs. Voltage are allowed. Non-monotonic currents in the table are expected in the parallel case but warnings can still be issued. It may be useful to have the modeler note the type of switch in the model so the user can better understand any non-monotonic issues. ****************************************************************************** Changes and additions to the IBIS Specification are shown by the |* lines |============================================================================= | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the I-V tables for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | [Series Pin Mapping] and pin_2 columns, respectively. | Sub-Params: Vds | Usage Rules: The first column contains the voltage value, and the three | remaining columns hold the typical, minimum, and maximum | current values. The four entries, Voltage, I(typ), I(min), | and I(max) must be placed on a single line and must be | separated by at least one white space. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. | | Other Notes: There is no monotonicity requirement. However the model | supplier should realize that it may not be possible to derive | a behavioral model from non-monotonic data. | |* the old model is: |* The model is: |* |* Table Current |* -------> |* + Vds - |* Pin 1 Pin 2 |* <---| |---> + |* d |_____| - s |* --+-- Vgs Vs |* | g + |* - |* Vg = [Voltage Range] = Vcc |* Vgs = Table Voltage = Vtable = Vcc - Vs |* Ids = Table Current for a given Vcc and Vds | |*The new model is: |* |* Table Current |* -------> Ids |* + Vds - |* |* Vcc |* | g |* ----+---- |* ------- NMOS |* Pin 1 | | Pin 2 |* <---| |---> Voltage = Vcc - Vs |* PMOS d |_____| s |* --+-- |* | g |* GND |* |* Either of the FET's could be removed (or have zero current |* contribution. Thus this model covers all four conditions, off, |* single NMOS, single PMOS and parallel NMOS/PMOS. |* |* Voltage = Table Voltage = Vtable = Vcc - Vs |* Ids = Table Current for a given Vcc and Vds | | |* old Internal logic that is generally referenced to the power rail |* is used to set the MOSFET switch to its 'On' state. Thus the |* [Voltage Range] settings provide the assumed gate voltages. |* If the [POWER Clamp Reference] exists, it overrides the |* [Voltage Range] value. The table entries are actually the Vgs |* values referenced to the power rail. The polarity conventions |* |* new Internal Logic that is generally referenced to the power rail |* is used to set the NMOS MOSFET switch to its 'ON' state. |* Internal logic likewise referenced to ground is used to set the |*- PMOS device to its 'ON' state if the PMOS device is present. |* Thus the [Voltage Range] settings provide the assumed |* gate voltages. If the [POWER Clamp Reference] exists, it |* overrides the [Voltage Range] value. The table entries are |* actually Vgs of the NMOS device and Vcc - Vgs of the PMOS !* device if present. The polarity conventions | are identical with those used for other tables that are | referenced to power rails. Thus the voltage column can be | viewed as a table defining the source voltages Vs according to | the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd >= Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | this assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the model with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow in both directions, as | would occur due to reflections when the switch is connected in | series with an unterminated transmission line. | | The model data is used to create an On state relationship | between the actual drain to source current, ids, and the | actual drain to source voltage, vds: | | ids = f(vds). | | This functional relationship depends on the actual source | voltage Vs and can be expressed in terms of the corresponding | table currents associated with Vs (and expressed as a function | of Vgs). | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be linearly related to the table drain to source current, | Ids, for the given Vds subparameter value and located at the | existing gate to source voltage value Vgs. This table current | is denoted as Ids(Vgs, Vds). The functional relationship | becomes: | |* old ids = Ids(Vgs, Vds) * vds / Vds. |* |* new ids = Idsn(V, Vds) * vds/Vds + Idsp((Vcc - V), Vds) * vds/Vds | | More than one [Series MOSFET] table is permitted, but it is | simulator dependent how the data will be used. Each | successive [Series MOSFET] table must have a different | subparameter value for Vds. The number of tables must not | exceed 100. | | C_comp values are ignored for [Series MOSFET] models. |----------------------------------------------------------------------------- [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p |============================================================================= ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: An Ad Hoc presentation on this topic was initially presented at the IBIS Summit Meeting on June 21, 2001. ****************************************************************************** Next message: Todd Westerhoff: "IBIS and device performance" Previous message: Bob Ross: "IBIS Summit Meeting First Announcement 9/13/01" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Thu Jul 26 2001 - 17:42:36 PDT IBIS and device performance Subject: IBIS and device performance From: Todd Westerhoff (twester@hhnetwk.com) Date: Fri Jul 27 2001 - 11:11:10 PDT Next message: Hailong Wang: "About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut" Previous message: Bob Ross: "IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi all, This particular question is going to both the SI and IBIS reflectors, as the issues touch both groups. Question 1 (for the SI-listers) How often are people seeing IBIS models that use the [Model Spec] keyword to list min/typ/max values for parameters like Vinl, Vinh and Vmeas? Are you seeing this commonly, or was your response "what is he talking about"? Question/Comment 2 (for the IBISians) Is there any definitive, short, concise document that lists which combinations of which IBIS parameters are meant to represent best, typical, and worst-case component-level performance? As an example, the [max] section of a V/I curve would clearly indicate best-case device performance, but you'd have to combine that with the [min] value of a parameter like c_comp. So - for best case conditions, the EDA tool and the model creator both have to use the same set of conventions of combining parameters for best, typical and worst case device performance. Is there a table anywhere that defines this? Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@hhnetwk.com ph: 978-671-5084 Next message: Hailong Wang: "About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut" Previous message: Bob Ross: "IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Fri Jul 27 2001 - 11:10:27 PDT About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut Subject: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut From: Hailong Wang (hlwang@avanticorp.com) Date: Sun Jul 29 2001 - 19:41:34 PDT Next message: Raj Raghuram: "Pin Mapping in IBIS models" Previous message: Todd Westerhoff: "IBIS and device performance" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi, I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the very similar functions. But form the IBIS Specification V3.2, I found they are different. So I am confused, and want to the relationship between them. Thanks in advance! -- Best Regards. Hai-long Wang Tel:021-62837026x228 Avant! Shanghai R&D Center, 16th Floor, SunTong InfoPort Plaza No.55, West Huaihai Road, Shanghai, 200030, P.R.China Next message: Raj Raghuram: "Pin Mapping in IBIS models" Previous message: Todd Westerhoff: "IBIS and device performance" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Sun Jul 29 2001 - 19:45:51 PDT Pin Mapping in IBIS models Subject: Pin Mapping in IBIS models From: Raj Raghuram (raghu@sigrity.com) Date: Tue Jul 31 2001 - 09:26:03 PDT Next message: Howard Johnson: "removal from ibis list" Previous message: Hailong Wang: "About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] The Pin Mapping section (optional) in IBIS 2.1 was introduced to associate drivers with appropriate Power and Ground pins for simulation of ground and power bounce. However, I am not able to locate any IBIS models which have this section. Can anybody point me to an IBIS model containing this section? Raj Raghuram Sigrity, Inc. "Achieve what others can't" raghu@sigrity.com http://www.sigrity.com 4675 Stevens Creek Blvd. , Ste 130 Santa Clara, CA-95051 PH: 408-260-9344 x116 CELL: 408-390-9614 FAX: 408-260-9342 Next message: Howard Johnson: "removal from ibis list" Previous message: Hailong Wang: "About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 09:31:01 PDT removal from ibis list Subject: removal from ibis list From: Howard Johnson (hsdd@signalintegrity.com) Date: Tue Jul 31 2001 - 15:33:11 PDT Previous message: Raj Raghuram: "Pin Mapping in IBIS models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Please remove Howard Johnson (howiej@sigcon.com, hsdd@sigcon.com, howiej@signalintegrity.com, hsdd@signalintegrity.com) from the IBIS email list. Previous message: Raj Raghuram: "Pin Mapping in IBIS models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 15:36:29 PDT Re: Pin Mapping in IBIS models Subject: Re: Pin Mapping in IBIS models From: LiuWeidong (liuweidong@huawei.com) Date: Tue Jul 31 2001 - 17:48:34 PDT Previous message: Howard Johnson: "removal from ibis list" In reply to: Raj Raghuram: "Pin Mapping in IBIS models" Reply: LiuWeidong: "Re: Pin Mapping in IBIS models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Please see the file attached. I hope this helps you ----- Original Message ----- From: Raj Raghuram To: ; Sent: Wednesday, August 01, 2001 12:26 AM Subject: Pin Mapping in IBIS models > The Pin Mapping section (optional) in IBIS 2.1 was introduced to associate > drivers with appropriate Power and Ground pins for simulation of ground and > power bounce. However, I am not able to locate any IBIS models which have > this section. > > Can anybody point me to an IBIS model containing this section? > > Raj Raghuram > Sigrity, Inc. > "Achieve what others can't" > raghu@sigrity.com > http://www.sigrity.com > 4675 Stevens Creek Blvd. , Ste 130 > Santa Clara, CA-95051 > PH: 408-260-9344 x116 > CELL: 408-390-9614 > FAX: 408-260-9342 > application/octet-stream attachment: LVT162244_pin_maping_.ibs |########################################################################## | TEXAS INSTRUMENTS INCORPORATED | Advanced Bus Interface Group | IBIS Model of LVT162244 | 3.3V ABT 16-Bit BUFFERS/DRIVERS WITH 3-STATE OUTPUTS |########################################################################## | [IBIS Ver] 1.1 [File Name] LVT162244.ibs | |12/25/1999,[pin mapping] was added in this model by Jiang XiangZhong CAD group Huawei company. | [File Rev] 2.0 [Date] 11/29/95 [Source] File originated at Texas Instruments, Inc. [Notes] The following is an IBIS list for the LVT162244. | - All test data contained in this file are derived from | hspice(tm) simulations. | - File created by Tareq Shahwan, ABL Applications. | - Disclaimer modified by David Holmgreen, Launch Marketing | |************************************************************************** [Disclaimer] Property of Texas Instruments Incorporated. Unauthorized reproduction and/or distribution is strictly prohibited. This product is protected under copyright law. Created 1995, (C) Copyright 1995, Texas Instruments Inc., All Rights Reserved UNLESS THERE IS A SIGNED, WRITTEN AGREEMENT TO THE CONTRARY, TEXAS INSTRUMENTS ("TI") IS PROVIDING THE IBIS MODELS "AS IS" AND WITHOUT ANY WARRANTY, EXPRESSED OR IMPLIED. TI assumes no liability for: 1) the accuracy of the IBIS models provided to your company; 2) the proper functioning of these IBIS models in your design or for any resulting applications; or 3) infringement of patents, copyrights or intellectual property rights resulting from your use of these IBIS models. TI provides IBIS Models as a service to our customers. You and your company shall not distribute, sell or give these models to anyone else without prior written permission from TI. TI reserves the right to make changes to our products or to discontinue any semiconductor product or service without notice, and advises our customers to obtain the latest version of relevant information to verify, before placing orders, that the information being relied on is current. Please be aware that your receipt and use of the IBIS information provided shall serve as acceptance of these terms and conditions. If you do not accept these terms, you should return or destroy the IBIS models and any other accompanying information immediately. | |************************************************************************** | [Component] LVT162244 [Manufacturer] Texas Instruments, Inc. [Package] | typ min max R_pkg 0.036 0.026 0.041 L_pkg 6.747nH 5.492nH 9.423nH C_pkg 0.752pF 0.392pF 1.110pF | |************************************************************************** | [Pin] signal_name model_name R_pin L_pin C_pin | 1 ce1 LVT162244_IN 0.041 8.654nH 1.110pF 24 ce2 LVT162244_IN 0.041 8.654nH 1.110pF 25 ce3 LVT162244_IN 0.041 8.654nH 1.110pF 48 ce4 LVT162244_IN 0.041 8.654nH 1.110pF 47 1D1 LVT162244_IN 0.041 8.654nH 1.110pF 46 1D2 LVT162244_IN 0.041 8.654nH 1.110pF 44 1D3 LVT162244_IN 0.041 8.654nH 1.110pF 43 1D4 LVT162244_IN 0.041 8.654nH 1.110pF 41 1D5 LVT162244_IN 0.041 8.654nH 1.110pF 40 1D6 LVT162244_IN 0.041 8.654nH 1.110pF 38 1D7 LVT162244_IN 0.041 8.654nH 1.110pF 37 1D8 LVT162244_IN 0.041 8.654nH 1.110pF 36 2D1 LVT162244_IN 0.041 8.654nH 1.110pF 35 2D2 LVT162244_IN 0.041 8.654nH 1.110pF 33 2D3 LVT162244_IN 0.041 8.654nH 1.110pF 32 2D4 LVT162244_IN 0.041 8.654nH 1.110pF 30 2D5 LVT162244_IN 0.041 8.654nH 1.110pF 29 2D6 LVT162244_IN 0.041 8.654nH 1.110pF 27 2D7 LVT162244_IN 0.041 8.654nH 1.110pF 26 2D8 LVT162244_IN 0.041 8.654nH 1.110pF 2 1O1 LVT162244_OUT 0.041 8.654nH 1.110pF 3 1O2 LVT162244_OUT 0.041 8.654nH 1.110pF 5 1O3 LVT162244_OUT 0.041 8.654nH 1.110pF 6 1O4 LVT162244_OUT 0.041 8.654nH 1.110pF 8 1O5 LVT162244_OUT 0.041 8.654nH 1.110pF 9 1O6 LVT162244_OUT 0.041 8.654nH 1.110pF 11 1O7 LVT162244_OUT 0.041 8.654nH 1.110pF 12 1O8 LVT162244_OUT 0.041 8.654nH 1.110pF 13 2O1 LVT162244_OUT 0.041 8.654nH 1.110pF 14 2O2 LVT162244_OUT 0.041 8.654nH 1.110pF 16 2O3 LVT162244_OUT 0.041 8.654nH 1.110pF 17 2O4 LVT162244_OUT 0.041 8.654nH 1.110pF 19 2O5 LVT162244_OUT 0.041 8.654nH 1.110pF 20 2O6 LVT162244_OUT 0.041 8.654nH 1.110pF 22 2O7 LVT162244_OUT 0.041 8.654nH 1.110pF 23 2O8 LVT162244_OUT 0.041 8.654nH 1.110pF 4 GND GND 0.041 7.469nH 0.899pF 10 GND GND 0.041 7.469nH 0.899pF 15 GND GND 0.041 7.469nH 0.899pF 21 GND GND 0.041 7.469nH 0.899pF 28 GND GND 0.041 7.469nH 0.899pF 34 GND GND 0.041 7.469nH 0.899pF 39 GND GND 0.041 7.469nH 0.899pF 45 GND GND 0.041 7.469nH 0.899pF 7 VCC POWER 0.035 6.006nH 0.748pF 18 VCC POWER 0.035 6.006nH 0.748pF 31 VCC POWER 0.035 6.006nH 0.748pF 42 VCC POWER 0.035 6.006nH 0.748pF | [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 NC NC 4 7 2 4 7 4 7 3 4 7 4 7 4 NC NC NC NC 5 4 7 4 7 6 4 7 4 7 7 NC NC NC NC 8 10 7 10 7 9 10 7 10 7 10 NC NC NC NC 11 10 7 10 7 12 10 7 10 7 13 15 18 15 18 14 15 18 15 18 15 NC NC NC NC 16 15 18 15 18 17 15 18 15 18 18 NC NC NC NC 19 21 18 21 18 20 21 18 21 18 21 NC NC NC NC 22 21 18 21 18 23 21 18 21 18 24 NC NC 21 18 25 NC NC 28 31 26 NC NC 28 31 27 NC NC 28 31 28 NC NC NC NC 29 NC NC 28 31 30 NC NC 28 31 31 NC NC NC NC 32 NC NC 34 31 33 NC NC 34 31 34 NC NC NC NC 35 NC NC 34 31 36 NC NC 34 31 37 NC NC 39 42 38 NC NC 39 42 39 NC NC NC NC 40 NC NC 39 42 41 NC NC 39 42 42 NC NC NC NC 43 NC NC 45 42 44 NC NC 45 42 45 NC NC NC NC 46 NC NC 45 42 47 NC NC 45 42 48 NC NC 45 42 | |************************************************************************** | Model LVT162244_OUT |************************************************************************** | [Model] LVT162244_OUT Model_type 3-state Polarity Inverting Enable Active-Low | | typ min max C_comp 9.25pF NA NA | |[Temperature Range] 25 -40 85 | [Voltage range] 3.3 3.0 3.6 | |************************************************************************** | [Pullup] | |Voltage I(typ) I(min) I(max) | 6.60E+00 -1.72E-01 -1.40E-01 -2.16E-01 6.50E+00 -1.70E-01 -1.38E-01 -2.12E-01 6.40E+00 -1.67E-01 -1.36E-01 -2.09E-01 6.30E+00 -1.65E-01 -1.34E-01 -2.06E-01 6.20E+00 -1.62E-01 -1.32E-01 -2.03E-01 6.10E+00 -1.59E-01 -1.29E-01 -2.00E-01 6.00E+00 -1.57E-01 -1.27E-01 -1.97E-01 5.90E+00 -1.54E-01 -1.25E-01 -1.94E-01 5.80E+00 -1.52E-01 -1.23E-01 -1.91E-01 5.70E+00 -1.49E-01 -1.20E-01 -1.88E-01 5.60E+00 -1.47E-01 -1.18E-01 -1.85E-01 5.50E+00 -1.44E-01 -1.16E-01 -1.82E-01 5.40E+00 -1.41E-01 -1.14E-01 -1.79E-01 5.30E+00 -1.39E-01 -1.11E-01 -1.76E-01 5.20E+00 -1.36E-01 -1.09E-01 -1.73E-01 5.10E+00 -1.33E-01 -1.07E-01 -1.70E-01 5.00E+00 -1.30E-01 -1.05E-01 -1.67E-01 4.90E+00 -1.27E-01 -1.02E-01 -1.63E-01 4.80E+00 -1.24E-01 -1.00E-01 -1.60E-01 4.70E+00 -1.21E-01 -9.78E-02 -1.57E-01 4.60E+00 -1.18E-01 -9.56E-02 -1.54E-01 4.50E+00 -1.15E-01 -9.33E-02 -1.51E-01 4.40E+00 -1.12E-01 -9.10E-02 -1.47E-01 4.30E+00 -1.09E-01 -8.87E-02 -1.44E-01 4.20E+00 -1.07E-01 -8.63E-02 -1.41E-01 4.10E+00 -1.04E-01 -8.39E-02 -1.38E-01 4.00E+00 -1.01E-01 -8.15E-02 -1.34E-01 3.90E+00 -9.83E-02 -7.91E-02 -1.31E-01 3.80E+00 -9.56E-02 -7.65E-02 -1.28E-01 3.70E+00 -9.30E-02 -7.38E-02 -1.25E-01 3.60E+00 -9.04E-02 -7.11E-02 -1.21E-01 3.50E+00 -8.80E-02 -6.84E-02 -1.18E-01 3.40E+00 -8.58E-02 -6.56E-02 -1.15E-01 3.30E+00 -8.37E-02 -6.29E-02 -1.11E-01 3.20E+00 -8.18E-02 -6.02E-02 -1.08E-01 3.10E+00 -7.98E-02 -5.75E-02 -1.05E-01 3.00E+00 -7.77E-02 -5.49E-02 -1.01E-01 2.90E+00 -7.56E-02 -5.23E-02 -9.79E-02 2.80E+00 -7.35E-02 -4.97E-02 -9.45E-02 2.70E+00 -7.12E-02 -4.72E-02 -9.11E-02 2.60E+00 -6.89E-02 -4.48E-02 -8.77E-02 2.50E+00 -6.66E-02 -4.25E-02 -8.44E-02 2.40E+00 -6.42E-02 -4.03E-02 -8.10E-02 2.30E+00 -6.18E-02 -3.83E-02 -7.76E-02 2.20E+00 -5.94E-02 -3.66E-02 -7.42E-02 2.10E+00 -5.69E-02 -3.53E-02 -7.08E-02 2.00E+00 -5.43E-02 -3.43E-02 -6.74E-02 1.90E+00 -5.18E-02 -3.34E-02 -6.40E-02 1.80E+00 -4.92E-02 -3.25E-02 -6.06E-02 1.70E+00 -4.66E-02 -3.14E-02 -5.72E-02 1.60E+00 -4.39E-02 -3.01E-02 -5.39E-02 1.50E+00 -4.13E-02 -2.88E-02 -5.05E-02 1.40E+00 -3.86E-02 -2.73E-02 -4.71E-02 1.30E+00 -3.59E-02 -2.58E-02 -4.37E-02 1.20E+00 -3.32E-02 -2.41E-02 -4.03E-02 1.10E+00 -3.05E-02 -2.24E-02 -3.69E-02 1.00E+00 -2.78E-02 -2.07E-02 -3.35E-02 9.00E-01 -2.50E-02 -1.88E-02 -3.01E-02 8.00E-01 -2.23E-02 -1.69E-02 -2.68E-02 7.00E-01 -1.95E-02 -1.49E-02 -2.34E-02 6.00E-01 -1.67E-02 -1.29E-02 -2.00E-02 5.00E-01 -1.40E-02 -1.09E-02 -1.67E-02 4.00E-01 -1.12E-02 -8.80E-03 -1.33E-02 3.00E-01 -8.40E-03 -6.67E-03 -1.00E-02 2.00E-01 -5.62E-03 -4.50E-03 -6.66E-03 1.00E-01 -2.82E-03 -2.29E-03 -3.34E-03 4.44E-16 7.84E-09 3.98E-08 1.52E-09 -1.00E-01 2.84E-03 2.32E-03 3.34E-03 -2.00E-01 5.69E-03 4.63E-03 6.69E-03 -3.00E-01 8.55E-03 6.97E-03 1.01E-02 -4.00E-01 1.15E-02 9.34E-03 1.35E-02 -5.00E-01 1.44E-02 1.17E-02 1.69E-02 -6.00E-01 1.73E-02 1.42E-02 2.03E-02 -7.00E-01 2.03E-02 1.66E-02 2.38E-02 -8.00E-01 2.33E-02 1.91E-02 2.72E-02 -9.00E-01 2.63E-02 2.15E-02 3.07E-02 -1.00E+00 2.94E-02 2.40E-02 3.42E-02 -1.10E+00 3.24E-02 2.65E-02 3.77E-02 -1.20E+00 3.55E-02 2.89E-02 4.13E-02 -1.30E+00 3.86E-02 3.14E-02 4.48E-02 -1.40E+00 4.16E-02 3.40E-02 4.84E-02 -1.50E+00 4.47E-02 3.65E-02 5.19E-02 -1.60E+00 4.78E-02 3.90E-02 5.55E-02 -1.70E+00 5.09E-02 4.16E-02 5.90E-02 -1.80E+00 5.40E-02 4.41E-02 6.25E-02 -1.90E+00 5.72E-02 4.67E-02 6.60E-02 -2.00E+00 6.03E-02 4.93E-02 6.95E-02 -2.10E+00 6.35E-02 5.18E-02 7.30E-02 -2.20E+00 6.66E-02 5.44E-02 7.65E-02 -2.30E+00 6.98E-02 5.70E-02 8.01E-02 -2.40E+00 7.28E-02 5.96E-02 8.37E-02 -2.50E+00 7.58E-02 6.22E-02 8.73E-02 -2.60E+00 7.88E-02 6.48E-02 9.09E-02 -2.70E+00 8.19E-02 6.74E-02 9.45E-02 -2.80E+00 8.51E-02 6.97E-02 9.81E-02 -2.90E+00 8.83E-02 7.21E-02 1.02E-01 -3.00E+00 9.15E-02 7.46E-02 1.05E-01 -3.10E+00 9.47E-02 7.73E-02 1.09E-01 -3.20E+00 9.79E-02 7.99E-02 1.13E-01 -3.30E+00 1.01E-01 8.25E-02 1.16E-01 | | [Pulldown] | |Voltage I(typ) I(min) I(max) | -3.30E+00 -7.49E-02 -7.90E-02 -7.10E-02 -3.20E+00 -7.12E-02 -7.53E-02 -6.76E-02 -3.10E+00 -6.76E-02 -7.16E-02 -6.43E-02 -3.00E+00 -6.41E-02 -6.80E-02 -6.12E-02 -2.90E+00 -6.06E-02 -6.44E-02 -5.83E-02 -2.80E+00 -5.73E-02 -6.09E-02 -5.56E-02 -2.70E+00 -5.42E-02 -5.74E-02 -5.32E-02 -2.60E+00 -5.11E-02 -5.40E-02 -5.09E-02 -2.50E+00 -4.82E-02 -5.07E-02 -4.86E-02 -2.40E+00 -4.54E-02 -4.75E-02 -4.65E-02 -2.30E+00 -4.28E-02 -4.44E-02 -4.43E-02 -2.20E+00 -4.04E-02 -4.15E-02 -4.22E-02 -2.10E+00 -3.81E-02 -3.86E-02 -4.00E-02 -2.00E+00 -3.59E-02 -3.59E-02 -3.79E-02 -1.90E+00 -3.38E-02 -3.33E-02 -3.58E-02 -1.80E+00 -3.18E-02 -3.08E-02 -3.37E-02 -1.70E+00 -2.97E-02 -2.86E-02 -3.16E-02 -1.60E+00 -2.77E-02 -2.64E-02 -2.95E-02 -1.50E+00 -2.58E-02 -2.44E-02 -2.75E-02 -1.40E+00 -2.38E-02 -2.24E-02 -2.54E-02 -1.30E+00 -2.19E-02 -2.04E-02 -2.35E-02 -1.20E+00 -2.00E-02 -1.85E-02 -2.17E-02 -1.10E+00 -1.81E-02 -1.67E-02 -1.99E-02 -1.00E+00 -1.64E-02 -1.49E-02 -1.81E-02 -9.00E-01 -1.47E-02 -1.32E-02 -1.63E-02 -8.00E-01 -1.31E-02 -1.16E-02 -1.45E-02 -7.00E-01 -1.15E-02 -1.01E-02 -1.27E-02 -6.00E-01 -9.84E-03 -8.65E-03 -1.09E-02 -5.00E-01 -8.22E-03 -7.22E-03 -9.14E-03 -4.00E-01 -6.60E-03 -5.79E-03 -7.35E-03 -3.00E-01 -4.98E-03 -4.37E-03 -5.56E-03 -2.00E-01 -3.36E-03 -2.94E-03 -3.77E-03 -1.00E-01 -1.74E-03 -1.51E-03 -1.98E-03 0.00E+00 -1.04E-04 -6.51E-05 -1.87E-04 1.00E-01 1.52E-03 1.37E-03 1.61E-03 2.00E-01 3.14E-03 2.79E-03 3.47E-03 3.00E-01 4.76E-03 4.05E-03 5.86E-03 4.00E-01 6.78E-03 6.69E-03 9.05E-03 5.00E-01 1.07E-02 1.06E-02 1.26E-02 6.00E-01 1.49E-02 1.47E-02 1.63E-02 7.00E-01 1.93E-02 1.89E-02 1.99E-02 8.00E-01 2.36E-02 2.30E-02 2.38E-02 9.00E-01 2.80E-02 2.72E-02 2.81E-02 1.00E+00 3.24E-02 3.14E-02 3.26E-02 1.10E+00 3.68E-02 3.56E-02 3.70E-02 1.20E+00 4.12E-02 3.97E-02 4.14E-02 1.30E+00 4.57E-02 4.39E-02 4.59E-02 1.40E+00 5.01E-02 4.80E-02 5.03E-02 1.50E+00 5.45E-02 5.21E-02 5.48E-02 1.60E+00 5.89E-02 5.62E-02 5.93E-02 1.70E+00 6.33E-02 6.02E-02 6.37E-02 1.80E+00 6.77E-02 6.42E-02 6.82E-02 1.90E+00 7.22E-02 6.82E-02 7.27E-02 2.00E+00 7.66E-02 7.22E-02 7.71E-02 2.10E+00 8.09E-02 7.63E-02 8.16E-02 2.20E+00 8.53E-02 8.02E-02 8.61E-02 2.30E+00 8.97E-02 8.39E-02 9.05E-02 2.40E+00 9.40E-02 8.73E-02 9.49E-02 2.50E+00 9.84E-02 9.06E-02 9.93E-02 2.60E+00 1.03E-01 9.39E-02 1.04E-01 2.70E+00 1.07E-01 9.71E-02 1.08E-01 2.80E+00 1.11E-01 1.00E-01 1.13E-01 2.90E+00 1.16E-01 1.03E-01 1.17E-01 3.00E+00 1.20E-01 1.06E-01 1.21E-01 3.10E+00 1.24E-01 1.09E-01 1.25E-01 3.20E+00 1.28E-01 1.11E-01 1.30E-01 3.30E+00 1.33E-01 1.13E-01 1.34E-01 3.40E+00 1.37E-01 1.15E-01 1.38E-01 3.50E+00 1.41E-01 1.16E-01 1.42E-01 3.60E+00 1.45E-01 1.18E-01 1.47E-01 3.70E+00 1.49E-01 1.21E-01 1.51E-01 3.80E+00 1.53E-01 1.24E-01 1.55E-01 3.90E+00 1.58E-01 1.27E-01 1.59E-01 4.00E+00 1.62E-01 1.31E-01 1.64E-01 4.10E+00 1.66E-01 1.34E-01 1.68E-01 4.20E+00 1.70E-01 1.38E-01 1.72E-01 4.30E+00 1.74E-01 1.41E-01 1.76E-01 4.40E+00 1.78E-01 1.45E-01 1.80E-01 4.50E+00 1.83E-01 1.48E-01 1.84E-01 4.60E+00 1.87E-01 1.52E-01 1.89E-01 4.70E+00 1.91E-01 1.55E-01 1.93E-01 4.80E+00 1.95E-01 1.59E-01 1.97E-01 4.90E+00 1.99E-01 1.62E-01 2.01E-01 5.00E+00 2.03E-01 1.66E-01 2.05E-01 5.10E+00 2.08E-01 1.69E-01 2.10E-01 5.20E+00 2.12E-01 1.73E-01 2.14E-01 5.30E+00 2.16E-01 1.76E-01 2.18E-01 5.40E+00 2.20E-01 1.79E-01 2.22E-01 5.50E+00 2.24E-01 1.83E-01 2.26E-01 5.60E+00 2.28E-01 1.86E-01 2.30E-01 5.70E+00 2.32E-01 1.89E-01 2.34E-01 5.80E+00 2.36E-01 1.92E-01 2.39E-01 5.90E+00 2.41E-01 1.96E-01 2.43E-01 6.00E+00 2.45E-01 1.98E-01 2.47E-01 6.10E+00 2.49E-01 2.01E-01 2.51E-01 6.20E+00 2.53E-01 2.03E-01 2.55E-01 6.30E+00 2.57E-01 2.04E-01 2.59E-01 6.40E+00 2.61E-01 2.05E-01 2.64E-01 6.50E+00 2.65E-01 2.06E-01 2.68E-01 6.60E+00 2.69E-01 2.07E-01 2.72E-01 | | [Ramp] |Variable typ min max | dV/dt_r 1.142/0.356n 0.869/0.787n 1.347/0.203n dV/dt_f 1.245/0.608n 1.124/1.169n 1.377/0.405n | |****************************************************************************** | Model LVT162244_IN |****************************************************************************** | [Model] LVT162244_IN Model_type Input Polarity Inverting Vinl = 0.8V Vinh = 2.0V | typ min max C_comp 3.25pF NA NA | [Voltage Range] 3.3 3.0 3.6 | |****************************************************************************** | [POWER_Clamp] | |Voltage I(typ) I(min) I(max) | 0.00E+00 1.32E-09 1.19E-09 1.44E-09 -3.33E-02 6.62E-09 4.81E-07 1.46E-09 -6.66E-02 8.16E-09 6.81E-07 1.48E-09 -1.00E-01 8.61E-09 7.57E-07 1.50E-09 -1.33E-01 8.75E-09 7.84E-07 1.52E-09 -1.67E-01 8.81E-09 7.94E-07 1.54E-09 -2.00E-01 8.84E-09 7.98E-07 1.56E-09 -2.33E-01 8.86E-09 7.99E-07 1.58E-09 -2.67E-01 8.88E-09 7.99E-07 1.60E-09 -3.00E-01 8.90E-09 8.00E-07 1.61E-09 -3.33E-01 8.92E-09 8.00E-07 1.63E-09 -3.67E-01 8.94E-09 8.00E-07 1.65E-09 -4.00E-01 8.96E-09 8.00E-07 1.67E-09 -4.33E-01 8.98E-09 8.00E-07 1.69E-09 -4.67E-01 8.99E-09 8.00E-07 1.71E-09 -5.00E-01 9.01E-09 8.00E-07 1.73E-09 -5.33E-01 9.03E-09 8.00E-07 1.75E-09 -5.67E-01 9.05E-09 8.00E-07 1.77E-09 -6.00E-01 9.07E-09 8.00E-07 1.78E-09 -6.33E-01 9.09E-09 8.00E-07 1.80E-09 -6.67E-01 9.11E-09 8.00E-07 1.82E-09 -7.00E-01 9.13E-09 8.00E-07 1.84E-09 -7.33E-01 9.15E-09 8.00E-07 1.86E-09 -7.67E-01 9.17E-09 8.00E-07 1.88E-09 -8.00E-01 9.19E-09 8.00E-07 1.90E-09 -8.33E-01 9.21E-09 8.00E-07 1.92E-09 -8.67E-01 9.23E-09 8.00E-07 1.94E-09 -9.00E-01 9.25E-09 8.00E-07 1.95E-09 -9.33E-01 9.27E-09 8.00E-07 1.97E-09 -9.67E-01 9.29E-09 8.00E-07 1.99E-09 -1.00E+00 9.31E-09 8.00E-07 2.01E-09 -1.03E+00 9.33E-09 8.00E-07 2.03E-09 -1.07E+00 9.34E-09 8.00E-07 2.05E-09 -1.10E+00 9.36E-09 8.00E-07 2.07E-09 -1.13E+00 9.38E-09 8.00E-07 2.09E-09 -1.17E+00 9.40E-09 8.00E-07 2.11E-09 -1.20E+00 9.42E-09 8.00E-07 2.12E-09 -1.23E+00 9.44E-09 8.00E-07 2.14E-09 -1.27E+00 9.46E-09 8.00E-07 2.16E-09 -1.30E+00 9.48E-09 8.00E-07 2.18E-09 -1.33E+00 9.50E-09 8.00E-07 2.20E-09 -1.37E+00 9.52E-09 8.00E-07 2.22E-09 -1.40E+00 9.54E-09 8.00E-07 2.24E-09 -1.43E+00 9.56E-09 8.00E-07 2.26E-09 -1.47E+00 9.58E-09 8.00E-07 2.28E-09 -1.50E+00 9.60E-09 8.00E-07 2.30E-09 -1.53E+00 9.62E-09 8.00E-07 2.32E-09 -1.57E+00 9.64E-09 8.00E-07 2.34E-09 -1.60E+00 9.66E-09 8.00E-07 2.36E-09 -1.63E+00 9.68E-09 8.01E-07 2.38E-09 -1.67E+00 9.70E-09 8.01E-07 2.40E-09 -1.70E+00 9.72E-09 8.01E-07 2.42E-09 -1.73E+00 9.74E-09 8.01E-07 2.44E-09 -1.77E+00 9.76E-09 8.01E-07 2.46E-09 -1.80E+00 9.78E-09 8.01E-07 2.48E-09 -1.83E+00 9.80E-09 8.01E-07 2.50E-09 -1.87E+00 9.82E-09 8.01E-07 2.52E-09 -1.90E+00 9.84E-09 8.01E-07 2.54E-09 -1.93E+00 9.86E-09 8.01E-07 2.56E-09 -1.97E+00 9.88E-09 8.01E-07 2.58E-09 -2.00E+00 9.90E-09 8.01E-07 2.60E-09 -2.03E+00 9.92E-09 8.01E-07 2.62E-09 -2.07E+00 9.94E-09 8.01E-07 2.64E-09 -2.10E+00 9.96E-09 8.01E-07 2.66E-09 -2.13E+00 9.98E-09 8.01E-07 2.68E-09 -2.17E+00 1.00E-08 8.01E-07 2.70E-09 -2.20E+00 1.00E-08 8.01E-07 2.72E-09 -2.23E+00 1.00E-08 8.01E-07 2.74E-09 -2.27E+00 1.01E-08 8.01E-07 2.76E-09 -2.30E+00 1.01E-08 8.01E-07 2.78E-09 -2.33E+00 1.01E-08 8.01E-07 2.80E-09 -2.37E+00 1.01E-08 8.01E-07 2.82E-09 -2.40E+00 1.01E-08 8.01E-07 2.84E-09 -2.43E+00 1.02E-08 8.01E-07 2.86E-09 -2.47E+00 1.02E-08 8.01E-07 2.88E-09 -2.50E+00 1.02E-08 8.01E-07 2.90E-09 -2.53E+00 1.02E-08 8.01E-07 2.92E-09 -2.57E+00 1.02E-08 8.01E-07 2.94E-09 -2.60E+00 1.03E-08 8.01E-07 2.96E-09 -2.63E+00 1.03E-08 8.01E-07 2.98E-09 -2.67E+00 1.03E-08 8.01E-07 3.00E-09 -2.70E+00 1.03E-08 8.01E-07 3.02E-09 -2.73E+00 1.03E-08 8.01E-07 3.04E-09 -2.77E+00 1.04E-08 8.01E-07 3.06E-09 -2.80E+00 1.04E-08 8.01E-07 3.08E-09 -2.83E+00 1.04E-08 8.01E-07 3.10E-09 -2.87E+00 1.04E-08 8.01E-07 3.12E-09 -2.90E+00 1.04E-08 8.01E-07 3.14E-09 -2.93E+00 1.05E-08 8.01E-07 3.16E-09 -2.97E+00 1.05E-08 8.01E-07 3.18E-09 -3.00E+00 1.05E-08 8.01E-07 3.20E-09 -3.03E+00 1.05E-08 8.01E-07 3.22E-09 -3.07E+00 1.05E-08 8.01E-07 3.24E-09 -3.10E+00 1.06E-08 8.01E-07 3.26E-09 -3.13E+00 1.06E-08 8.01E-07 3.28E-09 -3.17E+00 1.06E-08 8.01E-07 3.30E-09 -3.20E+00 1.06E-08 8.01E-07 3.32E-09 -3.23E+00 1.06E-08 8.01E-07 3.34E-09 -3.27E+00 1.07E-08 8.01E-07 3.36E-09 -3.30E+00 1.07E-08 8.01E-07 3.38E-09 | | [GND_Clamp] | |Voltage I(typ) I(min) I(max) | -3.30E+00 -5.19E-02 -5.27E-02 -5.17E-02 -3.23E+00 -5.04E-02 -5.12E-02 -5.01E-02 -3.17E+00 -4.89E-02 -4.98E-02 -4.86E-02 -3.10E+00 -4.74E-02 -4.83E-02 -4.71E-02 -3.03E+00 -4.60E-02 -4.69E-02 -4.56E-02 -2.97E+00 -4.45E-02 -4.54E-02 -4.41E-02 -2.90E+00 -4.30E-02 -4.40E-02 -4.26E-02 -2.83E+00 -4.16E-02 -4.25E-02 -4.11E-02 -2.77E+00 -4.01E-02 -4.11E-02 -3.96E-02 -2.70E+00 -3.87E-02 -3.97E-02 -3.82E-02 -2.63E+00 -3.73E-02 -3.83E-02 -3.67E-02 -2.57E+00 -3.58E-02 -3.69E-02 -3.52E-02 -2.50E+00 -3.44E-02 -3.55E-02 -3.38E-02 -2.43E+00 -3.30E-02 -3.41E-02 -3.23E-02 -2.37E+00 -3.16E-02 -3.27E-02 -3.09E-02 -2.30E+00 -3.02E-02 -3.13E-02 -2.94E-02 -2.23E+00 -2.88E-02 -2.99E-02 -2.80E-02 -2.17E+00 -2.74E-02 -2.85E-02 -2.66E-02 -2.10E+00 -2.60E-02 -2.71E-02 -2.51E-02 -2.03E+00 -2.46E-02 -2.58E-02 -2.37E-02 -1.97E+00 -2.32E-02 -2.44E-02 -2.23E-02 -1.90E+00 -2.19E-02 -2.31E-02 -2.09E-02 -1.83E+00 -2.05E-02 -2.17E-02 -1.95E-02 -1.77E+00 -1.92E-02 -2.04E-02 -1.81E-02 -1.70E+00 -1.78E-02 -1.91E-02 -1.67E-02 -1.63E+00 -1.65E-02 -1.78E-02 -1.54E-02 -1.57E+00 -1.52E-02 -1.64E-02 -1.40E-02 -1.50E+00 -1.38E-02 -1.51E-02 -1.26E-02 -1.43E+00 -1.25E-02 -1.39E-02 -1.13E-02 -1.37E+00 -1.12E-02 -1.26E-02 -9.96E-03 -1.30E+00 -9.95E-03 -1.13E-02 -8.64E-03 -1.23E+00 -8.68E-03 -1.00E-02 -7.34E-03 -1.17E+00 -7.42E-03 -8.79E-03 -6.06E-03 -1.10E+00 -6.19E-03 -7.56E-03 -4.83E-03 -1.03E+00 -4.98E-03 -6.35E-03 -3.64E-03 -9.67E-01 -3.81E-03 -5.17E-03 -2.51E-03 -9.00E-01 -2.69E-03 -4.02E-03 -1.48E-03 -8.33E-01 -1.67E-03 -2.92E-03 -7.03E-04 -7.67E-01 -8.18E-04 -1.90E-03 -4.19E-04 -7.00E-01 -3.29E-04 -1.02E-03 -3.63E-04 -6.33E-01 -2.00E-04 -4.08E-04 -3.25E-04 -5.67E-01 -1.68E-04 -1.57E-04 -2.88E-04 -5.00E-01 -1.46E-04 -9.74E-05 -2.52E-04 -4.33E-01 -1.26E-04 -7.85E-05 -2.16E-04 -3.67E-01 -1.05E-04 -6.51E-05 -1.81E-04 -3.00E-01 -8.52E-05 -5.26E-05 -1.47E-04 -2.33E-01 -6.56E-05 -4.05E-05 -1.13E-04 -1.67E-01 -4.64E-05 -2.86E-05 -8.00E-05 -1.00E-01 -2.77E-05 -1.71E-05 -4.76E-05 -3.33E-02 -9.20E-06 -5.70E-06 -1.58E-05 3.33E-02 9.11E-06 5.62E-06 1.57E-05 1.00E-01 2.68E-05 1.64E-05 4.64E-05 1.67E-01 4.41E-05 2.67E-05 7.68E-05 2.33E-01 6.11E-05 3.67E-05 1.07E-04 3.00E-01 7.77E-05 4.64E-05 1.37E-04 3.67E-01 9.40E-05 5.57E-05 1.66E-04 4.33E-01 1.10E-04 6.46E-05 1.95E-04 5.00E-01 1.26E-04 7.32E-05 2.24E-04 5.67E-01 1.41E-04 8.15E-05 2.52E-04 6.33E-01 1.55E-04 8.94E-05 2.80E-04 7.00E-01 1.70E-04 9.68E-05 3.07E-04 7.67E-01 1.84E-04 1.04E-04 3.33E-04 8.33E-01 1.97E-04 1.11E-04 3.58E-04 9.00E-01 2.10E-04 1.17E-04 3.82E-04 9.67E-01 2.22E-04 1.23E-04 4.04E-04 1.03E+00 2.33E-04 1.28E-04 4.25E-04 1.10E+00 2.42E-04 1.33E-04 4.43E-04 1.17E+00 2.50E-04 1.36E-04 4.59E-04 1.23E+00 2.54E-04 1.38E-04 4.72E-04 1.30E+00 2.55E-04 1.34E-04 4.81E-04 1.37E+00 2.50E-04 -5.05E-05 4.85E-04 1.43E+00 2.29E-04 -1.01E-04 4.83E-04 1.50E+00 5.45E-05 -1.03E-04 4.71E-04 1.57E+00 -1.86E-04 -1.03E-04 4.36E-04 1.63E+00 -2.04E-04 -1.01E-04 2.73E-04 1.70E+00 -2.08E-04 -9.81E-05 -7.28E-05 1.77E+00 -2.06E-04 -9.49E-05 -3.53E-04 1.83E+00 -2.01E-04 -9.14E-05 -3.81E-04 1.90E+00 -1.95E-04 -8.75E-05 -3.85E-04 1.97E+00 -1.87E-04 -8.33E-05 -3.80E-04 2.03E+00 -1.78E-04 -7.89E-05 -3.70E-04 2.10E+00 -1.68E-04 -7.41E-05 -3.57E-04 2.17E+00 -1.58E-04 -6.91E-05 -3.42E-04 2.23E+00 -1.47E-04 -6.39E-05 -3.24E-04 2.30E+00 -1.36E-04 -5.84E-05 -3.06E-04 2.37E+00 -1.25E-04 -5.27E-05 -2.86E-04 2.43E+00 -1.14E-04 -4.68E-05 -2.65E-04 2.50E+00 -1.02E-04 -4.08E-05 -2.44E-04 2.57E+00 -9.07E-05 -3.46E-05 -2.23E-04 2.63E+00 -7.92E-05 -2.83E-05 -2.01E-04 2.70E+00 -6.76E-05 -2.21E-05 -1.79E-04 2.77E+00 -5.61E-05 -1.59E-05 -1.57E-04 2.83E+00 -4.48E-05 -9.93E-06 -1.35E-04 2.90E+00 -3.36E-05 -4.68E-06 -1.13E-04 2.97E+00 -2.29E-05 -9.72E-07 -9.19E-05 3.03E+00 -1.31E-05 4.81E-07 -7.12E-05 3.10E+00 -5.06E-06 7.57E-07 -5.12E-05 3.17E+00 -9.10E-07 7.94E-07 -3.23E-05 3.23E+00 -7.98E-08 7.99E-07 -1.54E-05 3.30E+00 1.32E-09 8.00E-07 -3.56E-06 [END] Previous message: Howard Johnson: "removal from ibis list" In reply to: Raj Raghuram: "Pin Mapping in IBIS models" Reply: LiuWeidong: "Re: Pin Mapping in IBIS models" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 17:47:36 PDT