From owner-ibis Thu Jun 1 09:11:48 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA11225; Thu, 1 Jun 2000 09:11:47 -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 MAA12521; Thu, 1 Jun 2000 12:09:18 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA12195; Thu, 1 Jun 2000 12:09:16 -0400 (EDT) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA25642; Thu, 1 Jun 2000 09:09:04 -0700 (PDT) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id JAA15989; Thu, 1 Jun 2000 09:09:04 -0700 Date: Thu, 1 Jun 2000 09:09:04 -0700 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200006011609.JAA15989@f22.viewlogic.com> To: ibis-users@eda.org, ibis@eda.org Subject: IBIS Summit Meeting Agenda (June 8, 2000) ________________________________________________________________________ To All: Below is the planned agenda for the IBIS Summit Meeting to be held on Thursday June 8, 2000 during the Design Automation Conference in Los Angeles, California. The meeting consists of presentations and discussions. The meeting is free to people interested in IBIS modeling, digital circuit design and related EDA tool development. Refreshments and lunch are included. If you plan to attend, please contact Bob Ross or Guy de Burgh at the addresses below (if you haven't already done so): Bob Ross Mentor Graphics Chair, EIA IBIS Open Forum bob_ross@mentor.com Guy de Burgh Innoveda Secretary, EIA IBIS Open Forum gdeburgh@innoveda.com ________________________________________________________________________ AGENDA, IBIS SUMMIT MEETING June 8, 2000 Manhattan Room Hyatt Regency Hotel Los Angeles, California 8:30 AM REFRESHMENTS AND SIGN-IN 9:00 AM INTRODUCTIONS 9:10 AM IBIS REPORT Bob Ross, Mentor Graphics 9:30 AM INTRODUCTION TO EQUATION BASED ANALOG MODELING IN STANDARD HDL LANGUAGES (VHDL_AMS AND VERILOG) Kenneth Bakalar, Mentor Graphics 10:00 AM ELECTION OF OFFICERS AND OTHER BUSINESS 10:30 AM BREAK 10:45 AM CONNECTOR MODEL SPECIFICATION & DISCUSSION Kellee Crisafulli, HyperLynx 12:00 PM LUNCH (Provided to Attendees) 1:00 PM IBIS FUTURE DIRECTIONS UPDATE Stephen Peters, Intel 1:30 PM OVERVIEW OF XML Mike LaBonte, Cadence Design 2:00 PM MACRO LANGUAGE Al Davis, HyperLynx 2:30 PM BREAK 2:45 PM OPEN DISCUSSION AND AD HOC PRESENTATIONS - Version 4.0 Issues - IBIS Futures Issues - Next Meetings - Etc. 5:00 PM MEETING ENDS ________________________________________________________________________ From owner-ibis Wed Jun 7 10:42:55 2000 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA08932 for ; Wed, 7 Jun 2000 10:42:54 -0700 (PDT) Received: from trentonprocessors.com (user-38lc77e.dialup.mindspring.com [209.86.28.238]) by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id NAA31949 for ; Wed, 7 Jun 2000 13:40:46 -0400 (EDT) Received: from bs ([10.0.0.44]) by trentonprocessors.com ( IA Mail Server Version: 3.2.1. Build: 1084 ) ) ; Wed, 07 Jun 2000 13:39:27 -0400 Message-ID: <001401bfd0c1$cb84b240$2c00000a@bs> From: "Brian Skinner" To: Subject: UNSUBSCRIBING Date: Wed, 7 Jun 2000 13:48:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01BFD087.19178F40" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BFD087.19178F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable UNSUBSCRIBING=20 ------=_NextPart_000_0011_01BFD087.19178F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
UNSUBSCRIBING =
------=_NextPart_000_0011_01BFD087.19178F40-- From owner-ibis Fri Jun 9 11:23:52 2000 Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA19504 for ; Fri, 9 Jun 2000 11:23:51 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 55F987CF; Fri, 9 Jun 2000 14:21:19 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 48D92426 for ; Fri, 9 Jun 2000 14:21:19 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 14:21:18 -0400 Message-ID: <212CC57E84B8D111AD780000F84AA0490948402C@mroexc2.tay.dec.com> From: "Ingraham, Andrew" To: "'ibis-users'" Subject: Can I-V data be unsorted? Date: Fri, 9 Jun 2000 14:21:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Is there any requirement to list V/I data in order of increasing table voltage values? From what I can tell, there is no need to even sort the data, let alone have it in ascending order. The only mention I saw in the spec that seems related, is that "numeric values (in the typical current column) MUST be specified for the first and last voltage points on any I-V table." This probably should have been worded, "lowest and highest voltage points" rather than "first and last." Or does it really mean that the first and last lines in each table always represent the voltage endpoints? Regards, Andy From owner-ibis Mon Jun 12 16:42:41 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA04750 for ; Mon, 12 Jun 2000 16:42:40 -0700 (PDT) Received: from exgw.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA04359; Mon, 12 Jun 2000 16:40:07 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by exgw.wv.mentorg.com (8.8.8/CF5.33R) id QAA03532; Mon, 12 Jun 2000 16:40:06 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 16:32:20 -0700 Message-ID: <2179BC5B6583D311B44700508B4414697E3A80@svr-orw-exc-02.wv.mentorg.com> From: "Dunbar, Tony" To: "'ibis-users@eda.org'" Subject: RE: Can I-V data be unsorted? Date: Mon, 12 Jun 2000 16:32:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD4C6.6ECAA290" 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_01BFD4C6.6ECAA290 Content-Type: text/plain; charset="iso-8859-1" Andrew, Did you experiment with any real .ibs files by re-arranging the V-I table rows? I found that ibischk3 flags non-monotonic data when the lines are jumbled and it also had the repercussion of causing a bogus warning about the buffer being unable to drive through the Vmeas level. I think this alone is a good enough indication that the data should be ordered (sorted). However, I don't believe there is any requirement to order in increasing or decreasing order. It seems most models are ordered from -ve to +ve (e.g. -3.3V to +6.6V) but I have seen a few that go the other way and they don't give any problems (except to the human eye parser that kind-of expects them to go the other way). On the lighter side, the state of many models out there are bad enough without giving their creators an idea that they could jumble the data up as they please!! Was your question based on generalities or clarification of the spec., or do you have a specific .ibs file that's an issue to you? Regards, Tony Dunbar Mentor Graphics -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Friday, June 09, 2000 1:21 PM To: 'ibis-users' Subject: Can I-V data be unsorted? Is there any requirement to list V/I data in order of increasing table voltage values? From what I can tell, there is no need to even sort the data, let alone have it in ascending order. The only mention I saw in the spec that seems related, is that "numeric values (in the typical current column) MUST be specified for the first and last voltage points on any I-V table." This probably should have been worded, "lowest and highest voltage points" rather than "first and last." Or does it really mean that the first and last lines in each table always represent the voltage endpoints? Regards, Andy ------_=_NextPart_001_01BFD4C6.6ECAA290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Can I-V data be unsorted?

Andrew,

Did you experiment with any real .ibs files by = re-arranging the V-I table rows? I found that ibischk3 flags = non-monotonic data when the lines are jumbled and it also had the = repercussion of causing a bogus warning about the buffer being unable = to drive through the Vmeas level.

I think this alone is a good enough indication that = the data should be ordered (sorted). However, I don't believe there is = any requirement to order in increasing or decreasing order. It seems = most models are ordered from -ve to +ve (e.g. -3.3V to +6.6V) but I = have seen a few that go the other way and they don't give any problems = (except to the human eye parser that kind-of expects them to go the = other way).

On the lighter side, the state of many models out = there are bad enough without giving their creators an idea that they = could jumble the data up as they please!!

Was your question based on generalities or = clarification of the spec., or do you have a specific .ibs file that's = an issue to you?

Regards,
Tony Dunbar
Mentor Graphics

-----Original Message-----
From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq= .com]
Sent: Friday, June 09, 2000 1:21 PM
To: 'ibis-users'
Subject: Can I-V data be unsorted?


Is there any requirement to list V/I data in order of = increasing table
voltage values?

From what I can tell, there is no need to even sort = the data, let alone have
it in ascending order.  The only mention I saw = in the spec that seems
related, is that "numeric values (in the = typical current column) MUST be
specified for the first and last voltage points on = any I-V table."  This
probably should have been worded, "lowest and = highest voltage points" rather
than "first and last."  Or does it = really mean that the first and last lines
in each table always represent the voltage = endpoints?

Regards,
Andy

------_=_NextPart_001_01BFD4C6.6ECAA290-- From owner-ibis Tue Jun 13 07:33:56 2000 Received: from proxy.tellabs.fi (proxy.tellabs.fi [193.65.253.34]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA14423 for ; Tue, 13 Jun 2000 07:33:55 -0700 (PDT) Received: from notesmail.tellabs.fi (notesmail.tellabs.fi [193.64.171.119]) by proxy.tellabs.fi (8.8.8/8.8.8) with SMTP id RAA22018 for ; Tue, 13 Jun 2000 17:31:19 +0300 (EET DST) Received: by notesmail.tellabs.fi(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C22568FD.004F3D12 ; Tue, 13 Jun 2000 17:25:29 +0300 X-Lotus-FromDomain: MARTIS From: "Olli Timonen" To: ibis-users@eda.org Message-ID: Date: Tue, 13 Jun 2000 17:35:29 +0300 Subject: What is the difference between C_comp and C_pin? Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id HAA14424 Hi! I am a bit confused with C_comp. As I understand it, C_comp comprise all the capacitance of a die seen from the pad. What is then the purpose of C_pin (or C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? Does simulator sum C_comp and C_pin together or does C_comp override C_pin or...? From owner-ibis Tue Jun 13 17:30:37 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA17128 for ; Tue, 13 Jun 2000 17:30:36 -0700 (PDT) Received: from exgw.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA26907; Tue, 13 Jun 2000 17:28:03 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by exgw.wv.mentorg.com (8.8.8/CF5.33R) id RAA00250; Tue, 13 Jun 2000 17:28:03 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 17:20:14 -0700 Message-ID: <2179BC5B6583D311B44700508B4414697E3A84@svr-orw-exc-02.wv.mentorg.com> From: "Dunbar, Tony" To: "'ibis-users@eda.org'" Subject: RE: What is the difference between C_comp and C_pin? Date: Tue, 13 Jun 2000 17:20:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD596.4F4F48F0" 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_01BFD596.4F4F48F0 Content-Type: text/plain; charset="iso-8859-1" Olli, There are some REAL experts on IBIS out there that I hope will jump in and answer your questions and, perhaps, correct and add to mine. Here goes: You are correct - as you wrote, "C_comp comprises all of the capacitance of a die seen from the pad." C_pin (or C_pkg, if C_pin is not defined) is the capacitance of the packaging and interconnect that the die is packaged in (if it is packaged). Suppose the same die is available in a couple or more different packages (e.g. plastic or ceramic, SSOP or PQFP), then "good" .ibs files for each should be expected to have the same values of C_comp but different values of C_pkg/C_pin. If you were mounting the bare die on an MCM, C_pkg/C_pin (and L_pkg/L_pin and R_pkg/R_pin) would be totally different again. At the end of this text I have appended an example from the Interconnectix Standard Library. The example is an AMD PAL. The basic silicon is the AmPAL18P8 but in two different packages. Hence, the library .ibs file has [Component] AmPAL18P8BP and [Component] AmPAL18P8BJ. Please see how C_pkg/C_pin differ but C_comp is the same. Please also note the significant C, L and R value differences between the packages. For faster and faster edge rates, these packaging effects cannot be ignored and they could make the difference between a working design and a non-working design. One thing that's worth noting that might give an indication of the separate nature of C_pkg/C_pin and C_comp is that C_pkg/C_pin are [Component] or [Package] sub-parameters in the IBIS file but C_comp is a [Model] sub-parameter. So, C_pin is not supposed to be part of C_comp. Where they are often effectively included together is in a component datasheet. Most times, the vendor quotes a total pin capacitance value. Sometimes, it is required to reverse engineer an IBIS file for a component using the datasheet, perhaps with a V-I curve printed on the datasheet. You may then wish to create a C_pkg element and a C_comp element from the Ctotal number. A rule of thumb to work to that I got from Bob Ross is to apportion the Ctotal something like C_comp=(Ctotal*0.85) and C_pkg=(Ctotal*0.15). Again, others PLEASE comment. In general, an IBIS simulator should not sum (or lump) C_pkg/C_pin with C_comp because, in the general case, there are other interconnect circuit elements between them (e.g. L_pkg and R_pkg) and summing them directly together would be like collapsing a distributed element network into a lumped one. Sometimes that gets you close enough, but not always. This may be a simulator time-step and resolution issue. This is an important fine detail aspect that I invite the simulator experts to comment on. I hope this helps and stimulates other comments. Here's the example data: [Component] AmPAL18P8BJ [Manufacturer] AMD [Package] | variable typ min max R_pkg .078ohms NA NA L_pkg 3.58nH NA NA C_pkg .884pF NA NA | [Pin] signal_name model_name R_pin L_pin C_pin | 1 I Z188249_IN .076 3.3n .8p 2 I Z188249_IN .078 3.5n .87p 3 I Z188249_IN .08 3.8n .94p 4 I Z188249_IN .08 3.8n .94p 5 I Z188249_IN .078 3.5n .87p 6 I Z188249_IN .076 3.3n .8p 7 I Z188249_IN .078 3.5n .87p 8 I Z188249_IN .08 3.8n .94p 9 I Z188249_IN .08 3.8n .94p 10 GND GND .078 3.5n .87p 11 I Z188249_IN .076 3.3n .8p 12 I/O Z188249_BI .078 3.5n .87p 13 I/O Z188249_BI .08 3.8n .94p 14 I/O Z188249_BI .08 3.8n .94p 15 I/O Z188249_BI .078 3.5n .87p 16 I/O Z188249_BI .076 3.3n .8p 17 I/O Z188249_BI .078 3.5n .87p 18 I/O Z188249_BI .08 3.8n .94p 19 I/O Z188249_BI .08 3.8n .94p 20 VCC POWER .078 3.5n .87p ... [Model] Z188249_BI Model_type I/O Vinl=800.0mV Vinh=2.000V Vref=3.305V Rref=132.2ohms Cref=50.00pF Vmeas=1.500V C_comp 8.000pF NA NA | ... [Component] AmPAL18P8BP [Manufacturer] AMD [Package] | variable typ min max R_pkg .216ohms NA NA L_pkg 5.76nH NA NA C_pkg 1.29pF NA NA | [Pin] signal_name model_name R_pin L_pin C_pin | 1 I Z188250_IN .232 9.76n 1.87p 2 I Z188250_IN .224 7.26n 1.58p 3 I Z188250_IN .216 5.26n 1.29p 4 I Z188250_IN .208 3.76n 1.0p 5 I Z188250_IN .2 2.76n .71p 6 I Z188250_IN .2 2.76n .71p 7 I Z188250_IN .208 3.76n 1.0p 8 I Z188250_IN .216 5.26n 1.29p 9 I Z188250_IN .224 7.26n 1.58p 10 GND GND .232 9.76n 1.87p 11 I Z188250_IN .232 9.76n 1.87p 12 I/O Z188250_BI .224 7.26n 1.58p 13 I/O Z188250_BI .216 5.26n 1.29p 14 I/O Z188250_BI .208 3.76n 1.0p 15 I/O Z188250_BI .2 2.76n .71p 16 I/O Z188250_BI .2 2.76n .71p 17 I/O Z188250_BI .208 3.76n 1.0p 18 I/O Z188250_BI .216 5.26n 1.29p 19 I/O Z188250_BI .224 7.26n 1.58p 20 VCC POWER .232 9.76n 1.87p ... [Model] Z188250_BI Model_type I/O Vinl=800.0mV Vinh=2.000V Vref=3.305V Rref=132.2ohms Cref=50.00pF Vmeas=1.500V C_comp 8.000pF NA NA ... [End] Regards, Tony Dunbar Mentor Graphics/ICX -----Original Message----- From: Olli Timonen [mailto:Olli.Timonen@tellabs.fi] Sent: Tuesday, June 13, 2000 9:35 AM To: ibis-users@eda.org Subject: What is the difference between C_comp and C_pin? Hi! I am a bit confused with C_comp. As I understand it, C_comp comprise all the capacitance of a die seen from the pad. What is then the purpose of C_pin (or C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? Does simulator sum C_comp and C_pin together or does C_comp override C_pin or...? ------_=_NextPart_001_01BFD596.4F4F48F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: What is the difference between C_comp and C_pin?

Olli,

There are some REAL experts on IBIS out there that I = hope will jump in and answer your questions and, perhaps, correct and = add to mine. Here goes:

You are correct - as you wrote, "C_comp = comprises all of the capacitance of a die seen from the pad." = C_pin (or C_pkg, if C_pin is not defined) is the capacitance of the = packaging and interconnect that the die is packaged in (if it is = packaged). Suppose the same die is available in a couple or more = different packages (e.g. plastic or ceramic, SSOP or PQFP), then = "good" .ibs files for each should be expected to have the = same values of C_comp but different values of C_pkg/C_pin. If you were = mounting the bare die on an MCM, C_pkg/C_pin (and L_pkg/L_pin and = R_pkg/R_pin) would be totally different again. At the end of this text = I have appended an example from the Interconnectix Standard Library. = The example is an AMD PAL. The basic silicon is the AmPAL18P8 but in = two different packages. Hence, the library .ibs file has [Component] = AmPAL18P8BP and [Component] AmPAL18P8BJ. Please see how C_pkg/C_pin = differ but C_comp is the same. Please also note the significant C, L = and R value differences between the packages. For faster and faster = edge rates, these packaging effects cannot be ignored and they could = make the difference between a working design and a non-working = design.

One thing that's worth noting that might give an = indication of the separate nature of C_pkg/C_pin and C_comp is that = C_pkg/C_pin are [Component] or [Package] sub-parameters in the IBIS = file but C_comp is a [Model] sub-parameter.

So, C_pin is not supposed to be part of C_comp. Where = they are often effectively included together is in a component = datasheet. Most times, the vendor quotes a total pin capacitance value. = Sometimes, it is required to reverse engineer an IBIS file for a = component using the datasheet, perhaps with a V-I curve printed on the = datasheet. You may then wish to create a C_pkg element and a C_comp = element from the Ctotal number. A rule of thumb to work to that I got = from Bob Ross is to apportion the Ctotal something like = C_comp=3D(Ctotal*0.85) and C_pkg=3D(Ctotal*0.15). Again, others PLEASE = comment.

In general, an IBIS simulator should not sum (or = lump) C_pkg/C_pin with C_comp because, in the general case, there are = other interconnect circuit elements between them (e.g. L_pkg and R_pkg) = and summing them directly together would be like collapsing a = distributed element network into a lumped one. Sometimes that gets you = close enough, but not always. This may be a simulator time-step and = resolution issue. This is an important fine detail aspect that I invite = the simulator experts to comment on.

I hope this helps and stimulates other comments. = Here's the example data:

[Component] AmPAL18P8BJ
[Manufacturer] AMD
[Package]
| variable   typ   = min   max
R_pkg  .078ohms NA NA
L_pkg  3.58nH NA NA
C_pkg  .884pF NA NA
|
[Pin] signal_name  model_name  R_pin  = L_pin C_pin
|
1 I Z188249_IN .076 3.3n .8p
2 I Z188249_IN .078 3.5n .87p
3 I Z188249_IN .08 3.8n .94p
4 I Z188249_IN .08 3.8n .94p
5 I Z188249_IN .078 3.5n .87p
6 I Z188249_IN .076 3.3n .8p
7 I Z188249_IN .078 3.5n .87p
8 I Z188249_IN .08 3.8n .94p
9 I Z188249_IN .08 3.8n .94p
10 GND GND .078 3.5n .87p
11 I Z188249_IN .076 3.3n .8p
12 I/O Z188249_BI .078 3.5n .87p
13 I/O Z188249_BI .08 3.8n .94p
14 I/O Z188249_BI .08 3.8n .94p
15 I/O Z188249_BI .078 3.5n .87p
16 I/O Z188249_BI .076 3.3n .8p
17 I/O Z188249_BI .078 3.5n .87p
18 I/O Z188249_BI .08 3.8n .94p
19 I/O Z188249_BI .08 3.8n .94p
20 VCC POWER .078 3.5n .87p
...
[Model] Z188249_BI
Model_type I/O
Vinl=3D800.0mV
Vinh=3D2.000V
Vref=3D3.305V
Rref=3D132.2ohms
Cref=3D50.00pF
Vmeas=3D1.500V
C_comp 8.000pF NA NA
|
...
[Component] AmPAL18P8BP
[Manufacturer] AMD
[Package]
| variable   typ   = min   max
R_pkg  .216ohms NA NA
L_pkg  5.76nH NA NA
C_pkg  1.29pF NA NA
|
[Pin] signal_name  model_name  R_pin  = L_pin C_pin
|
1 I Z188250_IN .232 9.76n 1.87p
2 I Z188250_IN .224 7.26n 1.58p
3 I Z188250_IN .216 5.26n 1.29p
4 I Z188250_IN .208 3.76n 1.0p
5 I Z188250_IN .2 2.76n .71p
6 I Z188250_IN .2 2.76n .71p
7 I Z188250_IN .208 3.76n 1.0p
8 I Z188250_IN .216 5.26n 1.29p
9 I Z188250_IN .224 7.26n 1.58p
10 GND GND .232 9.76n 1.87p
11 I Z188250_IN .232 9.76n 1.87p
12 I/O Z188250_BI .224 7.26n 1.58p
13 I/O Z188250_BI .216 5.26n 1.29p
14 I/O Z188250_BI .208 3.76n 1.0p
15 I/O Z188250_BI .2 2.76n .71p
16 I/O Z188250_BI .2 2.76n .71p
17 I/O Z188250_BI .208 3.76n 1.0p
18 I/O Z188250_BI .216 5.26n 1.29p
19 I/O Z188250_BI .224 7.26n 1.58p
20 VCC POWER .232 9.76n 1.87p
...
[Model] Z188250_BI
Model_type I/O
Vinl=3D800.0mV
Vinh=3D2.000V
Vref=3D3.305V
Rref=3D132.2ohms
Cref=3D50.00pF
Vmeas=3D1.500V
C_comp 8.000pF NA NA
...
[End]

Regards,
Tony Dunbar
Mentor Graphics/ICX

-----Original Message-----
From: Olli Timonen [mailto:Olli.Timonen@tellabs.fi]
Sent: Tuesday, June 13, 2000 9:35 AM
To: ibis-users@eda.org
Subject: What is the difference between C_comp and = C_pin?


Hi!
I am a bit confused with C_comp. As I understand it, = C_comp comprise all the
capacitance of a die seen from the pad. What is then = the purpose of C_pin (or
C_pkg if not defined)? Isn?t capacitance of C_pin = included in C_comp? Does
simulator sum C_comp and C_pin together or does = C_comp override C_pin or...?

------_=_NextPart_001_01BFD596.4F4F48F0-- From owner-ibis Wed Jun 14 06:57:25 2000 Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA19724 for ; Wed, 14 Jun 2000 06:57:23 -0700 (PDT) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id JAA28106 for ; Wed, 14 Jun 2000 09:48:51 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdIAA7kcMc_; Wed Jun 14 09:48:44 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ibis-users@eda.org; Wed, 14 Jun 2000 09:54:49 -0400 Received: from newbridge.com ([138.120.118.113]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA60CE for ; Wed, 14 Jun 2000 09:54:10 -0400 Message-Id: <39478EB1.C757EDFD@newbridge.com> Date: Wed, 14 Jun 2000 09:54:58 -0400 From: "DORIN OPREA" Organization: Newbridge Networks Corporation X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'ibis-users@eda.org'" Subject: Re: What is the difference between C_comp and C_pin? References: <2179BC5B6583D311B44700508B4414697E3A84@svr-orw-exc-02.wv.mentorg.com> Content-Type: multipart/alternative; boundary="------------BA8A50D88A18D75900120BDE" --------------BA8A50D88A18D75900120BDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is C_comp a parameter characterizing the chip (good for power-ground bounce) and is also a parasitic on the buffer output (bad for signal speed) or is only the parasitic on the buffer output ? Thanks "Dunbar, Tony" wrote: > > > Olli, > > There are some REAL experts on IBIS out there that I hope will jump in > and answer your questions and, perhaps, correct and add to mine. Here > goes: > > You are correct - as you wrote, "C_comp comprises all of the > capacitance of a die seen from the pad." C_pin (or C_pkg, if C_pin is > not defined) is the capacitance of the packaging and interconnect that > the die is packaged in (if it is packaged). Suppose the same die is > available in a couple or more different packages (e.g. plastic or > ceramic, SSOP or PQFP), then "good" .ibs files for each should be > expected to have the same values of C_comp but different values of > C_pkg/C_pin. If you were mounting the bare die on an MCM, C_pkg/C_pin > (and L_pkg/L_pin and R_pkg/R_pin) would be totally different again. At > the end of this text I have appended an example from the > Interconnectix Standard Library. The example is an AMD PAL. The basic > silicon is the AmPAL18P8 but in two different packages. Hence, the > library .ibs file has [Component] AmPAL18P8BP and [Component] > AmPAL18P8BJ. Please see how C_pkg/C_pin differ but C_comp is the same. > Please also note the significant C, L and R value differences between > the packages. For faster and faster edge rates, these packaging > effects cannot be ignored and they could make the difference between a > working design and a non-working design. > > One thing that's worth noting that might give an indication of the > separate nature of C_pkg/C_pin and C_comp is that C_pkg/C_pin are > [Component] or [Package] sub-parameters in the IBIS file but C_comp is > a [Model] sub-parameter. > > So, C_pin is not supposed to be part of C_comp. Where they are often > effectively included together is in a component datasheet. Most times, > the vendor quotes a total pin capacitance value. Sometimes, it is > required to reverse engineer an IBIS file for a component using the > datasheet, perhaps with a V-I curve printed on the datasheet. You may > then wish to create a C_pkg element and a C_comp element from the > Ctotal number. A rule of thumb to work to that I got from Bob Ross is > to apportion the Ctotal something like C_comp=(Ctotal*0.85) and > C_pkg=(Ctotal*0.15). Again, others PLEASE comment. > > In general, an IBIS simulator should not sum (or lump) C_pkg/C_pin > with C_comp because, in the general case, there are other interconnect > circuit elements between them (e.g. L_pkg and R_pkg) and summing them > directly together would be like collapsing a distributed element > network into a lumped one. Sometimes that gets you close enough, but > not always. This may be a simulator time-step and resolution issue. > This is an important fine detail aspect that I invite the simulator > experts to comment on. > > I hope this helps and stimulates other comments. Here's the example > data: > > [Component] AmPAL18P8BJ > [Manufacturer] AMD > [Package] > | variable typ min max > R_pkg .078ohms NA NA > L_pkg 3.58nH NA NA > C_pkg .884pF NA NA > | > [Pin] signal_name model_name R_pin L_pin C_pin > | > 1 I Z188249_IN .076 3.3n .8p > 2 I Z188249_IN .078 3.5n .87p > 3 I Z188249_IN .08 3.8n .94p > 4 I Z188249_IN .08 3.8n .94p > 5 I Z188249_IN .078 3.5n .87p > 6 I Z188249_IN .076 3.3n .8p > 7 I Z188249_IN .078 3.5n .87p > 8 I Z188249_IN .08 3.8n .94p > 9 I Z188249_IN .08 3.8n .94p > 10 GND GND .078 3.5n .87p > 11 I Z188249_IN .076 3.3n .8p > 12 I/O Z188249_BI .078 3.5n .87p > 13 I/O Z188249_BI .08 3.8n .94p > 14 I/O Z188249_BI .08 3.8n .94p > 15 I/O Z188249_BI .078 3.5n .87p > 16 I/O Z188249_BI .076 3.3n .8p > 17 I/O Z188249_BI .078 3.5n .87p > 18 I/O Z188249_BI .08 3.8n .94p > 19 I/O Z188249_BI .08 3.8n .94p > 20 VCC POWER .078 3.5n .87p > ... > [Model] Z188249_BI > Model_type I/O > Vinl=800.0mV > Vinh=2.000V > Vref=3.305V > Rref=132.2ohms > Cref=50.00pF > Vmeas=1.500V > C_comp 8.000pF NA NA > | > ... > [Component] AmPAL18P8BP > [Manufacturer] AMD > [Package] > | variable typ min max > R_pkg .216ohms NA NA > L_pkg 5.76nH NA NA > C_pkg 1.29pF NA NA > | > [Pin] signal_name model_name R_pin L_pin C_pin > | > 1 I Z188250_IN .232 9.76n 1.87p > 2 I Z188250_IN .224 7.26n 1.58p > 3 I Z188250_IN .216 5.26n 1.29p > 4 I Z188250_IN .208 3.76n 1.0p > 5 I Z188250_IN .2 2.76n .71p > 6 I Z188250_IN .2 2.76n .71p > 7 I Z188250_IN .208 3.76n 1.0p > 8 I Z188250_IN .216 5.26n 1.29p > 9 I Z188250_IN .224 7.26n 1.58p > 10 GND GND .232 9.76n 1.87p > 11 I Z188250_IN .232 9.76n 1.87p > 12 I/O Z188250_BI .224 7.26n 1.58p > 13 I/O Z188250_BI .216 5.26n 1.29p > 14 I/O Z188250_BI .208 3.76n 1.0p > 15 I/O Z188250_BI .2 2.76n .71p > 16 I/O Z188250_BI .2 2.76n .71p > 17 I/O Z188250_BI .208 3.76n 1.0p > 18 I/O Z188250_BI .216 5.26n 1.29p > 19 I/O Z188250_BI .224 7.26n 1.58p > 20 VCC POWER .232 9.76n 1.87p > ... > [Model] Z188250_BI > Model_type I/O > Vinl=800.0mV > Vinh=2.000V > Vref=3.305V > Rref=132.2ohms > Cref=50.00pF > Vmeas=1.500V > C_comp 8.000pF NA NA > ... > [End] > > Regards, > Tony Dunbar > Mentor Graphics/ICX > > -----Original Message----- > From: Olli Timonen [mailto:Olli.Timonen@tellabs.fi] > Sent: Tuesday, June 13, 2000 9:35 AM > To: ibis-users@eda.org > Subject: What is the difference between C_comp and C_pin? > > Hi! > I am a bit confused with C_comp. As I understand it, C_comp comprise > all the > capacitance of a die seen from the pad. What is then the purpose of > C_pin (or > C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? > Does > simulator sum C_comp and C_pin together or does C_comp override C_pin > or...? --------------BA8A50D88A18D75900120BDE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Is  C_comp a  parameter characterizing the chip (good for  power-ground bounce) and
 is also a  parasitic on the buffer output (bad for signal speed) or is only the parasitic on the buffer output ?

Thanks
 
 
 

"Dunbar, Tony" wrote:

 

Olli,

There are some REAL experts on IBIS out there that I hope will jump in and answer your questions and, perhaps, correct and add to mine. Here goes:

You are correct - as you wrote, "C_comp comprises all of the capacitance of a die seen from the pad." C_pin (or C_pkg, if C_pin is not defined) is the capacitance of the packaging and interconnect that the die is packaged in (if it is packaged). Suppose the same die is available in a couple or more different packages (e.g. plastic or ceramic, SSOP or PQFP), then "good" .ibs files for each should be expected to have the same values of C_comp but different values of C_pkg/C_pin. If you were mounting the bare die on an MCM, C_pkg/C_pin (and L_pkg/L_pin and R_pkg/R_pin) would be totally different again. At the end of this text I have appended an example from the Interconnectix Standard Library. The example is an AMD PAL. The basic silicon is the AmPAL18P8 but in two different packages. Hence, the library .ibs file has [Component] AmPAL18P8BP and [Component] AmPAL18P8BJ. Please see how C_pkg/C_pin differ but C_comp is the same. Please also note the significant C, L and R value differences between the packages. For faster and faster edge rates, these packaging effects cannot be ignored and they could make the difference between a working design and a non-working design.

One thing that's worth noting that might give an indication of the separate nature of C_pkg/C_pin and C_comp is that C_pkg/C_pin are [Component] or [Package] sub-parameters in the IBIS file but C_comp is a [Model] sub-parameter.

So, C_pin is not supposed to be part of C_comp. Where they are often effectively included together is in a component datasheet. Most times, the vendor quotes a total pin capacitance value. Sometimes, it is required to reverse engineer an IBIS file for a component using the datasheet, perhaps with a V-I curve printed on the datasheet. You may then wish to create a C_pkg element and a C_comp element from the Ctotal number. A rule of thumb to work to that I got from Bob Ross is to apportion the Ctotal something like C_comp=(Ctotal*0.85) and C_pkg=(Ctotal*0.15). Again, others PLEASE comment.

In general, an IBIS simulator should not sum (or lump) C_pkg/C_pin with C_comp because, in the general case, there are other interconnect circuit elements between them (e.g. L_pkg and R_pkg) and summing them directly together would be like collapsing a distributed element network into a lumped one. Sometimes that gets you close enough, but not always. This may be a simulator time-step and resolution issue. This is an important fine detail aspect that I invite the simulator experts to comment on.

I hope this helps and stimulates other comments. Here's the example data:

[Component] AmPAL18P8BJ
[Manufacturer] AMD
[Package]
| variable   typ   min   max
R_pkg  .078ohms NA NA
L_pkg  3.58nH NA NA
C_pkg  .884pF NA NA
|
[Pin] signal_name  model_name  R_pin  L_pin C_pin
|
1 I Z188249_IN .076 3.3n .8p
2 I Z188249_IN .078 3.5n .87p
3 I Z188249_IN .08 3.8n .94p
4 I Z188249_IN .08 3.8n .94p
5 I Z188249_IN .078 3.5n .87p
6 I Z188249_IN .076 3.3n .8p
7 I Z188249_IN .078 3.5n .87p
8 I Z188249_IN .08 3.8n .94p
9 I Z188249_IN .08 3.8n .94p
10 GND GND .078 3.5n .87p
11 I Z188249_IN .076 3.3n .8p
12 I/O Z188249_BI .078 3.5n .87p
13 I/O Z188249_BI .08 3.8n .94p
14 I/O Z188249_BI .08 3.8n .94p
15 I/O Z188249_BI .078 3.5n .87p
16 I/O Z188249_BI .076 3.3n .8p
17 I/O Z188249_BI .078 3.5n .87p
18 I/O Z188249_BI .08 3.8n .94p
19 I/O Z188249_BI .08 3.8n .94p
20 VCC POWER .078 3.5n .87p
...
[Model] Z188249_BI
Model_type I/O
Vinl=800.0mV
Vinh=2.000V
Vref=3.305V
Rref=132.2ohms
Cref=50.00pF
Vmeas=1.500V
C_comp 8.000pF NA NA
|
...
[Component] AmPAL18P8BP
[Manufacturer] AMD
[Package]
| variable   typ   min   max
R_pkg  .216ohms NA NA
L_pkg  5.76nH NA NA
C_pkg  1.29pF NA NA
|
[Pin] signal_name  model_name  R_pin  L_pin C_pin
|
1 I Z188250_IN .232 9.76n 1.87p
2 I Z188250_IN .224 7.26n 1.58p
3 I Z188250_IN .216 5.26n 1.29p
4 I Z188250_IN .208 3.76n 1.0p
5 I Z188250_IN .2 2.76n .71p
6 I Z188250_IN .2 2.76n .71p
7 I Z188250_IN .208 3.76n 1.0p
8 I Z188250_IN .216 5.26n 1.29p
9 I Z188250_IN .224 7.26n 1.58p
10 GND GND .232 9.76n 1.87p
11 I Z188250_IN .232 9.76n 1.87p
12 I/O Z188250_BI .224 7.26n 1.58p
13 I/O Z188250_BI .216 5.26n 1.29p
14 I/O Z188250_BI .208 3.76n 1.0p
15 I/O Z188250_BI .2 2.76n .71p
16 I/O Z188250_BI .2 2.76n .71p
17 I/O Z188250_BI .208 3.76n 1.0p
18 I/O Z188250_BI .216 5.26n 1.29p
19 I/O Z188250_BI .224 7.26n 1.58p
20 VCC POWER .232 9.76n 1.87p
...
[Model] Z188250_BI
Model_type I/O
Vinl=800.0mV
Vinh=2.000V
Vref=3.305V
Rref=132.2ohms
Cref=50.00pF
Vmeas=1.500V
C_comp 8.000pF NA NA
...
[End]

Regards,
Tony Dunbar
Mentor Graphics/ICX

-----Original Message-----
From: Olli Timonen [mailto:Olli.Timonen@tellabs.fi]
Sent: Tuesday, June 13, 2000 9:35 AM
To: ibis-users@eda.org
Subject: What is the difference between C_comp and C_pin?

Hi!
I am a bit confused with C_comp. As I understand it, C_comp comprise all the
capacitance of a die seen from the pad. What is then the purpose of C_pin (or
C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? Does
simulator sum C_comp and C_pin together or does C_comp override C_pin or...?

--------------BA8A50D88A18D75900120BDE-- From owner-ibis Wed Jun 14 08:35:09 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA20195 for ; Wed, 14 Jun 2000 08:35:08 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA19357; Wed, 14 Jun 2000 15:33:55 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 14 Jun 2000 15:33:03 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 08:33:02 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512706458BDD@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'DORIN OPREA'" Cc: "'ibis-users@eda.org'" Subject: RE: What is the difference between C_comp and C_pin? Date: Wed, 14 Jun 2000 08:32:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD615.D242ECC8" 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_01BFD615.D242ECC8 Content-Type: text/plain; charset="windows-1252" Theoretically it should have an effect on both. The problem is that in the current IBIS specification there is no mention about where the C_comp is connected. Here is what I mean: Consider a complementary buffer which has both pullup and pulldown transistors. Both of these transistors have a parasitic capacitance between drain and source. These capacitors can be viewed as two series capacitors between power and ground. However, the midpoint is connected to the pad. So it will effect the signal as well as power/ground bounce, plus act as an on die decoupling capacitance. The problem is that because IBIS doesn't tell you how C_comp supposed to be divided up between power and ground, most implementations just put it between the pad and ground. This may load the signal, but will not account for the supply bounce correctly. There is a BIRD which addresses this issue which I hope will be voted on soon. Arpad Muranyi Intel Corporation ============================================================================ === -----Original Message----- From: DORIN OPREA [mailto:dorin.oprea@alcatel.com] Sent: Wednesday, June 14, 2000 6:55 AM Cc: 'ibis-users@eda.org' Subject: Re: What is the difference between C_comp and C_pin? Is C_comp a parameter characterizing the chip (good for power-ground bounce) and is also a parasitic on the buffer output (bad for signal speed) or is only the parasitic on the buffer output ? Thanks "Dunbar, Tony" wrote: Olli, There are some REAL experts on IBIS out there that I hope will jump in and answer your questions and, perhaps, correct and add to mine. Here goes: You are correct - as you wrote, "C_comp comprises all of the capacitance of a die seen from the pad." C_pin (or C_pkg, if C_pin is not defined) is the capacitance of the packaging and interconnect that the die is packaged in (if it is packaged). Suppose the same die is available in a couple or more different packages (e.g. plastic or ceramic, SSOP or PQFP), then "good" .ibs files for each should be expected to have the same values of C_comp but different values of C_pkg/C_pin. If you were mounting the bare die on an MCM, C_pkg/C_pin (and L_pkg/L_pin and R_pkg/R_pin) would be totally different again. At the end of this text I have appended an example from the Interconnectix Standard Library. The example is an AMD PAL. The basic silicon is the AmPAL18P8 but in two different packages. Hence, the library .ibs file has [Component] AmPAL18P8BP and [Component] AmPAL18P8BJ. Please see how C_pkg/C_pin differ but C_comp is the same. Please also note the significant C, L and R value differences between the packages. For faster and faster edge rates, these packaging effects cannot be ignored and they could make the difference between a working design and a non-working design. One thing that's worth noting that might give an indication of the separate nature of C_pkg/C_pin and C_comp is that C_pkg/C_pin are [Component] or [Package] sub-parameters in the IBIS file but C_comp is a [Model] sub-parameter. So, C_pin is not supposed to be part of C_comp. Where they are often effectively included together is in a component datasheet. Most times, the vendor quotes a total pin capacitance value. Sometimes, it is required to reverse engineer an IBIS file for a component using the datasheet, perhaps with a V-I curve printed on the datasheet. You may then wish to create a C_pkg element and a C_comp element from the Ctotal number. A rule of thumb to work to that I got from Bob Ross is to apportion the Ctotal something like C_comp=(Ctotal*0.85) and C_pkg=(Ctotal*0.15). Again, others PLEASE comment. In general, an IBIS simulator should not sum (or lump) C_pkg/C_pin with C_comp because, in the general case, there are other interconnect circuit elements between them (e.g. L_pkg and R_pkg) and summing them directly together would be like collapsing a distributed element network into a lumped one. Sometimes that gets you close enough, but not always. This may be a simulator time-step and resolution issue. This is an important fine detail aspect that I invite the simulator experts to comment on. I hope this helps and stimulates other comments. Here's the example data: [Component] AmPAL18P8BJ [Manufacturer] AMD [Package] | variable typ min max R_pkg .078ohms NA NA L_pkg 3.58nH NA NA C_pkg .884pF NA NA | [Pin] signal_name model_name R_pin L_pin C_pin | 1 I Z188249_IN .076 3.3n .8p 2 I Z188249_IN .078 3.5n .87p 3 I Z188249_IN .08 3.8n .94p 4 I Z188249_IN .08 3.8n .94p 5 I Z188249_IN .078 3.5n .87p 6 I Z188249_IN .076 3.3n .8p 7 I Z188249_IN .078 3.5n .87p 8 I Z188249_IN .08 3.8n .94p 9 I Z188249_IN .08 3.8n .94p 10 GND GND .078 3.5n .87p 11 I Z188249_IN .076 3.3n .8p 12 I/O Z188249_BI .078 3.5n .87p 13 I/O Z188249_BI .08 3.8n .94p 14 I/O Z188249_BI .08 3.8n .94p 15 I/O Z188249_BI .078 3.5n .87p 16 I/O Z188249_BI .076 3.3n .8p 17 I/O Z188249_BI .078 3.5n .87p 18 I/O Z188249_BI .08 3.8n .94p 19 I/O Z188249_BI .08 3.8n .94p 20 VCC POWER .078 3.5n .87p ... [Model] Z188249_BI Model_type I/O Vinl=800.0mV Vinh=2.000V Vref=3.305V Rref=132.2ohms Cref=50.00pF Vmeas=1.500V C_comp 8.000pF NA NA | ... [Component] AmPAL18P8BP [Manufacturer] AMD [Package] | variable typ min max R_pkg .216ohms NA NA L_pkg 5.76nH NA NA C_pkg 1.29pF NA NA | [Pin] signal_name model_name R_pin L_pin C_pin | 1 I Z188250_IN .232 9.76n 1.87p 2 I Z188250_IN .224 7.26n 1.58p 3 I Z188250_IN .216 5.26n 1.29p 4 I Z188250_IN .208 3.76n 1.0p 5 I Z188250_IN .2 2.76n .71p 6 I Z188250_IN .2 2.76n .71p 7 I Z188250_IN .208 3.76n 1.0p 8 I Z188250_IN .216 5.26n 1.29p 9 I Z188250_IN .224 7.26n 1.58p 10 GND GND .232 9.76n 1.87p 11 I Z188250_IN .232 9.76n 1.87p 12 I/O Z188250_BI .224 7.26n 1.58p 13 I/O Z188250_BI .216 5.26n 1.29p 14 I/O Z188250_BI .208 3.76n 1.0p 15 I/O Z188250_BI .2 2.76n .71p 16 I/O Z188250_BI .2 2.76n .71p 17 I/O Z188250_BI .208 3.76n 1.0p 18 I/O Z188250_BI .216 5.26n 1.29p 19 I/O Z188250_BI .224 7.26n 1.58p 20 VCC POWER .232 9.76n 1.87p ... [Model] Z188250_BI Model_type I/O Vinl=800.0mV Vinh=2.000V Vref=3.305V Rref=132.2ohms Cref=50.00pF Vmeas=1.500V C_comp 8.000pF NA NA ... [End] Regards, Tony Dunbar Mentor Graphics/ICX -----Original Message----- From: Olli Timonen [ mailto:Olli.Timonen@tellabs.fi ] Sent: Tuesday, June 13, 2000 9:35 AM To: ibis-users@eda.org Subject: What is the difference between C_comp and C_pin? Hi! I am a bit confused with C_comp. As I understand it, C_comp comprise all the capacitance of a die seen from the pad. What is then the purpose of C_pin (or C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? Does simulator sum C_comp and C_pin together or does C_comp override C_pin or...? ------_=_NextPart_001_01BFD615.D242ECC8 Content-Type: text/html; charset="windows-1252"
Theoretically it should have an effect on both.  The problem is that in the
current IBIS specification there is no mention about where the C_comp is
connected.  Here is what I mean:
 
Consider a complementary buffer which has both pullup and pulldown transistors.
Both of these transistors have a parasitic capacitance between drain and source.
These capacitors can be viewed as two series capacitors between power and ground.
However, the midpoint is connected to the pad.  So it will effect the signal as
well as power/ground bounce, plus act as an on die decoupling capacitance.
 
The problem is that because IBIS doesn't tell you how C_comp supposed to be
divided up between power and ground, most implementations just put it between
the pad and ground.  This may load the signal, but will not account for the
supply bounce correctly.  There is a BIRD which addresses this issue which I
hope will be voted on soon.
 
Arpad Muranyi
Intel Corporation
===============================================================================
 
 
 
-----Original Message-----
From: DORIN OPREA [mailto:dorin.oprea@alcatel.com]
Sent: Wednesday, June 14, 2000 6:55 AM
Cc: 'ibis-users@eda.org'
Subject: Re: What is the difference between C_comp and C_pin?

Is  C_comp a  parameter characterizing the chip (good for  power-ground bounce) and
 is also a  parasitic on the buffer output (bad for signal speed) or is only the parasitic on the buffer output ?

Thanks
 
 
 

"Dunbar, Tony" wrote:

 

Olli,

There are some REAL experts on IBIS out there that I hope will jump in and answer your questions and, perhaps, correct and add to mine. Here goes:

You are correct - as you wrote, "C_comp comprises all of the capacitance of a die seen from the pad." C_pin (or C_pkg, if C_pin is not defined) is the capacitance of the packaging and interconnect that the die is packaged in (if it is packaged). Suppose the same die is available in a couple or more different packages (e.g. plastic or ceramic, SSOP or PQFP), then "good" .ibs files for each should be expected to have the same values of C_comp but different values of C_pkg/C_pin. If you were mounting the bare die on an MCM, C_pkg/C_pin (and L_pkg/L_pin and R_pkg/R_pin) would be totally different again. At the end of this text I have appended an example from the Interconnectix Standard Library. The example is an AMD PAL. The basic silicon is the AmPAL18P8 but in two different packages. Hence, the library .ibs file has [Component] AmPAL18P8BP and [Component] AmPAL18P8BJ. Please see how C_pkg/C_pin differ but C_comp is the same. Please also note the significant C, L and R value differences between the packages. For faster and faster edge rates, these packaging effects cannot be ignored and they could make the difference between a working design and a non-working design.

One thing that's worth noting that might give an indication of the separate nature of C_pkg/C_pin and C_comp is that C_pkg/C_pin are [Component] or [Package] sub-parameters in the IBIS file but C_comp is a [Model] sub-parameter.

So, C_pin is not supposed to be part of C_comp. Where they are often effectively included together is in a component datasheet. Most times, the vendor quotes a total pin capacitance value. Sometimes, it is required to reverse engineer an IBIS file for a component using the datasheet, perhaps with a V-I curve printed on the datasheet. You may then wish to create a C_pkg element and a C_comp element from the Ctotal number. A rule of thumb to work to that I got from Bob Ross is to apportion the Ctotal something like C_comp=(Ctotal*0.85) and C_pkg=(Ctotal*0.15). Again, others PLEASE comment.

In general, an IBIS simulator should not sum (or lump) C_pkg/C_pin with C_comp because, in the general case, there are other interconnect circuit elements between them (e.g. L_pkg and R_pkg) and summing them directly together would be like collapsing a distributed element network into a lumped one. Sometimes that gets you close enough, but not always. This may be a simulator time-step and resolution issue. This is an important fine detail aspect that I invite the simulator experts to comment on.

I hope this helps and stimulates other comments. Here's the example data:

[Component] AmPAL18P8BJ
[Manufacturer] AMD
[Package]
| variable   typ   min   max
R_pkg  .078ohms NA NA
L_pkg  3.58nH NA NA
C_pkg  .884pF NA NA
|
[Pin] signal_name  model_name  R_pin  L_pin C_pin
|
1 I Z188249_IN .076 3.3n .8p
2 I Z188249_IN .078 3.5n .87p
3 I Z188249_IN .08 3.8n .94p
4 I Z188249_IN .08 3.8n .94p
5 I Z188249_IN .078 3.5n .87p
6 I Z188249_IN .076 3.3n .8p
7 I Z188249_IN .078 3.5n .87p
8 I Z188249_IN .08 3.8n .94p
9 I Z188249_IN .08 3.8n .94p
10 GND GND .078 3.5n .87p
11 I Z188249_IN .076 3.3n .8p
12 I/O Z188249_BI .078 3.5n .87p
13 I/O Z188249_BI .08 3.8n .94p
14 I/O Z188249_BI .08 3.8n .94p
15 I/O Z188249_BI .078 3.5n .87p
16 I/O Z188249_BI .076 3.3n .8p
17 I/O Z188249_BI .078 3.5n .87p
18 I/O Z188249_BI .08 3.8n .94p
19 I/O Z188249_BI .08 3.8n .94p
20 VCC POWER .078 3.5n .87p
...
[Model] Z188249_BI
Model_type I/O
Vinl=800.0mV
Vinh=2.000V
Vref=3.305V
Rref=132.2ohms
Cref=50.00pF
Vmeas=1.500V
C_comp 8.000pF NA NA
|
...
[Component] AmPAL18P8BP
[Manufacturer] AMD
[Package]
| variable   typ   min   max
R_pkg  .216ohms NA NA
L_pkg  5.76nH NA NA
C_pkg  1.29pF NA NA
|
[Pin] signal_name  model_name  R_pin  L_pin C_pin
|
1 I Z188250_IN .232 9.76n 1.87p
2 I Z188250_IN .224 7.26n 1.58p
3 I Z188250_IN .216 5.26n 1.29p
4 I Z188250_IN .208 3.76n 1.0p
5 I Z188250_IN .2 2.76n .71p
6 I Z188250_IN .2 2.76n .71p
7 I Z188250_IN .208 3.76n 1.0p
8 I Z188250_IN .216 5.26n 1.29p
9 I Z188250_IN .224 7.26n 1.58p
10 GND GND .232 9.76n 1.87p
11 I Z188250_IN .232 9.76n 1.87p
12 I/O Z188250_BI .224 7.26n 1.58p
13 I/O Z188250_BI .216 5.26n 1.29p
14 I/O Z188250_BI .208 3.76n 1.0p
15 I/O Z188250_BI .2 2.76n .71p
16 I/O Z188250_BI .2 2.76n .71p
17 I/O Z188250_BI .208 3.76n 1.0p
18 I/O Z188250_BI .216 5.26n 1.29p
19 I/O Z188250_BI .224 7.26n 1.58p
20 VCC POWER .232 9.76n 1.87p
...
[Model] Z188250_BI
Model_type I/O
Vinl=800.0mV
Vinh=2.000V
Vref=3.305V
Rref=132.2ohms
Cref=50.00pF
Vmeas=1.500V
C_comp 8.000pF NA NA
...
[End]

Regards,
Tony Dunbar
Mentor Graphics/ICX

-----Original Message-----
From: Olli Timonen [mailto:Olli.Timonen@tellabs.fi]
Sent: Tuesday, June 13, 2000 9:35 AM
To: ibis-users@eda.org
Subject: What is the difference between C_comp and C_pin?

Hi!
I am a bit confused with C_comp. As I understand it, C_comp comprise all the
capacitance of a die seen from the pad. What is then the purpose of C_pin (or
C_pkg if not defined)? Isn?t capacitance of C_pin included in C_comp? Does
simulator sum C_comp and C_pin together or does C_comp override C_pin or...?

------_=_NextPart_001_01BFD615.D242ECC8-- From owner-ibis Fri Jun 16 16:35:48 2000 Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA04607 for ; Fri, 16 Jun 2000 16:35:48 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id QAA03789 for ; Fri, 16 Jun 2000 16:33:44 -0700 (PDT) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 16 Jun 2000 23:33:43 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 16:33:41 -0700 Message-ID: From: "Mirmak, Michael" To: "'ibis-users@eda.org'" Subject: Differential inputs and "tdelay" Date: Fri, 16 Jun 2000 16:33:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Fellow IBIS-fans, I have a simple question relating to language used in the 3.2 specification to describe differential pins. The parameters "tdelay_typ," "tdelay_min" and "tdelay_max" are described as "launch delays." As such, they seem to be analogous to pin-to-pin skews on output-only or I/O buffers. However, this conflicts with the examples cited in the 3.2 specification, which include [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max 3 4 150mV -1ns 0ns -2ns | Input or I/O pair How can a pair of differential inputs have "launch delays?" Is this a reference to a max or min mismatch allowed by the device at these pins? Thanks in advance for any clarity you can lend! - Michael Mirmak, Intel Corp. From owner-ibis Mon Jun 19 07:40:43 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA14993 for ; Mon, 19 Jun 2000 07:40:42 -0700 (PDT) Received: from mercury.isr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA00829; Mon, 19 Jun 2000 07:37:58 -0700 (PDT) Received: from mentor.com by mercury.isr.mentorg.com (8.8.8/CF5.40H) id QAA02703; Mon, 19 Jun 2000 16:40:59 +0200 (IST) Sender: bmanor@isr.mentorg.com Message-ID: <394E3017.80832A5B@mentor.com> Date: Mon, 19 Jun 2000 16:37:11 +0200 From: Ben Manor Organization: Mentor Graphics Israel Ltd. X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis users Subject: 74ALVCH16501 Ibis Model Content-Type: multipart/mixed; boundary="------------27B9371E3553FF75BE55EDF1" This is a multi-part message in MIME format. --------------27B9371E3553FF75BE55EDF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Not in TI's site. Does anyone has it? THANKS -- ========================================================== Ben Manor, Application Engineer - Mentor Graphics Israel 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 email: Ben_Manor@mentor.com Mobile: +972-53-415412 ---------------------------------------------------------- --------------27B9371E3553FF75BE55EDF1 Content-Type: text/x-vcard; charset=us-ascii; name="Ben_Manor.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ben Manor Content-Disposition: attachment; filename="Ben_Manor.vcf" begin:vcard n:Manor;Ben tel;fax:+972-9-9552627 tel;work:+972-9-9552636 (Ext.119) x-mozilla-html:FALSE url:http://www.mentor.com/ org:Mentor Graphics Israel;Interconnectix version:2.1 email;internet:Ben_Manor@mentor.com title:Application Engineer adr;quoted-printable:;;41 Hagalim Blvd.=0D=0AP.O.B. 2155;Herzliya;;46120;Israel x-mozilla-cpt:;-10160 fn:Ben Manor end:vcard --------------27B9371E3553FF75BE55EDF1-- From owner-ibis Mon Jun 19 10:02:56 2000 Received: from mc.com ([192.233.16.119]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA15775 for ; Mon, 19 Jun 2000 10:02:54 -0700 (PDT) Received: from ruger.mc.com by mc.com (8.8.8+Sun/SMI-SVR4) id MAA11335; Mon, 19 Jun 2000 12:58:19 -0400 (EDT) Received: by ruger.mc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 12:58:19 -0400 Message-ID: From: "Greim, Michael" To: "'Ben Manor'" , ibis users Subject: RE: 74ALVCH16501 Ibis Model Date: Mon, 19 Jun 2000 12:58:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFDA0F.91A31754" 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_000_01BFDA0F.91A31754 Content-Type: text/plain Here it is. It is can be found on the following site: http://www.philipslogic.com/support/ibis/alvc/ Enjoy..... <> Best Regards, Michael > -----Original Message----- > From: Ben Manor [SMTP:Ben_Manor@mentorg.com] > Sent: Monday, June 19, 2000 10:37 AM > To: ibis users > Subject: 74ALVCH16501 Ibis Model > > Not in TI's site. > Does anyone has it? > > THANKS > -- > ========================================================== > Ben Manor, Application Engineer - Mentor Graphics Israel > 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel > Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 > email: Ben_Manor@mentor.com Mobile: +972-53-415412 > ---------------------------------------------------------- << File: Card > for Ben Manor >> ------_=_NextPart_000_01BFDA0F.91A31754 Content-Type: application/octet-stream; name="h16501t.ibs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="h16501t.ibs" | *************************************************** | Philips Semiconductors Inc.=20 | Logic Products Group =20 | =20 | IBIS model of 74ALVCH16501 =20 | 18-Bit universal bus transiver; 3-state =20 | TSSOP 56-pin (DGG) Package =20 | *************************************************** | [IBIS Ver] 2.1 [File Name] h16501t.ibs [File Rev] 1.0 [Date] 08-Apr-1998 [Source] File created from simulations by MP Philips Semiconductors Nijmegen | [Disclaimer] (C) Copyright Philips Semiconductors, Inc. 1998 All rights reserved Philips Semiconductors (PHILIPS) provides this IBIS = model=20 (MODEL) as a service to our customers. You and your = company shall not distribute, loan, sell or give this MODEL to = anyone else without receiving prior written permission = from=20 PHILIPS. The MODEL provided by PHILIPS is not warranted by = PHILIPS=20 as fully representing all of the specifications and=20 operating characteristics of the semiconductor product = to=20 which the MODEL relates. Moreover, this MODEL is = furnished=20 on an "as is" basis without support or warranty of any = kind,=20 either expressed or implied, regarding the use thereof = and=20 Philips specifically disclaims all implied warranties = of=20 merchantability and fitness of the MODELS for any = purpose. PHILIPS does not assume any liability arising out of = the=20 application or use of the MODELS including = infringements of=20 patents and copyrights, nor does PHILIPS convey any = license=20 under its patents and copyrights or the rights of = others. PHILIPS reserves the right to make changes to any = model i without notice. Please be aware that your receipt and subsequent use = of the=20 MODEL information provided shall serve as acceptance = of=20 these terms and conditions. If you do not accept these = terms,=20 you should return or destroy the MODEL and any other=20 accompanying information immediately. |=20 [Component] 74ALVCH16501 [Manufacturer] Philips Semiconductors Inc. [Package] |[Package] tssop56 | variable typ min max R_pkg 75.2mO 58.5mO 91.8mO L_pkg 5.35nH 3.09nH 7.61nH C_pkg 0.809pF 0.429pF 1.189pF | | [Pin] signal_name model_name R_pin L_pin C_pin 1 OEAB INPNBH 83.3mO 7.61nH 1.008pF 2 LEAB ALVCH_IO 84.3mO 7.08nH 1.189pF 3 A0 ALVCH_IO 85.6mO 6.49nH 1.083pF 4 GND GND 86.7mO 5.96nH 0.966pF 5 A1 ALVCH_IO 89.2mO 5.38nH 0.868pF 6 A2 ALVCH_IO 91.4mO 4.93nH 0.821pF 7 VCC POWER 87.3mO 4.50nH 0.757pF 8 A3 ALVCH_IO 91.8mO 4.27nH 0.707pF 9 A4 ALVCH_IO 80.8mO 3.91nH 0.652pF 10 A5 ALVCH_IO 72.3mO 3.69nH 0.635pF 11 GND GND 65.9mO 3.46nH 0.623pF 12 A6 ALVCH_IO 62.8mO 3.30nH 0.590pF 13 A7 ALVCH_IO 60.3mO 3.15nH 0.554pF 14 A8 ALVCH_IO 58.5mO 3.09nH 0.541pF 15 A9 ALVCH_IO 58.5mO 3.09nH 0.429pF 16 A10 ALVCH_IO 60.3mO 3.15nH 0.432pF 17 A11 ALVCH_IO 62.8mO 3.30nH 0.565pF 18 GND GND 65.9mO 3.46nH 0.603pF 19 A12 ALVCH_IO 72.3mO 3.69nH 0.639pF 20 A13 ALVCH_IO 80.8mO 3.91nH 0.642pF 21 A14 ALVCH_IO 91.8mO 4.27nH 0.669pF 22 VCC POWER 87.3mO 4.50nH 0.730pF 23 A15 ALVCH_IO 91.4mO 4.93nH 0.787pF 24 A16 ALVCH_IO 89.2mO 5.38nH 0.861pF 25 GND GND 86.7mO 5.96nH 0.922pF 26 A17 ALVCH_IO 85.6mO 6.49nH 1.014pF 27 OENBA INPNBH 84.3mO 7.08nH 1.141pF 28 LEBA INPNBH 83.3mO 7.61nH 1.268pF 29 GND GND 83.3mO 7.61nH 1.310pF 30 CPBA INPNBH 84.3mO 7.08nH 1.189pF 31 B17 ALVCH_IO 85.6mO 6.49nH 1.083pF 32 GND GND 86.7mO 5.96nH 0.966pF 33 B16 ALVCH_IO 89.2mO 5.38nH 0.868pF 34 B15 ALVCH_IO 91.4mO 4.93nH 0.821pF 35 VCC POWER 87.3mO 4.50nH 0.757pF 36 B14 ALVCH_IO 91.8mO 4.27nH 0.707pF 37 B13 ALVCH_IO 80.8mO 3.91nH 0.652pF 38 B12 ALVCH_IO 72.3mO 3.69nH 0.635pF 39 GND GND 65.9mO 3.46nH 0.623pF 40 B11 ALVCH_IO 62.8mO 3.30nH 0.590pF 41 B10 ALVCH_IO 60.3mO 3.15nH 0.554pF 42 B9 ALVCH_IO 58.5mO 3.09nH 0.541pF 43 B8 ALVCH_IO 58.5mO 3.09nH 0.429pF 44 B7 ALVCH_IO 60.3mO 3.15nH 0.432pF 45 B6 ALVCH_IO 62.8mO 3.30nH 0.565pF 46 GND GND 65.9mO 3.46nH 0.603pF 47 B5 ALVCH_IO 72.3mO 3.69nH 0.639pF 48 B4 ALVCH_IO 80.8mO 3.91nH 0.642pF 49 B3 ALVCH_IO 91.8mO 4.27nH 0.669pF 50 VCC POWER 87.3mO 4.50nH 0.730pF 51 B2 ALVCH_IO 91.4mO 4.93nH 0.787pF 52 B1 ALVCH_IO 89.2mO 5.38nH 0.861pF 53 GND GND 86.7mO 5.96nH 0.922pF 54 B0 ALVCH_IO 85.6mO 6.49nH 1.014pF 55 CPAB INPNBH 84.3mO 7.08nH 1.141pF 56 GND GND 83.3mO 7.61nH 1.268pF |=20 |***********************************************************************= * | Model INPNBH |***********************************************************************= * | [Model] INPNBH Model_type Input Polarity Inverting Vinl =3D 0.80V Vinh =3D 2.00V Vmeas =3D 1.50V C_comp 3.3000pF 3.0000pF 3.6000pF | | [Temperature Range] 27.0000 85.0000 = -40.0000=20 [Voltage Range] 3.3000V 3.6000V = 3.0000V [GND_clamp] | voltage I(typ) I(min) I(max) | -3.3000 -2.3280A -2.4050A -2.2550A -3.2000 -2.2280A -2.3050A -2.1550A -3.1000 -2.1280A -2.2060A -2.0550A -3.0000 -2.0280A -2.1060A -1.9550A -2.9000 -1.9290A -2.0070A -1.8550A -2.8000 -1.8290A -1.9070A -1.7550A -2.7000 -1.7300A -1.8080A -1.6560A -2.6000 -1.6300A -1.7090A -1.5560A -2.5000 -1.5310A -1.6100A -1.4560A -2.4000 -1.4320A -1.5110A -1.3570A -2.3000 -1.3320A -1.4120A -1.2570A -2.2000 -1.2330A -1.3130A -1.1580A -2.1000 -1.1350A -1.2150A -1.0590A -2.0000 -1.0360A -1.1160A -0.9597A -1.9000 -0.9377A -1.0180A -0.8609A -1.8000 -0.8396A -0.9202A -0.7624A -1.7000 -0.7418A -0.8228A -0.6642A -1.6000 -0.6445A -0.7257A -0.5665A -1.5000 -0.5478A -0.6292A -0.4694A -1.4000 -0.4519A -0.5334A -0.3731A -1.3000 -0.3572A -0.4386A -0.2782A -1.2000 -0.2643A -0.3452A -0.1857A -1.1000 -0.1745A -0.2540A -98.3630mA -1.0000 -91.2620mA -0.1666A -27.3500mA -0.9000 -26.6510mA -86.9460mA -4.6760mA -0.8000 -4.6820mA -27.0300mA -1.9730mA -0.7000 -1.8290mA -5.3390mA -0.6322mA -0.6000 -0.6719mA -1.9630mA -0.1088mA -0.5000 -0.1638mA -0.7771mA -8.2330uA -0.4000 -23.1350uA -0.2299mA -0.3593uA -0.3000 -1.5650uA -44.4590uA -3.2110nA -0.2000 -31.2680nA -2.9840uA -19.0120pA -0.1000 -0.5324nA -0.1047uA -0.1085pA 0.0000 1.044e-20A 2.885e-23A 1.289e-24A 0.1000 9.1980pA 3.5500nA 1.3990fA 0.2000 9.6590pA 3.8090nA 2.0150fA 0.3000 9.9690pA 3.9510nA 2.6520fA 0.4000 10.2950pA 4.0980nA 3.3180fA 0.5000 10.6380pA 4.2530nA 3.8530fA 0.6000 10.9950pA 4.4150nA 4.5980fA 0.7000 11.3670pA 4.5850nA 5.2290fA 0.8000 11.7530pA 4.7620nA 5.8610fA 0.9000 12.1530pA 4.9460nA 6.4930fA 1.0000 12.5670pA 5.1370nA 7.1210fA 1.1000 12.9960pA 5.3360nA 7.7530fA 1.2000 13.4400pA 5.5440nA 8.3800fA 1.3000 13.9000pA 5.7590nA 9.0080fA 1.4000 14.3760pA 5.9830nA 9.6320fA 1.5000 14.8680pA 6.2160nA 10.2580fA 1.6000 15.3770pA 6.4580nA 10.8810fA 1.7000 15.9050pA 6.7100nA 11.5060fA 1.8000 16.4500pA 6.9710nA 12.1270fA 1.9000 17.0140pA 7.2430nA 12.7430fA 2.0000 17.5980pA 7.5250nA 13.3610fA 2.1000 18.2020pA 7.8190nA 13.9770fA 2.2000 18.8270pA 8.1240nA 14.5940fA 2.3000 19.4740pA 8.4410nA 15.2100fA 2.4000 20.1450pA 8.7710nA 15.8140fA 2.5000 20.8380pA 9.1150nA 16.4200fA 2.6000 21.5570pA 9.4720nA 17.0270fA 2.7000 22.3030pA 9.8440nA 18.2260fA 2.8000 23.0760pA 10.2320nA 18.8420fA 2.9000 23.8790pA 10.6360nA 19.4590fA 3.0000 24.7130pA 11.0570nA 20.0610fA 3.1000 25.5810pA 11.4980nA 20.6720fA 3.2000 26.4840pA 11.9580nA 21.2710fA 3.3000 27.4260pA 12.4400nA 21.8630fA | [POWER_clamp] | voltage I(typ) I(min) I(max) | -3.3000 0.1153nA 71.2160nA 45.1680fA -3.2000 0.1095nA 67.2980nA 43.9040fA -3.1000 0.1039nA 63.6110nA 42.6060fA -3.0000 98.7390pA 60.1430nA 42.6110fA -2.9000 93.8370pA 56.8800nA 41.2470fA -2.8000 89.2190pA 53.8120nA 39.8620fA -2.7000 84.8670pA 50.9260nA 39.7460fA -2.6000 80.7670pA 48.2140nA 38.3280fA -2.5000 76.9050pA 45.6650nA 38.1220fA -2.4000 73.2670pA 43.2690nA 36.6860fA -2.3000 69.8420pA 41.0180nA 36.4310fA -2.2000 66.6150pA 38.9020nA 34.9680fA -2.1000 63.5760pA 36.9150nA 34.6500fA -2.0000 60.7140pA 35.0470nA 34.2920fA -1.9000 58.0160pA 33.2920nA 32.8180fA -1.8000 55.4750pA 31.6430nA 32.4280fA -1.7000 53.0800pA 30.0930nA 31.9990fA -1.6000 50.8210pA 28.6360nA 30.5350fA -1.5000 48.6910pA 27.2660nA 30.0790fA -1.4000 46.6800pA 25.9780nA 29.6130fA -1.3000 44.7810pA 24.7660nA 29.1150fA -1.2000 42.9860pA 23.6250nA 27.6640fA -1.1000 41.2900pA 22.5510nA 27.1550fA -1.0000 39.6830pA 21.5380nA 26.6270fA -0.9000 38.1620pA 20.5840nA 26.0960fA -0.8000 36.7200pA 19.6840nA 25.5360fA -0.7000 35.3510pA 18.8340nA 24.9690fA -0.6000 34.0490pA 18.0310nA 23.5950fA -0.5000 32.8110pA 17.2710nA 23.0260fA -0.4000 31.6330pA 16.5520nA 22.4460fA -0.3000 30.5080pA 15.8710nA 21.8630fA -0.2000 29.4350pA 15.2250nA 21.2710fA -0.1000 28.4080pA 14.6110nA 20.6720fA 0.0000 27.4260pA 14.0280nA 20.0610fA | | End [Model] INPNBH | |***********************************************************************= * | Model ALVCH_IO |***********************************************************************= * | [Model] ALVCH_IO Model_type I/O Polarity Non-Inverting Enable Active-High Vinl =3D 0.80V Vinh =3D 2.00V Vmeas =3D 1.50V Cref =3D 50.00pF Rref =3D 500 C_comp 3.30pF 3.00pF 3.60pF | | [Temperature Range] 27.0000 85.0000 = -40.0000=20 [Voltage Range] 3.3000V 3.6000V = 3.0000V [Pulldown] | voltage I(typ) I(min) I(max) | -3.3000 -1.0000mA -2.0000mA -1.0000mA -3.1000 -1.0000mA -2.0000mA -1.0000mA -2.9000 -1.0000mA -1.0000mA -1.0000mA -2.7000 -2.0000mA -2.0000mA -2.0000mA -2.5000 -2.0000mA -1.0000mA -2.0000mA -2.3000 -2.0000mA -3.0000mA -3.0000mA -2.1000 -3.0000mA -3.0000mA -2.0000mA -1.9000 -3.0000mA -3.0000mA -3.0000mA -1.7000 -4.0520mA -3.0000mA -4.4390mA -1.5000 -5.5780mA -4.9710mA -6.5020mA -1.0000 -41.5430mA -20.6050mA -0.1041A -0.9000 -81.7870mA -39.3530mA -0.1110A -0.8000 -86.9740mA -69.0320mA -0.1025A -0.7000 -79.2490mA -72.5330mA -92.5403mA -0.6000 -70.0318mA -64.9750mA -81.3366mA -0.5000 -59.8268mA -55.8278mA -69.2510mA -0.4000 -48.8670mA -45.7729mA -56.4191mA -0.3000 -37.2503mA -35.0134mA -42.8741mA -0.2000 -25.1598mA -23.6758mA -28.9384mA -0.1000 -12.7293mA -11.9762mA -14.6351mA 0.0000 0.0000mA 0.0000mA 0.0000mA 0.1000 12.4645mA 11.7953mA 14.2256mA 0.2000 24.1124mA 22.9657mA 27.3275mA 0.3000 34.9360mA 33.4921mA 39.3066mA 0.4000 44.9500mA 43.3788mA 50.1939mA 0.5000 54.1796mA 52.6406mA 60.0284mA 0.6000 62.6478mA 61.2888mA 68.8500mA 0.7000 70.3797mA 69.3405mA 76.6997mA 0.8000 77.4015mA 76.8110mA 83.6185mA 0.9000 83.7399mA 83.7156mA 89.6463mA 1.0000 89.4171mA 90.0696mA 94.8247mA 1.1000 94.4606mA 95.8892mA 99.1950mA 1.2000 98.8942mA 0.1012A 0.1028A 1.3000 0.1027A 0.1060A 0.1057A 1.4000 0.1060A 0.1103A 0.1079A 1.5000 0.1088A 0.1141A 0.1095A 1.6000 0.1110A 0.1175A 0.1107A 1.7000 0.1128A 0.1205A 0.1115A 1.8000 0.1142A 0.1230A 0.1120A 1.9000 0.1152A 0.1251A 0.1124A 2.0000 0.1159A 0.1268A 0.1127A 2.1000 0.1164A 0.1282A 0.1130A 2.2000 0.1168A 0.1293A 0.1133A 2.3000 0.1171A 0.1301A 0.1135A 2.4000 0.1174A 0.1307A 0.1137A 2.5000 0.1176A 0.1311A 0.1139A 2.6000 0.1178A 0.1315A 0.1140A 2.7000 0.1180A 0.1318A 0.1142A 2.8000 0.1182A 0.1321A 0.1144A 2.9000 0.1184A 0.1323A 0.1146A 3.0000 0.1186A 0.1325A 0.1147A 3.1000 0.1188A 0.1327A 0.1149A 3.2000 0.1189A 0.1329A 0.1150A 3.3000 0.1191A 0.1331A 0.1152A 3.4000 0.1192A 0.1333A 0.1154A 3.5000 0.1194A 0.1335A 0.1156A 3.6000 0.1196A 0.1337A 0.1159A 3.7000 0.1198A 0.1339A 0.1166A 3.8000 0.1202A 0.1341A 0.1178A 3.9000 0.1208A 0.1344A 0.1197A 4.0000 0.1219A 0.1348A 0.1266A 4.1000 0.1238A 0.1355A 0.1444A 4.2000 0.1311A 0.1367A 0.1662A 4.3000 0.1478A 0.1389A 0.1892A 4.5000 0.1912A 0.1623A 0.2370A 4.7000 0.2381A 0.2044A 0.2857A 4.9000 0.2863A 0.2507A 0.3350A 5.1000 0.3353A 0.2985A 0.3848A 5.3000 0.3847A 0.3472A 0.4349A 5.5000 0.4346A 0.3965A 0.4855A 5.7000 0.4849A 0.4463A 0.5363A 5.9000 0.5357A 0.4966A 0.5876A 6.1000 0.5868A 0.5474A 0.6393A 6.6000 0.7165A 0.6762A 0.7703A | [Pullup] | voltage I(typ) I(min) I(max) | -3.3000 1.1030mA 1.1980mA 1.0260mA -3.1000 1.2120mA 1.3110mA 1.1360mA -2.9000 1.3460mA 1.4470mA 1.2720mA -2.7000 1.5140mA 1.6150mA 1.4450mA -2.5000 1.7290mA 1.8260mA 1.6720mA -2.3000 2.0150mA 2.1030mA 1.9860mA -2.1000 2.4170mA 2.4760mA 2.4460mA -1.9000 3.0180mA 3.0120mA 3.1850mA -1.7000 4.0190mA 3.8420mA 4.5850mA -1.5000 6.0070mA 5.2980mA 8.2690mA -1.0000 45.0450mA 28.9180mA 63.7730mA -0.9000 54.0940mA 40.3850mA 63.1730mA -0.8000 54.0190mA 48.3290mA 57.5960mA -0.7000 48.6910mA 48.2010mA 51.3052mA -0.6000 42.5108mA 42.8720mA 44.4388mA -0.5000 35.8423mA 36.4755mA 37.0523mA -0.4000 28.7646mA 29.5836mA 29.4996mA -0.3000 21.5339mA 22.3224mA 22.0029mA -0.2000 14.3091mA 14.9137mA 14.5843mA -0.1000 7.1285mA 7.4499mA 7.2486mA 0.0000 0.0000mA 0.0000mA 0.0000mA 0.1000 -7.0500mA -7.4020mA -7.1320mA 0.2000 -13.9450mA -14.6770mA -14.0680mA 0.3000 -20.6800mA -21.8230mA -20.8010mA 0.4000 -27.2500mA -28.8330mA -27.3230mA 0.5000 -33.6500mA -35.7060mA -33.6270mA 0.6000 -39.8750mA -42.4360mA -39.7040mA 0.7000 -45.9180mA -49.0190mA -45.5460mA 0.8000 -51.7750mA -55.4520mA -51.1460mA 0.9000 -57.4390mA -61.7310mA -56.4930mA 1.0000 -62.9060mA -67.8500mA -61.5790mA 1.1000 -68.1680mA -73.8070mA -66.3940mA 1.2000 -73.2190mA -79.5960mA -70.9280mA 1.3000 -78.0540mA -85.2130mA -75.1710mA 1.4000 -82.6640mA -90.6530mA -79.1130mA 1.5000 -87.0440mA -95.9100mA -82.7420mA 1.6000 -91.1850mA -0.1010A -85.7160mA 1.7000 -95.0730mA -0.1059A -88.6780mA 1.8000 -98.3570mA -0.1105A -91.3560mA 1.9000 -0.1017A -0.1146A -93.7320mA 2.0000 -0.1049A -0.1188A -95.8210mA 2.1000 -0.1078A -0.1229A -97.6520mA 2.2000 -0.1105A -0.1268A -99.2660mA 2.3000 -0.1129A -0.1305A -0.1007A 2.4000 -0.1151A -0.1339A -0.1020A 2.5000 -0.1172A -0.1372A -0.1032A 2.6000 -0.1190A -0.1402A -0.1043A 2.7000 -0.1208A -0.1431A -0.1053A 2.8000 -0.1224A -0.1457A -0.1062A 2.9000 -0.1240A -0.1483A -0.1070A 3.0000 -0.1254A -0.1506A -0.1078A 3.1000 -0.1268A -0.1529A -0.1085A 3.2000 -0.1281A -0.1551A -0.1092A 3.3000 -0.1292A -0.1573A -0.1098A 3.4000 -0.1303A -0.1594A -0.1104A 3.5000 -0.1313A -0.1615A -0.1110A 3.6000 -0.1322A -0.1634A -0.1116A 3.7000 -0.1331A -0.1653A -0.1126A 3.8000 -0.1340A -0.1670A -0.1144A 3.9000 -0.1353A -0.1686A -0.1173A 4.0000 -0.1371A -0.1702A -0.1354A 4.1000 -0.1401A -0.1721A -0.2199A 4.2000 -0.1570A -0.1745A -0.3338A 4.3000 -0.2300A -0.1783A -0.4562A 4.5000 -0.4552A -0.2606A -0.7103A 4.7000 -0.7044A -0.4763A -0.9698A 4.9000 -0.9608A -0.7214A -1.2320A 5.1000 -1.2210A -0.9756A -1.4950A 5.3000 -1.4830A -1.2340A -1.7600A 5.5000 -1.7460A -1.4950A -2.0250A 5.7000 -2.0100A -1.7570A -2.2900A 5.9000 -2.2750A -2.0200A -2.5570A 6.1000 -2.5400A -2.2850A -2.8230A 6.6000 -3.2050A -2.9470A -3.4900A | [GND_clamp] | voltage I(typ) I(min) I(max) | -3.3000 -3.0590A -3.1550A -2.9700A -3.2000 -2.9260A -3.0230A -2.8370A -3.1000 -2.7930A -2.8900A -2.7040A -3.0000 -2.6600A -2.7580A -2.5710A -2.9000 -2.5280A -2.6260A -2.4380A -2.8000 -2.3950A -2.4930A -2.3050A -2.7000 -2.2630A -2.3610A -2.1720A -2.6000 -2.1310A -2.2290A -2.0400A -2.5000 -1.9990A -2.0980A -1.9070A -2.4000 -1.8670A -1.9660A -1.7750A -2.3000 -1.7350A -1.8340A -1.6420A -2.2000 -1.6030A -1.7030A -1.5100A -2.1000 -1.4720A -1.5720A -1.3790A -2.0000 -1.3410A -1.4420A -1.2470A -1.9000 -1.2100A -1.3110A -1.1160A -1.8000 -1.0800A -1.1810A -0.9847A -1.7000 -0.9501A -1.0520A -0.8542A -1.6000 -0.8209A -0.9228A -0.7244A -1.5000 -0.6925A -0.7948A -0.5954A -1.4000 -0.5653A -0.6677A -0.4677A -1.3000 -0.4399A -0.5422A -0.3420A -1.2000 -0.3171A -0.4187A -0.2200A -1.1000 -0.1994A -0.2987A -0.1064A -1.0000 -93.0600mA -0.1849A -22.3920mA -0.9000 -20.5820mA -84.8610mA -4.6690mA -0.8000 -4.3570mA -20.4010mA -2.1790mA -0.7000 -1.9930mA -4.6880mA -0.8367mA -0.6000 -0.8342mA -2.0850mA -0.3024mA -0.5000 -0.3092mA -0.9142mA -0.1760mA -0.4000 -0.1440mA -0.3461mA -0.1359mA -0.3000 -92.7200uA -0.1346mA -0.1009mA -0.2000 -60.1530uA -63.1530uA -66.5860uA -0.1000 -29.6720uA -29.7990uA -32.9110uA 0.0000 -34.2910pA -22.6180nA -0.3668pA 0.1000 28.5250uA 28.6810uA 31.3810uA 0.2000 55.5570uA 56.3300uA 60.5280uA 0.3000 81.0420uA 82.8540uA 87.4180uA 0.4000 0.1050mA 0.1082mA 0.1121mA 0.5000 0.1274mA 0.1324mA 0.1346mA 0.6000 0.1482mA 0.1552mA 0.1550mA 0.7000 0.1673mA 0.1765mA 0.1733mA 0.8000 0.1845mA 0.1960mA 0.1895mA 0.9000 0.1991mA 0.2134mA 0.2027mA 1.0000 0.2109mA 0.2284mA 0.2123mA 1.1000 0.2194mA 0.2408mA 0.2170mA 1.2000 0.2238mA 0.2502mA 0.2152mA 1.3000 0.2230mA 0.2560mA 0.2032mA 1.4000 0.2145mA 0.2571mA 0.1589mA 1.5000 0.1897mA 0.2518mA -0.1920mA 1.6000 -0.1902mA 0.2344mA -0.2001mA 1.7000 -0.2096mA 0.1754mA -0.2009mA 1.8000 -0.2158mA -0.2238mA -0.1974mA 1.9000 -0.2160mA -0.2417mA -0.1907mA 2.0000 -0.2123mA -0.2476mA -0.1815mA 2.1000 -0.2057mA -0.2477mA -0.1701mA 2.2000 -0.1967mA -0.2438mA -0.1568mA 2.3000 -0.1858mA -0.2371mA -0.1419mA 2.4000 -0.1730mA -0.2278mA -0.1256mA 2.5000 -0.1587mA -0.2166mA -0.1080mA 2.6000 -0.1429mA -0.2034mA -89.0050uA 2.7000 -0.1258mA -0.1887mA -68.7190uA 2.8000 -0.1075mA -0.1724mA -47.1180uA 2.9000 -88.1630uA -0.1547mA -24.2090uA 3.0000 -67.7250uA -0.1358mA 0.1632pA 3.1000 -46.2150uA -0.1157mA 25.3620uA 3.2000 -23.6380uA -94.5110uA 51.7280uA 3.3000 27.0750pA -72.3370uA 79.0960uA | [POWER_clamp] | voltage I(typ) I(min) I(max) | -3.3000 0.5810A 0.6014A 0.5618A -3.2000 0.5563A 0.5767A 0.5371A -3.1000 0.5316A 0.5521A 0.5123A -3.0000 0.5069A 0.5274A 0.4875A -2.9000 0.4823A 0.5028A 0.4628A -2.8000 0.4576A 0.4782A 0.4381A -2.7000 0.4330A 0.4536A 0.4134A -2.6000 0.4084A 0.4290A 0.3887A -2.5000 0.3838A 0.4045A 0.3640A -2.4000 0.3592A 0.3800A 0.3394A -2.3000 0.3347A 0.3555A 0.3148A -2.2000 0.3102A 0.3311A 0.2902A -2.1000 0.2857A 0.3067A 0.2657A -2.0000 0.2613A 0.2823A 0.2412A -1.9000 0.2369A 0.2580A 0.2167A -1.8000 0.2127A 0.2338A 0.1923A -1.7000 0.1885A 0.2097A 0.1680A -1.6000 0.1644A 0.1857A 0.1438A -1.5000 0.1404A 0.1618A 0.1198A -1.4000 0.1167A 0.1380A 95.9890mA -1.3000 93.2360mA 0.1146A 72.5080mA -1.2000 70.2060mA 91.4080mA 49.6200mA -1.1000 47.9280mA 68.7780mA 28.0110mA -1.0000 27.2050mA 47.0340mA 10.3640mA -0.9000 10.6520mA 27.0590mA 3.6160mA -0.8000 3.5770mA 11.3400mA 1.8690mA -0.7000 1.7880mA 4.0380mA 0.8148mA -0.6000 0.8332mA 1.9760mA 0.3082mA -0.5000 0.3387mA 0.9615mA 0.1517mA -0.4000 0.1454mA 0.4114mA 0.1084mA -0.3000 80.0760uA 0.1626mA 79.0960uA -0.2000 49.9020uA 59.3430uA 51.7280uA -0.1000 24.5400uA 26.1020uA 25.3620uA 0.0000 27.0750pA 13.8590nA 0.1632pA | [Ramp] | variable typ min max dV/dt_r 1.9254/0.1374n 2.1030/0.1190n 1.7508/0.1455n dV/dt_f 1.9493/0.1760n 2.1244/0.1853n 1.7756/0.1661n R_load =3D 500 | [Rising Waveform] R_fixture =3D 500 V_fixture =3D 0.0 V_fixture_min =3D 0.0 V_fixture_max =3D 0.0 | time V(typ) V(min) V(max) | 0.0000nS 0.2635nV 0.1846uV 2.4580pV 0.0500nS -2.1222mV -2.4849mV -2.4034mV 0.1000nS -33.5185mV -33.3725mV -34.6665mV 0.1500nS -61.2770mV -51.2893mV -62.9833mV 0.2000nS -48.1790mV 36.9120mV -81.6970mV 0.2500nS 0.1626V 0.4700V 39.0953mV 0.3000nS 0.6324V 1.2980V 0.3570V 0.3500nS 1.1738V 2.0575V 0.7595V 0.4000nS 1.9585V 2.8120V 1.4075V 0.4500nS 2.5620V 3.1710V 2.0450V 0.5000nS 2.8780V 3.3210V 2.4690V 0.5500nS 3.0230V 3.3980V 2.6805V 0.6000nS 3.0975V 3.4430V 2.7815V 0.6500nS 3.1420V 3.4655V 2.8385V 0.7000nS 3.1703V 3.4787V 2.8750V 0.7500nS 3.1820V 3.4850V 2.8900V 0.8000nS 3.1865V 3.4880V 2.8955V 0.8500nS 3.1910V 3.4910V 2.9010V 0.9000nS 3.1945V 3.4935V 2.9040V 0.9500nS 3.1975V 3.4955V 2.9065V 1.0000nS 3.1995V 3.4975V 2.9085V 1.0500nS 3.2010V 3.4987V 2.9107V 1.1000nS 3.2025V 3.5000V 2.9120V 1.1500nS 3.2030V 3.5010V 2.9130V 1.2000nS 3.2040V 3.5010V 2.9135V 1.2500nS 3.2050V 3.5020V 2.9140V 1.3000nS 3.2055V 3.5025V 2.9150V 1.3500nS 3.2060V 3.5030V 2.9157V 1.4000nS 3.2070V 3.5035V 2.9160V 1.4500nS 3.2070V 3.5040V 2.9160V 1.5000nS 3.2070V 3.5040V 2.9165V 1.5500nS 3.2075V 3.5040V 2.9170V 1.6000nS 3.2080V 3.5040V 2.9170V 1.6500nS 3.2080V 3.5040V 2.9170V 1.7000nS 3.2080V 3.5050V 2.9170V 1.7500nS 3.2080V 3.5050V 2.9180V 1.8000nS 3.2080V 3.5050V 2.9180V 1.8500nS 3.2083V 3.5050V 2.9180V 1.9000nS 3.2090V 3.5050V 2.9180V 1.9500nS 3.2090V 3.5050V 2.9180V 2.0000nS 3.2090V 3.5050V 2.9180V 2.0500nS 3.2090V 3.5050V 2.9180V 2.1000nS 3.2090V 3.5050V 2.9180V 2.1500nS 3.2090V 3.5050V 2.9180V 2.2000nS 3.2090V 3.5050V 2.9180V 2.2500nS 3.2090V 3.5050V 2.9180V 2.3000nS 3.2090V 3.5050V 2.9180V 2.3500nS 3.2090V 3.5050V 2.9180V 2.4000nS 3.2090V 3.5050V 2.9180V 2.4500nS 3.2090V 3.5050V 2.9180V 2.5000nS 3.2090V 3.5050V 2.9180V | [Falling Waveform] R_fixture =3D 500 V_fixture =3D 0.0 V_fixture_min =3D 0.0 V_fixture_max =3D 0.0 | time V(typ) V(min) V(max) | 0.0000nS 3.2090V 3.5050V 2.9180V 0.0500nS 3.2075V 3.5035V 2.9165V 0.1000nS 3.2095V 3.5130V 2.9165V 0.1500nS 3.2393V 3.5363V 2.9397V 0.2000nS 3.2430V 3.4510V 2.9530V 0.2500nS 3.1370V 3.1900V 2.9277V 0.3000nS 2.9460V 2.8510V 2.8370V 0.3500nS 2.7410V 2.5210V 2.7100V 0.4000nS 2.3845V 1.9470V 2.4760V 0.4500nS 1.8905V 1.2175V 2.1400V 0.5000nS 1.2115V 0.6644V 1.6595V 0.5500nS 0.5945V 0.3833V 0.9952V 0.6000nS 0.2965V 0.2379V 0.4185V 0.6500nS 0.1669V 0.1461V 0.1754V 0.7000nS 87.1707mV 76.6810mV 77.1940mV 0.7500nS 47.8900mV 42.9260mV 41.8900mV 0.8000nS 30.9720mV 28.1035mV 26.8895mV 0.8500nS 17.2195mV 15.6240mV 14.9260mV 0.9000nS 10.0000mV 9.0005mV 8.9130mV 0.9500nS 6.3350mV 5.6495mV 5.7560mV 1.0000nS 4.3445mV 3.8495mV 3.9815mV 1.0500nS 2.9543mV 2.5603mV 2.7083mV 1.1000nS 2.1000mV 1.7610mV 1.9375mV 1.1500nS 1.7420mV 1.4330mV 1.6160mV 1.2000nS 1.4635mV 1.1815mV 1.3635mV 1.2500nS 1.1670mV 0.9189mV 1.0935mV 1.3000nS 0.9363mV 0.7191mV 0.8829mV 1.3500nS 0.7167mV 0.5337mV 0.6811mV 1.4000nS 0.5477mV 0.3952mV 0.5249mV 1.4500nS 0.4666mV 0.3304mV 0.4495mV 1.5000nS 0.3987mV 0.2773mV 0.3861mV 1.5500nS 0.3229mV 0.2192mV 0.3149mV 1.6000nS 0.2616mV 0.1734mV 0.2569mV 1.6500nS 0.2120mV 0.1371mV 0.2097mV 1.7000nS 0.1718mV 0.1085mV 0.1711mV 1.7500nS 0.1393mV 85.8720uV 0.1397mV 1.8000nS 0.1129mV 67.9720uV 0.1141mV 1.8500nS 87.0567uV 50.9073uV 88.7037uV 1.9000nS 66.8160uV 37.9235uV 68.6995uV 1.9500nS 57.0080uV 31.7890uV 58.9350uV 2.0000nS 48.7740uV 26.7435uV 50.6890uV 2.0500nS 39.5430uV 21.1970uV 41.3900uV 2.1000nS 32.0590uV 16.8095uV 33.7980uV 2.1500nS 25.9920uV 13.3380uV 27.5990uV 2.2000nS 21.0735uV 10.5915uV 22.5375uV 2.2500nS 17.0855uV 8.4185uV 18.4040uV 2.3000nS 13.8525uV 6.6990uV 15.0295uV 2.3500nS 11.2315uV 5.3385uV 12.2730uV 2.4000nS 8.6607uV 4.0417uV 9.5483uV 2.4500nS 6.6480uV 3.0540uV 7.3965uV 2.5000nS 5.6730uV 2.5880uV 6.3460uV | | End [Model] ALVCH_IO | | [END] ------_=_NextPart_000_01BFDA0F.91A31754-- From owner-ibis Mon Jun 19 10:57:45 2000 Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA16122 for ; Mon, 19 Jun 2000 10:57:44 -0700 (PDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Mon, 19 Jun 2000 13:52:55 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 13:52:34 -0400 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24020DB6A6@bcarua63.ca.nortel.com> From: "Hassan Ali" To: ibis users Subject: RE: 74ALVCH16501 Ibis Model Date: Mon, 19 Jun 2000 13:52:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDA17.24CC5B7E" 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_01BFDA17.24CC5B7E Content-Type: text/plain; charset="iso-8859-1" Would the model of the device made by Philips fit similar device (same logic family) made by TI? I always thought that there are subtle differences? Am I right? Hassan. -----Original Message----- From: Greim, Michael [mailto:mgreim@mc.com] Sent: Monday, June 19, 2000 12:58 PM To: 'Ben Manor'; ibis users Subject: RE: 74ALVCH16501 Ibis Model Here it is. It is can be found on the following site: http://www.philipslogic.com/support/ibis/alvc/ Enjoy..... <> Best Regards, Michael > -----Original Message----- > From: Ben Manor [SMTP:Ben_Manor@mentorg.com] > Sent: Monday, June 19, 2000 10:37 AM > To: ibis users > Subject: 74ALVCH16501 Ibis Model > > Not in TI's site. > Does anyone has it? > > THANKS > -- > ========================================================== > Ben Manor, Application Engineer - Mentor Graphics Israel > 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel > Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 > email: Ben_Manor@mentor.com Mobile: +972-53-415412 > ---------------------------------------------------------- << File: Card > for Ben Manor >> ------_=_NextPart_001_01BFDA17.24CC5B7E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 74ALVCH16501 Ibis Model

Would the model of the device made by Philips fit = similar device (same logic family) made by TI? I always thought that = there are subtle differences? Am I right?

Hassan.


-----Original Message-----
From: Greim, Michael [mailto:mgreim@mc.com]
Sent: Monday, June 19, 2000 12:58 PM
To: 'Ben Manor'; ibis users
Subject: RE: 74ALVCH16501 Ibis Model


Here it is.  It is can be found on the following = site:

http://www.philipslogic.com/support/ibis/alvc/

Enjoy.....

 <<h16501t.ibs>>

Best Regards,

Michael

> -----Original Message-----
> From: Ben Manor = [SMTP:Ben_Manor@mentorg.com]
> Sent: Monday, June 19, 2000 10:37 AM
> To:   ibis users
> Subject:      = 74ALVCH16501 Ibis Model
>
> Not in TI's site.
> Does anyone has it?
>
> THANKS
> --
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Ben Manor, Application Engineer - Mentor = Graphics Israel
> 41 Hagalim Blvd.   P.O.B. = 2155   Herzliya, 46120  Israel
> Tel:  +972-9-9552636  ext. = 119      Fax:  +972-9-9552627
> email: = Ben_Manor@mentor.com       Mobile: = +972-53-415412
> = ---------------------------------------------------------- << = File: Card
> for Ben Manor >>

------_=_NextPart_001_01BFDA17.24CC5B7E-- From owner-ibis Mon Jun 19 12:35:02 2000 Received: from mc.com ([192.233.16.119]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA16504 for ; Mon, 19 Jun 2000 12:35:02 -0700 (PDT) Received: from ruger.mc.com by mc.com (8.8.8+Sun/SMI-SVR4) id PAA18588; Mon, 19 Jun 2000 15:31:12 -0400 (EDT) Received: by ruger.mc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 15:31:12 -0400 Message-ID: From: "Greim, Michael" To: "'Hassan Ali'" , ibis users Subject: RE: 74ALVCH16501 Ibis Model Date: Mon, 19 Jun 2000 15:31:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain You are right that there should be subtle differences, but when push comes to shove, they will be crosses to one another when the product hits mfg, so from a simulation standpoint, your simulations should still achieve the desired results with this model. MG > -----Original Message----- > From: Hassan Ali [SMTP:hali@nortelnetworks.com] > Sent: Monday, June 19, 2000 1:52 PM > To: ibis users > Subject: RE: 74ALVCH16501 Ibis Model > > Would the model of the device made by Philips fit similar device (same > logic family) made by TI? I always thought that there are subtle > differences? Am I right? > > Hassan. > > > -----Original Message----- > From: Greim, Michael [ ] > Sent: Monday, June 19, 2000 12:58 PM > To: 'Ben Manor'; ibis users > Subject: RE: 74ALVCH16501 Ibis Model > > > Here it is. It is can be found on the following site: > > > > Enjoy..... > > <> > > Best Regards, > > Michael > > > -----Original Message----- > > From: Ben Manor [SMTP:Ben_Manor@mentorg.com] > > Sent: Monday, June 19, 2000 10:37 AM > > To: ibis users > > Subject: 74ALVCH16501 Ibis Model > > > > Not in TI's site. > > Does anyone has it? > > > > THANKS > > -- > > ========================================================== > > Ben Manor, Application Engineer - Mentor Graphics Israel > > 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel > > Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 > > email: Ben_Manor@mentor.com Mobile: +972-53-415412 > > ---------------------------------------------------------- << File: Card > > > for Ben Manor >> > From owner-ibis Mon Jun 19 12:39:56 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA16534 for ; Mon, 19 Jun 2000 12:39:55 -0700 (PDT) From: mike.magdaluyo@philips.com Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id VAA22415; Mon, 19 Jun 2000 21:37:37 +0200 (MEST) (envelope-from mike.magdaluyo@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma022413; Mon, 19 Jun 00 21:37:37 +0200 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id VAA07742; Mon, 19 Jun 2000 21:37:36 +0200 (MET DST) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910005610222; Mon, 19 Jun 2000 14:36:14 -0500 To: Cc: Subject: RE: 74ALVCH16501 Ibis Model Message-ID: <0056910005610222000002L122*@MHS> Date: Mon, 19 Jun 2000 14:36:14 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=0056910005610222" --Boundary=_0.0_=0056910005610222 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 06/19/00 14:37:21" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hassan, The Philips model can differ from the TI device for the output rise/fal= l times and drive current. Although we have alternate source agreement= s for various logic families, we have separate design teams and wafer f= abs. DC and AC specs can match but we=20 can implement circuits differently. The output edges aren't always the= same which will result in different responses in a transmission line. = I would not recommend using Philips' or TI's models to simulate each o= ther's parts. Regards, Mike Magdaluyo Logic Products Applications Philips Semiconductors (408) 991-2642 mike.magdaluyo@philips.com hali@nortelnetworks.com on 06/19/2000 11:57:13 AM To: ibis-users@eda.org@SMTP cc: =20 Subject: RE: 74ALVCH16501 Ibis Model Classification: Restricted Would the model of the device made by Philips fit similar device (same = logic family) made by TI? I always thought that there are subtle differences?= Am I right? Hassan. -----Original Message----- From: Greim, Michael [mailto:mgreim@mc.com] Sent: Monday, June 19, 2000 12:58 PM To: 'Ben Manor'; ibis users Subject: RE: 74ALVCH16501 Ibis Model Here it is. It is can be found on the following site: http://www.philipslogic.com/support/ibis/alvc/ Enjoy..... <> Best Regards, Michael > -----Original Message----- > From: Ben Manor [SMTP:Ben_Manor@mentorg.com] > Sent: Monday, June 19, 2000 10:37 AM > To: ibis users > Subject: 74ALVCH16501 Ibis Model > > Not in TI's site. > Does anyone has it? > > THANKS > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Ben Manor, Application Engineer - Mentor Graphics Israel > 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel > Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 > email: Ben_Manor@mentor.com Mobile: +972-53-415412 > ---------------------------------------------------------- << File: C= ard > for Ben Manor >> = --Boundary=_0.0_=0056910005610222 Content-Type: application/octet-stream; name=FILE0001.htm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=FILE0001.htm PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MS42NSI+DQo8VElUTEU+UkU6IDc0 QUxWQ0gxNjUwMSBJYmlzIE1vZGVsPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9O VCBTSVpFPTI+V291bGQgdGhlIG1vZGVsIG9mIHRoZSBkZXZpY2UgbWFkZSBieSBQaGlsaXBzIGZp dCBzaW1pbGFyIGRldmljZSAoc2FtZSBsb2dpYyBmYW1pbHkpIG1hZGUgYnkgVEk/IEkgYWx3YXlz IHRob3VnaHQgdGhhdCB0aGVyZSBhcmUgc3VidGxlIGRpZmZlcmVuY2VzPyBBbSBJIHJpZ2h0Pzwv Rk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5IYXNzYW4uPC9GT05UPg0KPC9QPg0KPEJSPg0K DQo8UD48Rk9OVCBTSVpFPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPkZyb206IEdyZWltLCBNaWNoYWVsIFs8QSBIUkVGPSJtYWlsdG86bWdyZWlt QG1jLmNvbSI+bWFpbHRvOm1ncmVpbUBtYy5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+U2VudDogTW9uZGF5LCBKdW5lIDE5LCAyMDAwIDEyOjU4IFBNPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5UbzogJ0JlbiBNYW5vcic7IGliaXMgdXNlcnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlN1YmplY3Q6IFJFOiA3NEFMVkNIMTY1MDEgSWJpcyBNb2RlbDwvRk9OVD4NCjwvUD4NCjxC Uj4NCg0KPFA+PEZPTlQgU0laRT0yPkhlcmUgaXQgaXMuJm5ic3A7IEl0IGlzIGNhbiBiZSBmb3Vu ZCBvbiB0aGUgZm9sbG93aW5nIHNpdGU6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ PEEgSFJFRj0iaHR0cDovL3d3dy5waGlsaXBzbG9naWMuY29tL3N1cHBvcnQvaWJpcy9hbHZjLyIg VEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly93d3cucGhpbGlwc2xvZ2ljLmNvbS9zdXBwb3J0L2liaXMv YWx2Yy88L0E+PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RW5qb3kuLi4uLjwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyZsdDsmbHQ7aDE2NTAxdC5pYnMmZ3Q7 Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CZXN0IFJlZ2FyZHMsPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TWljaGFlbDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgRnJvbTogQmVuIE1hbm9yIFtTTVRQOkJlbl9NYW5vckBtZW50b3JnLmNv bV08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogTW9uZGF5LCBKdW5lIDE5LCAy MDAwIDEwOjM3IEFNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRvOiZuYnNwOyZuYnNw OyBpYmlzIHVzZXJzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDc0QUxWQ0gxNjUwMSBJYmlzIE1vZGVsPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBOb3Qg aW4gVEkncyBzaXRlLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBEb2VzIGFueW9uZSBo YXMgaXQ/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBUSEFOS1M8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgLS0gPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg QmVuIE1hbm9yLCBBcHBsaWNhdGlvbiBFbmdpbmVlciAtIE1lbnRvciBHcmFwaGljcyBJc3JhZWw8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgNDEgSGFnYWxpbSBCbHZkLiZuYnNwOyZuYnNw OyBQLk8uQi4gMjE1NSZuYnNwOyZuYnNwOyBIZXJ6bGl5YSwgNDYxMjAmbmJzcDsgSXNyYWVsPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRlbDombmJzcDsgKzk3Mi05LTk1NTI2MzYmbmJz cDsgZXh0LiAxMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmF4OiZuYnNwOyArOTcy LTktOTU1MjYyNyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZW1haWw6IEJlbl9NYW5v ckBtZW50b3IuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1vYmlsZTog Kzk3Mi01My00MTU0MTI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAmbHQ7Jmx0OyBG aWxlOiBDYXJkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGZvciBCZW4gTWFub3IgJmd0 OyZndDsgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ --Boundary=_0.0_=0056910005610222-- From owner-ibis Mon Jun 19 12:52:14 2000 Received: from ausxc08.us.dell.com (ausxc08.us.dell.com [143.166.99.216]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA16560 for ; Mon, 19 Jun 2000 12:52:13 -0700 (PDT) From: Aubrey_Sparkman@Dell.com Received: by ausxc08.us.dell.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 14:49:35 -0500 Message-ID: <0340D4D07D98D311A60A00A0C92DCAF7017FB67E@ausxmbrh03.aus.amer.dell.com> To: mike.magdaluyo@philips.com, hali@nortelnetworks.com Cc: ibis-users@eda.org Subject: RE: 74ALVCH16501 Ibis Model Date: Mon, 19 Jun 2000 14:49:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFDA27.7E578D70" 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_000_01BFDA27.7E578D70 Content-Type: text/plain; charset="iso-8859-1" For a robust system design, you will want to make sure you system works with both. This means you may choose the "max" model from one supplier for the max conditions and choose the "min" model from another supplier to use in the min conditions. Bottom line is that if your design is on the edge with one supplier, you should re-consider allowing the second source. Aubrey Sparkman Signal Integrity Aubrey_Sparkman@Dell.com (512) 723-3592 > -----Original Message----- > From: mike.magdaluyo@philips.com [mailto:mike.magdaluyo@philips.com] > Sent: Monday, June 19, 2000 2:36 PM > To: hali@nortelnetworks.com > Cc: ibis-users@eda.org > Subject: RE: 74ALVCH16501 Ibis Model > > > Hassan, > > The Philips model can differ from the TI device for the > output rise/fall times and drive current. Although we have > alternate source agreements for various logic families, we > have separate design teams and wafer fabs. DC and AC specs > can match but we > can implement circuits differently. The output edges aren't > always the same which will result in different responses in a > transmission line. I would not recommend using Philips' or > TI's models to simulate each other's parts. > > Regards, > > Mike Magdaluyo > Logic Products Applications > Philips Semiconductors > (408) 991-2642 > mike.magdaluyo@philips.com > > > > > > hali@nortelnetworks.com on 06/19/2000 11:57:13 AM > To: ibis-users@eda.org@SMTP > cc: > Subject: RE: 74ALVCH16501 Ibis Model > Classification: Restricted > Would the model of the device made by Philips fit similar > device (same logic > family) made by TI? I always thought that there are subtle > differences? Am I > right? > > Hassan. > > > -----Original Message----- > From: Greim, Michael [mailto:mgreim@mc.com] > Sent: Monday, June 19, 2000 12:58 PM > To: 'Ben Manor'; ibis users > Subject: RE: 74ALVCH16501 Ibis Model > > > Here it is. It is can be found on the following site: > http://www.philipslogic.com/support/ibis/alvc/ Enjoy..... <> Best Regards, Michael > -----Original Message----- > From: Ben Manor [SMTP:Ben_Manor@mentorg.com] > Sent: Monday, June 19, 2000 10:37 AM > To: ibis users > Subject: 74ALVCH16501 Ibis Model > > Not in TI's site. > Does anyone has it? > > THANKS > -- > ========================================================== > Ben Manor, Application Engineer - Mentor Graphics Israel > 41 Hagalim Blvd. P.O.B. 2155 Herzliya, 46120 Israel > Tel: +972-9-9552636 ext. 119 Fax: +972-9-9552627 > email: Ben_Manor@mentor.com Mobile: +972-53-415412 > ---------------------------------------------------------- << File: Card > for Ben Manor >> ------_=_NextPart_000_01BFDA27.7E578D70 Content-Type: application/octet-stream; name="Sparkman, Aubrey.vcf" Content-Disposition: attachment; filename="Sparkman, Aubrey.vcf" BEGIN:VCARD VERSION:2.1 N:Sparkman;Aubrey FN:Sparkman, Aubrey EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com REV:19990728T212924Z END:VCARD ------_=_NextPart_000_01BFDA27.7E578D70-- From owner-ibis Mon Jun 19 17:17:40 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA17195 for ; Mon, 19 Jun 2000 17:17:39 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA26996; Mon, 19 Jun 2000 17:15:04 -0700 (PDT) Received: from orwtomda by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA23913; Mon, 19 Jun 2000 17:15:02 -0700 (PDT) Reply-To: From: "Tom Dagostino" To: "'Greim, Michael'" , "'Hassan Ali'" , "'ibis users'" Subject: RE: 74ALVCH16501 Ibis Model Date: Mon, 19 Jun 2000 15:51:32 -0700 Message-ID: <000101bfda4c$906808d0$83532293@wv.mentorg.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By