From owner-ibis Wed May 2 19:52:34 2001 Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [203.197.74.142]) by server.eda.org (8.11.0/8.11.0) with SMTP id f432qUj12085 for ; Wed, 2 May 2001 19:52:32 -0700 (PDT) Received: (qmail 16468 invoked from network); 3 May 2001 02:46:00 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 3 May 2001 02:46:00 -0000 Received: from localhost (sandeep@localhost) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with SMTP id IAA02368 for ; Thu, 3 May 2001 08:23:21 +0530 (IST) Date: Thu, 3 May 2001 08:23:21 +0530 (IST) From: "Bakshi Sandeep Trimbakrao(P00039)" To: "'ibis@vhdl.org'" Subject: unsubscribe In-Reply-To: <2179BC5B6583D311B44700508B441469041775D3@svr-orw-exc-02.wv.mentorg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please Unsubscribe me.. From owner-ibis Fri May 4 11:34:47 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f44IYej21576 for ; Fri, 4 May 2001 11:34:46 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA18183; Fri, 4 May 2001 11:33:57 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSKBHT7R; Fri, 4 May 2001 11:33:57 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3AF2F614.4547D5A5@mentor.com> Date: Fri, 04 May 2001 11:33:56 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Agenda 5/11/01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 5/11/01 Bridge Number Reservation # Passcode New Number --> (916) 356-2663 2 0210511 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Peters - Intros of New IBIS Participants, Meeting Quorum Peters - Membership Update and Treasurers Report Peters/Fleming - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Peters/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Peters - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Peters - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes DAC 2001 IBIS Summit Meeting Planning de Burgh/Peters IBIS Model Review Committee Angulo New Administrative Issues All 8:30 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella/Peters IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD70.3 - Golden Waveforms Edlund BIRD71 - Timing Test Loads in [Model Spec] to Support Peters PCI & PCI-X Other Pending BIRDS Peters ibischk3 Bug Tracking Peters - BUG56 - Parser Fails to Detect Always Flowing Current Flora New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Fri May 4 12:17:35 2001 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f44JHVj21695 for ; Fri, 4 May 2001 12:17:34 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA500284 for ; Fri, 4 May 2001 15:14:53 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id PAA40866 for ; Fri, 4 May 2001 15:11:14 -0400 Importance: Normal Subject: BIRD 70.3 To: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Fri, 4 May 2001 14:16:02 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.6a |January 17, 2001) at 05/04/2001 02:16:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii BIRD 70.3 has four new keywords for differential waveforms. I removed the "timing-related" subparameters in favor of using an extra set of Golden Waveforms that specify the standard (timing) test load. There is still one outstanding issue: what are the legal combinations of test_data_type and test_load_type? ******************************************************************************* ******************************************************************************* BIRD ID#: 70.3 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: March 16, 2001; April 16, 2001; April 18, 2001; May 4, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are eight Wavevform keywords whose scope is local. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: |============================================================================= | | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a set of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Test_load, | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "Single_ended" or "Differential." | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | |----------------------------------------------------------------------------- | [Test Data] Data1 Test_data_type Single_ended Driver_model Buffer1 Test_load Load1 | |============================================================================= | | Keywords: [Rising Waveform Near], [Falling Waveform Near], | [Rising Waveform Far], [Falling Waveform Far], | [Diff Rising Waveform Near], [Diff Falling Waveform Near], | [Diff Rising Waveform Far], [Diff Falling Waveform Far] | Required: At least one Rising/Falling waveform pair is required under | the scope of the [Test Data] keyword. | Description: Describes the shape of the rising and falling Golden | Waveforms of a given driver and a given [Test Load]. | A model developer may use the [Rising Waveform Near/Far] and | [Falling Waveform Near/Far] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of | SPICE and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |----------------------------------------------------------------------------- | [Rising Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= | | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables correspond to a given [Test Load] which is specified | by the Test_load subparameter under the [Test Data] keyword. | | Sub-Params: Test_data_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, R_diff_near, | R_diff_far. | | Usage Rules: The value of the Test_data_type subparameter must be either | "Single_ended" or "Differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_data_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [voltage range] keyword. | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | If Test_load_type is differential, a the test load is a | pair of the above circuits. If the R_diff_near subparameter | is used, it is connected between the near nodes of the two | circuits. If the R_diff_far subparameter is used, it is | connected between the near nodes of the two circuits. | |----------------------------------------------------------------------------- | [Test Load] Load1 Test_load_type Single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 | |----------------------------------------------------------------------------- ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1/70.2: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Waveform Near/Far]. Changed [Falling Waveform] to [Falling Waveform Near/Far]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the Vx_rise/fall subparameters to indicate the end of a timing interval for timing correlation. 6. Added Tmeas_rise/fall to facilitate timing correlation. 7. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 8. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 9. Moved Driver_model and Test_load under the scope of [Test Data]. 10. R_diff became R_diff_near and R_diff_far. 11. Removed timing-related keywords: Tmeas_rise, Tmeas_fall, Vx_rise, Vx_fall This function can be achieved with less complexity by including a Golden Waveform that represents the standard (timing) test load. 12. Added four differential waveform keywords. BIRD 70.3 adds 192 lines of code to IBIS, of which 138 are comments. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. ****************************************************************************** Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Fri May 4 22:27:18 2001 Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f455RHj23215 for ; Fri, 4 May 2001 22:27:18 -0700 (PDT) Received: from rosebud.al.dynip.com (c207-202-218-223.sea1.cablespeed.com [207.202.218.223]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id WAA09875; Fri, 4 May 2001 22:26:36 -0700 Received: from hobbes ([192.168.22.7]) by rosebud.al.dynip.com (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with SMTP id f455RsU26908; Fri, 4 May 2001 22:27:54 -0700 X-Authentication-Warning: rosebud.al.dynip.com: Host [192.168.22.7] claimed to be hobbes From: Al Davis To: "Gregory R Edlund" , ibis@vhdl.org Subject: Re: BIRD 70.3 Date: Fri, 4 May 2001 22:27:50 -0700 X-Mailer: KMail [version 1.1.61] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01050422275001.20482@hobbes> Content-Transfer-Encoding: 8bit On Fri, 04 May 2001, Gregory R Edlund wrote: > BIRD 70.3 has four new keywords for differential waveforms. > > I removed the "timing-related" subparameters in favor of using an > extra set of Golden Waveforms that > specify the standard (timing) test load. > > There is still one outstanding issue: what are the legal > combinations of test_data_type and test_load_type? That's easy. Just say they need to be the same. It needs clarification of the meaning of the various waveforms, and which can be used with which type. Something like: Diff waveforms are only used with type differential, and are measured differentially. The other waveforms may be used with either single_ended or differential types. When used with the differential type, they represent the common mode waveforms, measured from one side to ground. It would probably be an improvement to explicitly say they are common-mode, as in [Common Mode Rising Waveform Near], so the Diff or Common forms are used with type differential, and the plain is used with single-ended. Reason: the plain one will be interpreted as the most significant, but in differential mode the differential one really is. From owner-ibis Mon May 7 13:26:51 2001 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f47KQlj07494 for ; Mon, 7 May 2001 13:26:50 -0700 (PDT) Received: from us-ea-gtwy-6.ea.unisys.com (us-ea-gtwy-6.ea.unisys.com [192.61.146.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id UAA12462 for ; Mon, 7 May 2001 20:24:44 GMT Received: by us-ea-gtwy-6.ea.unisys.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 15:26:08 -0500 Message-ID: From: "Mahoney, Margaret" To: ibis@eda.org Subject: Schottky barrier diode Date: Mon, 7 May 2001 15:27:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D734.13B8E710" 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_01C0D734.13B8E710 Content-Type: text/plain; charset="iso-8859-1" Hello, I am attempting to model a schottky barrier diode in IBIS. Attached is the ibis file I have created. The power and ground clamp tables were extracted from HSpice simulations and I have set the transit time parameters for both the power and ground clamp to zero. Is this the correct representation of a schottky barrier diode? Thanks in advance for your help. Maggie Mahoney ------_=_NextPart_000_01C0D734.13B8E710 Content-Type: application/octet-stream; name="clamp_3.ibs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="clamp_3.ibs" [IBIS Ver] 3.2 | [File name] clamp_3.ibs | [File Rev] 1.0 | [Date] April 27, 2001 | =20 [Source] =20 [Notes] =20 | [Disclaimer] =20 | [Copyright] =20 | | |-----------------------------------------------------------------------= -------| | [Component] CLAMP [Manufacturer] Unisys | [Package] |variable typ min max R_pkg 0 NA NA L_pkg 0 NA NA C_pkg 0 NA NA | | [Pin] signal_name model_name 1 CLAMP INPUT=20 2 VSS GND 3 VDD POWER | =20 [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref = power_clamp_ref 1 VSS VDD VSS VDD 2 VSS NC NC NC 3 NC VDD NC NC |=20 |-----------------------------------------------------------------------= -------| | End Pin Mapping |-----------------------------------------------------------------------= -------| | [Model] INPUT Model_type Input | Vinl =3D 0.8000V=20 Vinh =3D 2.0000V=20 | typ min max C_comp 1.000pF NA NA [Voltage Range] 1.8000V NA NA=20 | [POWER Clamp] |Voltage I(typ) I(min) I(max) Table is Vcc-relative -1.800 0.536 NA NA =20 -1.782 0.529 NA NA =20 -1.764 0.522 NA NA =20 -1.745 0.515 NA NA =20 -1.727 0.509 NA NA =20 -1.709 0.502 NA NA =20 -1.691 0.495 NA NA =20 -1.673 0.488 NA NA =20 -1.655 0.482 NA NA =20 -1.636 0.475 NA NA =20 -1.618 0.468 NA NA =20 -1.600 0.461 NA NA =20 -1.582 0.455 NA NA =20 -1.564 0.448 NA NA =20 -1.545 0.441 NA NA =20 -1.527 0.434 NA NA =20 -1.509 0.428 NA NA =20 -1.491 0.421 NA NA =20 -1.473 0.414 NA NA =20 -1.455 0.407 NA NA =20 -1.436 0.401 NA NA =20 -1.418 0.394 NA NA =20 -1.400 0.387 NA NA =20 -1.382 0.380 NA NA =20 -1.364 0.374 NA NA =20 -1.345 0.367 NA NA =20 -1.327 0.360 NA NA =20 -1.309 0.354 NA NA =20 -1.291 0.347 NA NA =20 -1.273 0.340 NA NA =20 -1.255 0.334 NA NA =20 -1.236 0.327 NA NA =20 -1.218 0.320 NA NA =20 -1.200 0.313 NA NA =20 -1.182 0.307 NA NA =20 -1.164 0.300 NA NA =20 -1.145 0.293 NA NA =20 -1.127 0.287 NA NA =20 -1.109 0.280 NA NA =20 -1.091 0.273 NA NA =20 -1.073 0.267 NA NA =20 -1.055 0.260 NA NA =20 -1.036 0.254 NA NA =20 -1.018 0.247 NA NA =20 -1.000 0.240 NA NA =20 -0.982 0.234 NA NA =20 -0.964 0.227 NA NA =20 -0.945 0.220 NA NA =20 -0.927 0.214 NA NA =20 -0.909 0.207 NA NA =20 -0.891 0.201 NA NA =20 -0.873 0.194 NA NA =20 -0.855 0.188 NA NA =20 -0.836 0.181 NA NA =20 -0.818 0.175 NA NA =20 -0.800 0.168 NA NA =20 -0.782 0.162 NA NA =20 -0.764 0.155 NA NA =20 -0.745 0.149 NA NA =20 -0.727 0.142 NA NA =20 -0.709 0.136 NA NA =20 -0.691 0.129 NA NA =20 -0.673 0.123 NA NA =20 -0.655 0.117 NA NA =20 -0.636 0.110 NA NA =20 -0.618 0.104 NA NA =20 -0.600 0.098 NA NA =20 -0.582 0.091 NA NA =20 -0.564 0.085 NA NA =20 -0.545 0.079 NA NA =20 -0.527 0.073 NA NA =20 -0.509 0.067 NA NA =20 -0.491 0.061 NA NA =20 -0.473 0.055 NA NA =20 -0.455 0.049 NA NA =20 -0.436 0.044 NA NA =20 -0.418 0.038 NA NA =20 -0.400 0.033 NA NA =20 -0.382 0.028 NA NA =20 -0.364 0.023 NA NA =20 -0.345 0.018 NA NA =20 -0.327 0.014 NA NA =20 -0.309 0.011 NA NA =20 -0.291 0.008 NA NA =20 -0.273 0.005 NA NA =20 -0.255 0.003 NA NA =20 -0.236 0.002 NA NA =20 -0.218 0.002 NA NA =20 -0.200 0.001 NA NA =20 -0.182 0.001 NA NA =20 -0.164 0.000 NA NA =20 -0.145 0.000 NA NA =20 -0.127 0.000 NA NA =20 -0.109 0.000 NA NA =20 -0.091 0.000 NA NA =20 -0.073 0.000 NA NA =20 -0.055 0.000 NA NA =20 -0.036 0.000 NA NA =20 -0.018 0.000 NA NA =20 0.000 0.000 NA NA =20 | | [GND Clamp] |Voltage I(typ) I(min) I(max)=20 | -1.800 -0.536 NA NA =20 -1.764 -0.522 NA NA =20 -1.727 -0.509 NA NA =20 -1.691 -0.495 NA NA =20 -1.654 -0.482 NA NA =20 -1.618 -0.468 NA NA =20 -1.582 -0.455 NA NA =20 -1.545 -0.441 NA NA =20 -1.509 -0.428 NA NA =20 -1.473 -0.414 NA NA =20 -1.436 -0.401 NA NA =20 -1.400 -0.387 NA NA =20 -1.364 -0.374 NA NA =20 -1.327 -0.360 NA NA =20 -1.291 -0.347 NA NA =20 -1.255 -0.334 NA NA =20 -1.218 -0.320 NA NA =20 -1.182 -0.307 NA NA =20 -1.145 -0.293 NA NA =20 -1.109 -0.280 NA NA =20 -1.073 -0.267 NA NA =20 -1.036 -0.254 NA NA =20 -1.000 -0.240 NA NA =20 -0.964 -0.227 NA NA =20 -0.927 -0.214 NA NA =20 -0.891 -0.201 NA NA =20 -0.855 -0.188 NA NA =20 -0.818 -0.175 NA NA =20 -0.782 -0.162 NA NA =20 -0.745 -0.149 NA NA =20 -0.709 -0.136 NA NA =20 -0.673 -0.123 NA NA =20 -0.636 -0.110 NA NA =20 -0.600 -0.098 NA NA =20 -0.564 -0.085 NA NA =20 -0.527 -0.073 NA NA =20 -0.491 -0.061 NA NA =20 -0.455 -0.049 NA NA =20 -0.418 -0.038 NA NA =20 -0.382 -0.028 NA NA =20 -0.345 -0.018 NA NA =20 -0.309 -0.010 NA NA =20 -0.273 -0.005 NA NA =20 -0.236 -0.002 NA NA =20 -0.200 -0.001 NA NA =20 -0.164 0.000 NA NA =20 -0.127 0.000 NA NA =20 -0.091 0.000 NA NA =20 -0.055 0.000 NA NA =20 -0.018 0.000 NA NA =20 0.018 0.000 NA NA =20 0.055 0.000 NA NA =20 0.091 0.000 NA NA =20 0.127 0.000 NA NA =20 0.164 0.000 NA NA =20 0.200 0.000 NA NA =20 0.236 0.000 NA NA =20 0.273 0.000 NA NA =20 0.309 0.000 NA NA =20 0.345 0.000 NA NA =20 0.382 0.000 NA NA =20 0.418 0.000 NA NA =20 0.455 0.000 NA NA =20 0.491 0.000 NA NA =20 0.527 0.000 NA NA =20 0.564 0.000 NA NA =20 0.600 0.000 NA NA =20 0.636 0.000 NA NA =20 0.673 0.000 NA NA =20 0.709 0.000 NA NA =20 0.745 0.000 NA NA =20 0.782 0.000 NA NA =20 0.818 0.000 NA NA =20 0.855 0.000 NA NA =20 0.891 0.000 NA NA =20 0.927 0.000 NA NA =20 0.964 0.000 NA NA =20 1.000 0.000 NA NA =20 1.036 0.000 NA NA =20 1.073 0.000 NA NA =20 1.109 0.000 NA NA =20 1.145 0.000 NA NA =20 1.182 0.000 NA NA =20 1.218 0.000 NA NA =20 1.255 0.000 NA NA =20 1.291 0.000 NA NA =20 1.327 0.000 NA NA =20 1.364 0.000 NA NA =20 1.400 0.000 NA NA =20 1.436 0.000 NA NA =20 1.473 0.000 NA NA =20 1.509 0.000 NA NA =20 1.545 0.000 NA NA =20 1.582 0.000 NA NA =20 1.618 0.000 NA NA =20 1.655 0.000 NA NA =20 1.691 0.000 NA NA =20 1.727 0.000 NA NA =20 1.764 0.000 NA NA =20 1.800 0.000 NA NA =20 | |variable TT(typ) TT(min) TT(max) [TTpower] 0ns NA NA [TTgnd] 0ns NA NA | END =20 ------_=_NextPart_000_01C0D734.13B8E710-- From owner-ibis Thu May 10 16:45:06 2001 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4ANj3929178 for ; Thu, 10 May 2001 16:45:05 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id XAA26335 for ; Thu, 10 May 2001 23:44:03 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 May 2001 23:44:02 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 16:44:01 -0700 Message-ID: <10C8636AE359D4119118009027AE99870515544B@FMSMSX34> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Thu, 10 May 2001 16:43:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Stephen, I have seen some specs (system bus on P4 platforms) which also include transmission lines and series inductors, and other elements (describing a package at the ends of the T-line) in the reference or test load. Even though I strongly disagree with such test loads, I feel we should address these too in the IBIS spec. Do you think that this BIRD could be used to extend the variety of load circuits? Arpad ================================================================= Date: Mon, 30 Apr 2001 15:19:51 -0700 From: Bob Ross To: ibis@eda.org CC: stephen.peters@intel.com Subject: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PCI & PCI-X To IBIS Committee: Stephen Peters is submitting BIRD71 for consideration in IBIS Version 4.0. Bob Ross Mentor Graphics **************************************************************************** ** **************************************************************************** ** BIRD ID#: 71 ISSUE TITLE: Timing Test Loads in [Model Spec] to Support PCI & PCI-X REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: April 30, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The IBIS specification lacks a way to specify minimum and maximum values for timing test load parameters. In addition, the current set of timing test load parameters (Cref, Rref) are applied to both edges of an output waveform, thus making them inadequate for describing the timing tests loads used by the PCI-X bus specification. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following additional subparameters are added to the [Model Spec] keyword: Cref, Rref, Vref_rising, Vref_falling, Cref_rising, Cref_falling, Rref_rising, Rref_falling, Vmeas_rising, Vmeas_falling. Changes and additions to the [Model Spec] keyword are shown by the |* lines |=========================================================================== == | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas |* Vref, Cref, Rref, Cref_rising, Cref_falling, Rref_rising, |* Rref_falling, Vref_rising, Vref_falling, Vmeas_rising, |* Vmeas_falling. | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Vmeas Measurement voltage for timing measurements | Vref Timing specification test load voltage |* Cref Timing specification capacitive load |* Rref Timing specification resistance load |* Cref_rising Timing spec capacitive load for rising edges |* Cref_falling Timing spec capacitive load for falling edges |* Rref_rising Timing spec resistance load for rising edges |* Rref_falling Timing spec resistance load for falling edges |* Vref_rising Timing spec test load voltage for rising edges |* Vref_falling Timing spec test load voltage for falling edges |* Vmeas_rising Measurement voltage for rising edge timing |* measurements |* Vmeas_falling Measurement voltage for falling edge timing |* measurements | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab character. All four columns are required under | the [Model Spec] keyword. However, data is required only in | the typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used indicating the | typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | be interchanged such that the Vinl value is larger than the | Vinh value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the voltage values | for which the model is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. | |* Vmeas, Vref, Cref, Rref rules: |* |* The Vmeas, Vref, Cref and Rref values under the [Model Spec] |* keyword override their respective values entered elsewhere. |* Note that a Vmeas, Vref, Cref or Rref subparameters may not be |* used if its edge specific version (*_rising or *_falling) is |* used. |* |* Cref_rising, Cref_falling, Rref_rising, Rref_falling, |* Vref_rising, Vref_falling, Vmeas_rising, Vmeas_falling rules: |* |* Use these subparameters when specifying separate timing test |* loads and voltages for rising and falling edges. If one |* 'rising' or 'falling' subparameter is used, then the |* corresponding 'rising' or 'falling' subparameter must be |* present. The values listed in these subparameters override any |* corresponding Cref, Vref, Rref or Vmeas values entered |* elsewhere. |--------------------------------------------------------------------------- -- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | | Timing test load voltage reference example | Vref 1.25 1.15 1.35 | An SSTL-2 example | |* BEGIN ADDED EXAMPLE |* |* rising and falling timing test load example (values from PCI-X spec) |* Cref_falling 10p 10p 10p Cref_rising 10p 10p 10p Rref_rising 25 500 25 | typ value not specified Rref_falling 25 500 25 | typ value not specified Vref_rising 0 1.5 0 Vref_falling 3.3 1.5 3.6 Vmeas_rising 0.941 0.885 1.026 | vmeas = 0.285(vcc) Vmeas_falling 2.0295 1.845 2.214 | vmeas = 0.615(vcc) |* |* |* END ADDED EXAMPLE |=========================================================================== == **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDxx is issued because of a long standing problem with specifying PCI compliant drivers. In PCI 2.2, minimum timing values are specified into a 0pF load, while maximum timing parameters are specified into a 50pF load. There was no way to specify this cleanly in IBIS. In addition, the PCI-X specification goes even further in specifying separate timing test loads for maximum rising and falling edges, and a single test load for the minimum case. In order to satisy the PCI-X spec all eight variations of Cref, Vref, Rref and Vmeas has to be included. Note that the PCI-X minimum test load is represented by it's Thevinen equivalent. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: **************************************************************************** ** ---End of forwarded mail from Bob Ross From owner-ibis Thu May 10 17:41:33 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4B0fV929351 for ; Thu, 10 May 2001 17:41:32 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA15473; Thu, 10 May 2001 17:40:47 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 17:40:54 -0700 Message-ID: <0EC6ED94FF36D511BCE900508BB83C1D4F6CD6@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'Muranyi, Arpad'" , "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Thu, 10 May 2001 17:40:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Arpad, I don't think the IBIS specification should allow these test loads. It is a mis-understanding of the purpose of these test loads that results in these abuses. IBIS should lead by explaining to the community the real purpose of test loads and why it is important. Adding this capability to the IBIS specification would definitely be in the wrong direction. Chris -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com] Sent: Thursday, May 10, 2001 4:44 PM To: 'ibis@eda.org' Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Stephen, I have seen some specs (system bus on P4 platforms) which also include transmission lines and series inductors, and other elements (describing a package at the ends of the T-line) in the reference or test load. Even though I strongly disagree with such test loads, I feel we should address these too in the IBIS spec. Do you think that this BIRD could be used to extend the variety of load circuits? Arpad ================================================================= Date: Mon, 30 Apr 2001 15:19:51 -0700 From: Bob Ross To: ibis@eda.org CC: stephen.peters@intel.com Subject: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PCI & PCI-X To IBIS Committee: Stephen Peters is submitting BIRD71 for consideration in IBIS Version 4.0. Bob Ross Mentor Graphics **************************************************************************** ** **************************************************************************** ** BIRD ID#: 71 ISSUE TITLE: Timing Test Loads in [Model Spec] to Support PCI & PCI-X REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: April 30, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The IBIS specification lacks a way to specify minimum and maximum values for timing test load parameters. In addition, the current set of timing test load parameters (Cref, Rref) are applied to both edges of an output waveform, thus making them inadequate for describing the timing tests loads used by the PCI-X bus specification. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following additional subparameters are added to the [Model Spec] keyword: Cref, Rref, Vref_rising, Vref_falling, Cref_rising, Cref_falling, Rref_rising, Rref_falling, Vmeas_rising, Vmeas_falling. Changes and additions to the [Model Spec] keyword are shown by the |* lines |=========================================================================== == | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas |* Vref, Cref, Rref, Cref_rising, Cref_falling, Rref_rising, |* Rref_falling, Vref_rising, Vref_falling, Vmeas_rising, |* Vmeas_falling. | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Vmeas Measurement voltage for timing measurements | Vref Timing specification test load voltage |* Cref Timing specification capacitive load |* Rref Timing specification resistance load |* Cref_rising Timing spec capacitive load for rising edges |* Cref_falling Timing spec capacitive load for falling edges |* Rref_rising Timing spec resistance load for rising edges |* Rref_falling Timing spec resistance load for falling edges |* Vref_rising Timing spec test load voltage for rising edges |* Vref_falling Timing spec test load voltage for falling edges |* Vmeas_rising Measurement voltage for rising edge timing |* measurements |* Vmeas_falling Measurement voltage for falling edge timing |* measurements | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab character. All four columns are required under | the [Model Spec] keyword. However, data is required only in | the typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used indicating the | typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | be interchanged such that the Vinl value is larger than the | Vinh value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the voltage values | for which the model is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. | |* Vmeas, Vref, Cref, Rref rules: |* |* The Vmeas, Vref, Cref and Rref values under the [Model Spec] |* keyword override their respective values entered elsewhere. |* Note that a Vmeas, Vref, Cref or Rref subparameters may not be |* used if its edge specific version (*_rising or *_falling) is |* used. |* |* Cref_rising, Cref_falling, Rref_rising, Rref_falling, |* Vref_rising, Vref_falling, Vmeas_rising, Vmeas_falling rules: |* |* Use these subparameters when specifying separate timing test |* loads and voltages for rising and falling edges. If one |* 'rising' or 'falling' subparameter is used, then the |* corresponding 'rising' or 'falling' subparameter must be |* present. The values listed in these subparameters override any |* corresponding Cref, Vref, Rref or Vmeas values entered |* elsewhere. |--------------------------------------------------------------------------- -- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | | Timing test load voltage reference example | Vref 1.25 1.15 1.35 | An SSTL-2 example | |* BEGIN ADDED EXAMPLE |* |* rising and falling timing test load example (values from PCI-X spec) |* Cref_falling 10p 10p 10p Cref_rising 10p 10p 10p Rref_rising 25 500 25 | typ value not specified Rref_falling 25 500 25 | typ value not specified Vref_rising 0 1.5 0 Vref_falling 3.3 1.5 3.6 Vmeas_rising 0.941 0.885 1.026 | vmeas = 0.285(vcc) Vmeas_falling 2.0295 1.845 2.214 | vmeas = 0.615(vcc) |* |* |* END ADDED EXAMPLE |=========================================================================== == **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDxx is issued because of a long standing problem with specifying PCI compliant drivers. In PCI 2.2, minimum timing values are specified into a 0pF load, while maximum timing parameters are specified into a 50pF load. There was no way to specify this cleanly in IBIS. In addition, the PCI-X specification goes even further in specifying separate timing test loads for maximum rising and falling edges, and a single test load for the minimum case. In order to satisy the PCI-X spec all eight variations of Cref, Vref, Rref and Vmeas has to be included. Note that the PCI-X minimum test load is represented by it's Thevinen equivalent. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: **************************************************************************** ** ---End of forwarded mail from Bob Ross From owner-ibis Fri May 11 09:07:10 2001 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BG77T02673 for ; Fri, 11 May 2001 09:07:08 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id B3DD8C41; Fri, 11 May 2001 09:09:14 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 70278F55 for ; Fri, 11 May 2001 09:09:14 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 11 May 2001 12:06:19 -0400 Message-ID: From: "Ingraham, Andrew" To: "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Fri, 11 May 2001 12:06:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain > I don't think the IBIS specification should allow these test > loads. It is a mis-understanding of the purpose of these > test loads that results in these abuses. IBIS should lead > by explaining to the community the real purpose of test > loads and why it is important. I haven't been paying full attention lately (too much stuff going on!), but thought I'd chime in at this point. In digital logic, most real loads look like unterminated transmission lines, with some capacitance sprinkled in. The old lumped C or R-C load right on the DUT pin is unrepresentative, and may be inadequate as a test load. That is, in fact, why PCI 2.1 (not PCI-X, by the way) changed from the ancient 50pF test load, to the two 25 ohm loads (for 3.3V PCI parts), each representing a pair of 50 ohm traces in parallel; one case with the lines previously in the low state, the other in the high state. This test load emulates infinitely-long transmission lines, which is somewhat unrealistic (but more representative than the lumped load). Not only that, but there are times when a few nanoseconds of transmission line, is a partciularly useful "test" load, such as when comparing simulations of an IBIS model to a SPICE model. And it's a good, quick way to visually see how a part behaves when its output "rattles around," quickly exercising how the output transistors both source and sink current (as the outputs go beyond the rails), as well as ESD clamping, reflection coefficient, die capacitance, and package impedance. You can reveal a lot about a part ... or its model ... in one quick test, which the old lumped R-C model can never show. Regards, Andy From owner-ibis Fri May 11 09:31:04 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BGV1T02781 for ; Fri, 11 May 2001 09:31:02 -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 MAA27556 for ; Fri, 11 May 2001 12:30:17 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA20082 for ; Fri, 11 May 2001 12:30:16 -0400 (EDT) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id JAA16726 for ; Fri, 11 May 2001 09:30:07 -0700 (PDT) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id JAA06522; Fri, 11 May 2001 09:30:13 -0700 Date: Fri, 11 May 2001 09:30:13 -0700 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200105111630.JAA06522@f22.innoveda.com> To: ibis@eda.org Subject: DAC 2001 IBIS Meeting Announcement D A C 2 0 0 1 I B I S S U M M I T M E E T I N G S E C O N D A N N O U N C E M E N T DATE: Thursday, June 21, 2001 TIME: 8:30 AM - 5:00 PM CITY: Las Vegas, Nevada LOCATION: Las Vegas Hilton Hotel (adjacent to the Convention Center) ROOM: To be Announced LUNCH: Free Refreshments and Lunch will be provided. AGENDA: The agenda is being planned. Some planned items are: Election of Officers for 2001 - 2002 Connector Specification IBIS-X IBIS Version 4.0 Issues Possibly other topics such as enhanced buffer extraction and driver schedule modeling. We welcome presentations and discussions on IBIS topics. DAC 2001: DAC is scheduled Monday - Friday, June 18 - 22, 2001. The exhibitor portion is open from Monday - Wednesday. For more information on DAC 2001 activities, housing, etc., visit the DAC URL: DAC URL: http://www.dac.com/ CALL FOR PRESENTATIONS: We are also open to technical presentations (usually 30 minutes or less) related to any current IBIS activity and to future IBIS needs. Contact Guy de Burgh regarding your presentation: Presenter: Title: Estimated Time: Please plan to use regular overhead slides for the presentation. It is possible that an LCD projector will be available, but do not assume this to be so at this time. We would like you to provide handouts for the meeting (about 25) and also an electronic copy for archiving. CALL FOR ATTENDEES: Please let Guy de Burgh know if you are planning to attend so we have an estimate on food requirements. CONTACT: Guy de Burgh IBIS Secretary gdeburgh@innoveda.com (805) 988-8250 ext. 6823 From owner-ibis Fri May 11 10:01:14 2001 Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BH1CT02994 for ; Fri, 11 May 2001 10:01:13 -0700 (PDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id RAA20465 for ; Fri, 11 May 2001 17:00:25 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 11 May 2001 17:00:27 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 10:00:26 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A771F@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'Ingraham, Andrew'" , "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Fri, 11 May 2001 10:00:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Andy: I agree that a testing a model with something other than a simple RC is necessary to test the goodness of a model. I wish more folks would validate their models with realistic transmission line type loads before releasing them. However, the purpose of the timing test load is not to test a buffers response in an environment with reflections, etc. -- it's to measure Tco. For that, the timing test load should be something that produces a clean, full-switching edge at the nominal impedance of the intended application. I think that is what Chris was getting at, and I tend to agree. Regards, Stephen Peters Intel Corp. -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Friday, May 11, 2001 9:06 AM To: 'ibis@eda.org' Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X > I don't think the IBIS specification should allow these test > loads. It is a mis-understanding of the purpose of these > test loads that results in these abuses. IBIS should lead > by explaining to the community the real purpose of test > loads and why it is important. I haven't been paying full attention lately (too much stuff going on!), but thought I'd chime in at this point. In digital logic, most real loads look like unterminated transmission lines, with some capacitance sprinkled in. The old lumped C or R-C load right on the DUT pin is unrepresentative, and may be inadequate as a test load. That is, in fact, why PCI 2.1 (not PCI-X, by the way) changed from the ancient 50pF test load, to the two 25 ohm loads (for 3.3V PCI parts), each representing a pair of 50 ohm traces in parallel; one case with the lines previously in the low state, the other in the high state. This test load emulates infinitely-long transmission lines, which is somewhat unrealistic (but more representative than the lumped load). Not only that, but there are times when a few nanoseconds of transmission line, is a partciularly useful "test" load, such as when comparing simulations of an IBIS model to a SPICE model. And it's a good, quick way to visually see how a part behaves when its output "rattles around," quickly exercising how the output transistors both source and sink current (as the outputs go beyond the rails), as well as ESD clamping, reflection coefficient, die capacitance, and package impedance. You can reveal a lot about a part ... or its model ... in one quick test, which the old lumped R-C model can never show. Regards, Andy From owner-ibis Fri May 11 10:08:08 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BH85T03036 for ; Fri, 11 May 2001 10:08:07 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA10644; Fri, 11 May 2001 10:07:19 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 10:07:28 -0700 Message-ID: <0EC6ED94FF36D511BCE900508BB83C1D4F6CD7@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'Ingraham, Andrew'" , "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Fri, 11 May 2001 10:07:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Andrew, Using the 25 ohm loads makes a lot of sense. Allowing a timing test load for a rising edge that is different from the falling edge may also be a good idea. Testing a model with a real transmission line network is useful to see if the IBIS model really captures the behavior of the model under these conditions (with reflections coming back.) There is an IBIS effort to define how to measure the accuracy of IBIS models and that group is considering various transmission line loads. However, the purpose of the timing test load is very specific and important. The delay through the component, as specified by the IC vendor, is the time from the logic switch of a receiver to the time a driver reaches vmeas in response. That is the value the timing analysis tools work with. The SI tools deliver the interconnect delays which is the time that the receiver on the other end of the interconnect switches minus the time-to-vmeas for the driver. Thus the timing tools and the SI tools can work together. More complex timing test loads would just make it more difficult for timing tools and SI tools to cooperate. For example if the reflection from the transmission line causes multiple crossings of the Vmeas threshold, which one is the right one? The IBIS accuracy work may add complex loads to the IBIS spec for the purposes of validating models, but such complex loads are not desirable for timing test loads. Thanks, Chris -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Friday, May 11, 2001 9:06 AM To: 'ibis@eda.org' Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X > I don't think the IBIS specification should allow these test > loads. It is a mis-understanding of the purpose of these > test loads that results in these abuses. IBIS should lead > by explaining to the community the real purpose of test > loads and why it is important. I haven't been paying full attention lately (too much stuff going on!), but thought I'd chime in at this point. In digital logic, most real loads look like unterminated transmission lines, with some capacitance sprinkled in. The old lumped C or R-C load right on the DUT pin is unrepresentative, and may be inadequate as a test load. That is, in fact, why PCI 2.1 (not PCI-X, by the way) changed from the ancient 50pF test load, to the two 25 ohm loads (for 3.3V PCI parts), each representing a pair of 50 ohm traces in parallel; one case with the lines previously in the low state, the other in the high state. This test load emulates infinitely-long transmission lines, which is somewhat unrealistic (but more representative than the lumped load). Not only that, but there are times when a few nanoseconds of transmission line, is a partciularly useful "test" load, such as when comparing simulations of an IBIS model to a SPICE model. And it's a good, quick way to visually see how a part behaves when its output "rattles around," quickly exercising how the output transistors both source and sink current (as the outputs go beyond the rails), as well as ESD clamping, reflection coefficient, die capacitance, and package impedance. You can reveal a lot about a part ... or its model ... in one quick test, which the old lumped R-C model can never show. Regards, Andy From owner-ibis Fri May 11 10:09:49 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BH9lT03059 for ; Fri, 11 May 2001 10:09:48 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA10764; Fri, 11 May 2001 10:08:57 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 10:09:05 -0700 Message-ID: <0EC6ED94FF36D511BCE900508BB83C1D4F6CD8@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'Peters, Stephen'" , "'Ingraham, Andrew'" , "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Fri, 11 May 2001 10:09:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Stephen, Yes! Your response came in at the same time I sent my own response. I believe we are saying the same thing. Chris -----Original Message----- From: Peters, Stephen [mailto:stephen.peters@intel.com] Sent: Friday, May 11, 2001 10:00 AM To: 'Ingraham, Andrew'; 'ibis@eda.org' Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Hi Andy: I agree that a testing a model with something other than a simple RC is necessary to test the goodness of a model. I wish more folks would validate their models with realistic transmission line type loads before releasing them. However, the purpose of the timing test load is not to test a buffers response in an environment with reflections, etc. -- it's to measure Tco. For that, the timing test load should be something that produces a clean, full-switching edge at the nominal impedance of the intended application. I think that is what Chris was getting at, and I tend to agree. Regards, Stephen Peters Intel Corp. -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Friday, May 11, 2001 9:06 AM To: 'ibis@eda.org' Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X > I don't think the IBIS specification should allow these test > loads. It is a mis-understanding of the purpose of these > test loads that results in these abuses. IBIS should lead > by explaining to the community the real purpose of test > loads and why it is important. I haven't been paying full attention lately (too much stuff going on!), but thought I'd chime in at this point. In digital logic, most real loads look like unterminated transmission lines, with some capacitance sprinkled in. The old lumped C or R-C load right on the DUT pin is unrepresentative, and may be inadequate as a test load. That is, in fact, why PCI 2.1 (not PCI-X, by the way) changed from the ancient 50pF test load, to the two 25 ohm loads (for 3.3V PCI parts), each representing a pair of 50 ohm traces in parallel; one case with the lines previously in the low state, the other in the high state. This test load emulates infinitely-long transmission lines, which is somewhat unrealistic (but more representative than the lumped load). Not only that, but there are times when a few nanoseconds of transmission line, is a partciularly useful "test" load, such as when comparing simulations of an IBIS model to a SPICE model. And it's a good, quick way to visually see how a part behaves when its output "rattles around," quickly exercising how the output transistors both source and sink current (as the outputs go beyond the rails), as well as ESD clamping, reflection coefficient, die capacitance, and package impedance. You can reveal a lot about a part ... or its model ... in one quick test, which the old lumped R-C model can never show. Regards, Andy From owner-ibis Fri May 11 12:25:03 2001 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4BJP1T03796 for ; Fri, 11 May 2001 12:25:02 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 70648CEA; Fri, 11 May 2001 12:27:08 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 17396D9B for ; Fri, 11 May 2001 12:27:08 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 11 May 2001 15:24:12 -0400 Message-ID: From: "Ingraham, Andrew" To: "'ibis@eda.org'" Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X Date: Fri, 11 May 2001 15:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain I forgot to mention in my earlier reply: The AGP spec also uses a transmission line as its Data Sheet Test Load for measuring Tval (Tco) at 4x mode. (Section 4.2.3.3: "The timing margins for 4x mode are smaller and a simple capacitive load is not sufficient to accurately model the load on a buffer.") So even with BIRD71, IBIS would be unable to handle Intel's 1998 AGP spec. > I agree that a testing a model with something other than a simple RC > is > necessary to test the goodness of a model. I wish more folks would > validate > their models with realistic transmission line type loads before > releasing > them. However, the purpose of the timing test load is not to test a > buffers > response in an environment with reflections, etc. -- it's to measure > Tco. > For that, the timing test load should be something that produces a > clean, > full-switching edge at the nominal impedance of the intended > application. Agreed, you need clean edges. But I also assert that you ideally want the Data Sheet Test Load (for measuring Tco) to be reasonably similar to the actual in-use load. To the extent that the two are similar, you get better accuracy, when you come to using the Data Sheet delays. (I don't understand what you mean by "at the nominal impedance of the intended application." A 50 pF capacitor isn't anything like a 50 ohm board trace impedance, except at 63.7 MHz, and even then the magnitude of the reflection coefficient is unity.) What is Tco anyway? Some people interpret it as simply the delay to the output pin. So when they plunk the part down on their board, it is the delay they will get. They want to "add up the numbers" and get the total path delay. (This might have been the purpose of the P4 test load.) For this to work, you need the Test Load (for determining Tco) to be similar to the actual load, don't you? At one time, 50 pF was close enough to a typical load (given slow risetimes, a small fanout, and some inches of trace); now it may not be. Other people use Tco as the delay in the specific case with the Test Load attached, and run simulations with both the Test Load and the actual load and calculate their difference. IN THEORY, this should always give the correct results. However, the further the Test Load is from the actual load, the greater the simulation errors may be. Then there is the case of a Standard, such as PCI, which specifies acceptable Tco (Tval) ranges that a part is allowed to have, from any vendor and with any IC design or process. Now I'm not a chip designer so I am taking some liberties here. But I assume there are some combinations of IC characteristics (drive strengths, edge rates, etc.) that are good for driving a 50pF load but not a transmission line; and vice-versa. So you could take two different ICs, that have exactly the same measured Tco with the 50pF test load, and they would have distinctly different delays in your system! That's the kind of thing you can avoid with the right test load. With a 50pF Data Sheet Test Load, what pass as acceptable chips, may behave poorly (well, variably) in the real system, so you need margins to account for that. As speeds go up, you may not be able to afford those margins. You need to test the chips for how they will perform in the transmission line environment, and evaluate them for Pass/Fail based on their Tco with the transmission line load. Regards, Andy From owner-ibis Fri May 11 17:36:44 2001 Received: from ntmail.qlc.com (216-231-2-8.qlc.com [216.231.2.8]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4C0ahT04790 for ; Fri, 11 May 2001 17:36:44 -0700 (PDT) Received: by ntmail.qlc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 17:35:12 -0700 Message-ID: <6B36306AFC41D511BA5E0003470D72E4D60C68@ntmail.qlc.com> From: John Martin To: "'ibis@eda.org'" Subject: IBIS to HSpice Date: Fri, 11 May 2001 17:35:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Does anybody have a template for the Intusoft IBIS converter that will convert IBIS to HSpice? Also does anyone know of a company that sells a converter that will convert IBIS to an HSpice netlist? Thanks, John Martin QLogic Corporation From owner-ibis Mon May 14 05:32:03 2001 Received: from mtvwca1-smrly1.gtei.net (mtvwca1-smrly1.gtei.net [128.11.176.196]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4ECW0T15625 for ; Mon, 14 May 2001 05:32:02 -0700 (PDT) Received: from fairchild3-cp-fc.fairchildsemi.com (smtp2-fc.fairchildsemi.com [192.233.132.91]) by mtvwca1-smrly1.gtei.net (Postfix) with SMTP id 6013143E1 for ; Mon, 14 May 2001 12:24:14 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Mon May 14 08:22:56 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id IAA26124; Mon, 14 May 2001 08:23:28 -0400 Subject: IBIS to HSPICE To: "'ibis@eda.org'" From: Adam.Tambone@fairchildsemi.com Date: Mon, 14 May 2001 08:23:28 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 05/14/2001 08:23:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii John, I have written my own IBIS to HSPICE translator but one needs Mathematica to do the translation. I saw a commercial version available and it can be found through the URL below. http://www.eigroup.org/ibis/ibis.htm Adam Tambone From owner-ibis Tue May 15 16:46:29 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4FNkQT25457 for ; Tue, 15 May 2001 16:46:28 -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 TAA29811 for ; Tue, 15 May 2001 19:45:38 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id TAA19525 for ; Tue, 15 May 2001 19:45:35 -0400 (EDT) Received: from innoveda.com ([139.181.6.206]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with ESMTP id QAA10946 for ; Tue, 15 May 2001 16:45:14 -0700 (PDT) Message-ID: <3B01BF45.49FC37E9@innoveda.com> Date: Tue, 15 May 2001 16:44:05 -0700 From: Guy de Burgh Organization: Innoveda X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS minutes Content-Type: multipart/mixed; boundary="------------3E75DBEE3D9398C057623954" This is a multi-part message in MIME format. --------------3E75DBEE3D9398C057623954 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------3E75DBEE3D9398C057623954 Content-Type: text/plain; charset=us-ascii; name="m051101.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="m051101.txt" DATE: 5/15/01 SUBJECT: 5/11/01 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal* Agilent (Mark Chang) Ansoft Corporation (Eric Bracken) Apple Computer John Figueroa Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Brocade Communications Robert Badal Cadence Design [Ian Dodd], Patrick Dos Santos, Heiko Dudek Lynne Green*, Lance Wang* Cisco Systems Syed Huq, Lungfu Chen Compaq Peter LaFlamme, Ron Bellomio, Quang Dam, Bill Ham Cypress (Rajesh Manapat) EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone* IBM Michael Cohen, Greg Edlund*, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel Innoveda (& HyperLynx) Guy de Burgh*, John Angulo*, Cary Mandel, Matthew Flora Intel Corporation Stephen Peters*, Arpad Muranyi*, Dave Lorang, Michael Mirmak*, Qinglun Chen, Will Hobbs LSI Logic Larry Barnes* Mentor Graphics Bob Ross, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad, Mohammed Korany, Weston Beal, Chris Swaim, Ali Samii, Eric Ronger, Karine Loudet Micron Technology Randy Wolff*, Yong Phan* Mitsubishi (Tam (Tom) Cao) Molex Incorporated Gus Panella, Brian O'Malley Motorola (Ron Werner) National Semiconductor Milt Schwartz* Nortel Networks Calvin Trowell North East Systems Associates Edward Sayre Philips Semiconductor Zack Ciccone, Rob Mataheroe Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens (& Automotive) AG Bernhard Unger, Helmut Katzier, Katja Koller, Wolfram Meyer, Eckhard Lenski, Gerald Bannert, Burkhard Muller, Christian Marot, Manfred Maurer, Amir Motamedi, Hans Pichlmaier Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz SiQual Scott McMorrow, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar, Jean Claude Perrin Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) John Berrie OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith ASIS Ltd David Wright BMW Friedrich Hasinger Cereva Networks Bob Haller EADS Airbus Industry Claude Huet (Aerospatiale) EFM Ekkehard Miersch, Horle Raines EIA Cecilia Fleming* FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fraunhofer Institute Mariusz Faferko, Peter Kralicek Reliability and Integration Fujitsu Ltd Tadashi Arai, Takeshi Murakami Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt Huawei Technologies Rachild Chen Hyundai Electronics Jongho Kang Infineon Technologies Christian Sporrer Intrinsix Corporation Steven Chin National Institute of Applied Etienne Sicard Science (INSA) Nokia Tapani von Ravner, Mika Castren, Janne Uusitalo Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Sintecs Hans Klos STMicroelectronics Peter Hirt, Fabrice Boissieres Sun Adrian Udenze Xilinx Susan Wu Independent, Consultant Al Davis In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode June 1 (916) 356-2663 2 6352088 Thursday June 21, 2001 IBIS Summit Meeting, No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum, and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Lance Wang of Cadence joined the meeting for the first time. Lance is a software developer, and is attending in order to learn more about IBIS models. Stephen Peters stated that the budget has been set for this year. The details are in the minutes from the last meeting. Cecilia Fleming stated that we have 27 out of 34 paid members, and that she and Bob will go after the remaining 7. REVIEW OF MINUTES AND AR'S The April 20, 2001 IBIS Minutes were approved without change. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Larry Barnes mentioned that the Fiber Channel group under Insights is also going to be coming up with a modeling document. Lynne Green wanted to know who to contact. Larry said that when he's done with his report he will talk to Stephen Peters about contact information. PRESS AND WEB PAGE UPDATES Stephen Peters reported that Syed Huq updated the Roster link on the IBIS Home page with some changes and also made some other minor corrections in the Upcoming Events link. NEW MODELS AVAILABLE, LIBRARY UPDATE Roy Leventhal announced that the IBIS Models page has been updated on May 3, 2001. He also mentioned that he has been receiving requests for models. Stephen Peters stated that the purpose of the models page is to provide a link to known IBIS models, not a place where models can be requested. OPENS FOR NEW ISSUES None INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Cecilia reported that the document is being published now. This is available on the http://www.iec.ch web site. Search by committee for TC93 and you can see the program's work. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal (formerly, IEC 93/67/NP IBIS and EMC Simulation) - Stephen Peters reported that he, Bob Ross, Jean Claude Perrin and Etienne Sicard have been in contact. There is a draft document out. Etienne Sicard is hoping to present this at the DAC IBIS Summit meeting. After DAC the group will get together to with the EMC group to draft a standard that is more consistent with the IBIS format. Stephen stated that there is a subdirectory for EMC data on: http://www.eda.org/pub/ibis/emc/ - JEDEC JC-16 - Modeling and Testing - No report. - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the National Committee for Information Technology (NCITS)) - Larry Barnes reported that the model specification for the SCSI model is planned for completion around the DAC timeframe. It will then be passed to the T10 committee for letter ballot. Larry anticipates that the ballot will be going out in August. A proposal for a follow on project to turn the technical report into a standard was forwarded to the T10 meeting last week. It was approved unanimously. Larry reported that the IBIS connector specification will be used in that standard. Larry also reported on T11. T11 is responsible for Fiber Channel. A group has been formed and meetings have started. The plan is to take the T10 document and modify it for use in Fiber Channel. The intention is to release it by Jan 02, 2002. Details of T10 and can be found on the www.t10.org web site. Go to Draft standards and technical reports. Larry is the technical editor for the T10 document and is likely to be the same for T11. Chris Reid published to the IBIS reflector a paper on reduced strength drivers and driver schedule. The intent was to issue a BIRD to clarify some language. Larry and Bob Ross need to clarify the implementation to remove an invalid condition. DESIGN AUTOMATION CONFERENCE 2001 IBIS SUMMIT MEETING PLANS Stephen Peters gave the general plans for the next IBIS Summit Meeting. The annual meeting is conducted along with the Design Automation Conference (DAC), held this year in Las Vegas, Nevada. The IBIS Summit Meeting will be in the Hilton Hotel adjacent to the Las Vegas Convention Center. The meeting date is Thursday, June 21, 2001, the day following the trade show portion of DAC. This meeting is sponsored by the IBIS Open Forum through the dues. Guy de Burgh will coordinate the signups, presentations and other local logistics. EIA and Cecilia Fleming will help with the meeting site and luncheon logistics. Guy de Burgh sent out the first notice and will send out a second notice today on May 11, 2001. Tentative Program under Development: Administrative Issues - Election of IBIS Officers for 2001 - 2002 Connector Specification Discussion IBIS-X Discussion IBIS Version 4.0 Issues Enhanced Buffer Extraction - Hazem Hegazy, Mentor Graphics Driver Schedule Modeling - Chris Reid, Mentor Graphics Behavioral Frequency Domain Modeling - Arpad Muranyi, Intel Corp. Larry Barnes may give a short presentation on T10 and Fiber Channel. IBIS MODEL REVIEW COMMITTEE DISCUSSION No report. CONNECTOR PROPOSAL REVIEW Stephen Peters reported that the last meeting held May 1, 2001. The next meeting is scheduled on May 15, 2001. The main focus has been to get the wording and key words consistent with IBIS-X. The latest specification is on the IBIS web site. A question came up about BGA package pin coupling. Stephen replied that the Connector Specification doesn't lend itself to this as it assumes a regular geometry which BGA doesn't have. This will probably be addressed in IBIS-X. The plan is to present a cleaned up specification at the DAC summit meeting. Roy Leventhal asked if, after the Connector Specification was finalized, whether this would then be a good point to readdress the package modeling issue. Stephen responded that he thought that it would be a reasonable point, but it would come after the IBIS-X macro language was documented. IBIS FUTURES (IBIS-X, API, BIRDxx) Meeting held May 1, 2001. The next meeting is scheduled on May 15, 2001 New version has been published. It should be on the web page next week. This is a draft version. The major changes are corrections and the addition of the tree diagram. Stephen Peters welcomes anyone who would like to contribute to the discussion and the specification. The next item is to make the Macro language presentable. Some revisions have been done for clarity. BIRD70.3 - GOLDEN WAVEFORMS Greg Edlund reported on changes leading to BIRD70.3 which was released a week ago. The major change between BIRD70.2 and BIRD70.3 was to remove timing parameters that were considered extra complexity. The only remaining question is regarding 2 sub parameters that are IBIS-X related. Bob Ross has some concerns covering all possible combinations of drivers and receivers. Stephen mentioned that this is likely to be ready for a vote at the meeting after next. BIRD71 - TIMING TEST LOADS IN [Model Spec] TO SUPPORT PCI & PCI-X Stephen Peters outlined the goal of this bird, and the differences between this and BIRD 70.3. Arpad Muranyi wondered if this BIRD should cover more, and different, types of test loads other than PCI and PCI-X. Stephen's opinion on this was to just expand the [Model Spec] parameters to their logical conclusion, but not attempt to change the IBIS specification. Stephen will discuss with Bob Ross whether a more general BIRD is required, but was concerned about whether there would be enough time to get it into IBIS Version 4.0. IBISCHK3 BUG TRACKING (Other Pending BIRDs were moved to the end) - BUG56 Parser Fails to Detect Always Flowing Current Revision - specified fix. Resolution - to fix. Matt Flora discussed the bug with Bob Ross. Bob proposed extending this to include all I-V tables not just the Clamp tables. The tables should approach 0, but do not have to cross 0. Bob proposed that a Warning should be issued if the current in an I-V table did not cross zero or did not approach zero to within some reasonably low (noise) value. The Proposal is to issue a warning, not an error, and extend the test to check the [Pullup] and [Pulldown] as well as the [Gnd Clamp] and [Power Clamp] tables. Some explanation and description of the warning will be added. OTHER PENDING BIRDS (moved to the end) None. MISC. Roy Leventhal asked for the location of the EMC documents. They can be found under: http://www.eda.org/pub/ibis/emc/ NEXT MEETING: The next teleconference meeting will be on Friday, June 1, 2001, from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 stephen.peters@intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== --------------3E75DBEE3D9398C057623954-- From owner-ibis Wed May 16 06:40:40 2001 Received: from grieg.transfer.nl (mail.transfer.nl [195.193.231.177]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4GDebT29294 for ; Wed, 16 May 2001 06:40:39 -0700 (PDT) Received: from portis (portis.a1.transfer.nl [10.1.2.153]) by grieg.transfer.nl (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA14582 for ; Wed, 16 May 2001 15:39:44 +0200 X-Authentication-Warning: grieg.transfer.nl: Host portis.a1.transfer.nl [10.1.2.153] claimed to be portis From: "Wilco Hamhuis" To: "Ibis" Subject: another C_comp confusion question Date: Wed, 16 May 2001 15:39:36 +0200 Message-ID: <000301c0de0d$a61c0850$9902010a@a1.transfer.nl> 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Hi all, Betty Luk initiated this topic a few months ago. Recently I received a differential IBIS model from a vendor. I noticed that the C_comp value was very small, 162fF. Apparently the C_comp value is also included in the VT tables. In my case I don't have the VT tables. The driver model only consists out of the pullup and down curves. Gnd, power, rise and fall aren't present (ramp data is present). When I use this model in a XTK simulation I see very large oscillation, straight through the logic threshold levels. Increasing the C_comp value a bit and the results become significant better. I find it VERY disturbing that C_comp has such a large impact on the simulation results. My questions: - is 162fF a realistic C_comp value according to your experience? - does anyone have any experience with questionable simulation results due to C_comp value? - what is the relationship between the VT tables and C_comp? Tanks in advance, Wilco Signal Integrity Expert From owner-ibis Wed May 16 07:50:25 2001 Received: from mail-wst.wedc-wst ([209.211.171.226]) by server.eda.org (8.11.0/8.11.0) with SMTP id f4GEoNT29941 for ; Wed, 16 May 2001 07:50:24 -0700 (PDT) Received: by MAIL-WST with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 10:50:47 -0400 Message-ID: From: Bob Khederian To: "'Wilco Hamhuis'" , Ibis Subject: RE: another C_comp confusion question Date: Wed, 16 May 2001 10:50:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi All, I have also had a problem with Ccomp, but the other extreme. I have seen Ccomp values of 5pF. Recall according to the IBIS spec, "Ccomp defines the silicon die capacitance". I find it difficult to beleive that the capacitance of a die (we deal with memory here) is 5pF. Has anyone had similar concerns? Has anyone addressed this with any of the silicon vendors? Bob. -----Original Message----- From: Wilco Hamhuis [mailto:w.hamhuis@transfer.nl] Sent: Wednesday, May 16, 2001 9:40 AM To: Ibis Subject: another C_comp confusion question Hi all, Betty Luk initiated this topic a few months ago. Recently I received a differential IBIS model from a vendor. I noticed that the C_comp value was very small, 162fF. Apparently the C_comp value is also included in the VT tables. In my case I don't have the VT tables. The driver model only consists out of the pullup and down curves. Gnd, power, rise and fall aren't present (ramp data is present). When I use this model in a XTK simulation I see very large oscillation, straight through the logic threshold levels. Increasing the C_comp value a bit and the results become significant better. I find it VERY disturbing that C_comp has such a large impact on the simulation results. My questions: - is 162fF a realistic C_comp value according to your experience? - does anyone have any experience with questionable simulation results due to C_comp value? - what is the relationship between the VT tables and C_comp? Tanks in advance, Wilco Signal Integrity Expert From owner-ibis Wed May 16 11:55:08 2001 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4GIt4T00986 for ; Wed, 16 May 2001 11:55:08 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.8.8/8.6.11) id LAA03903 for ; Wed, 16 May 2001 11:54:22 -0700 (PDT) Received: from scnt-wsec2.nsc.com(139.187.1.17) by natsemi-bh.nsc.com via smap (4.1) id xma001024; Wed, 16 May 01 11:48:38 -0700 Received: from 139.187.179.130 by MMS2 with ESMTP (- Hi - (MMS v4.7)); Wed, 16 May 2001 11:48:42 -0700 X-Server-Uuid: 305674a2-aa00-11d4-b160-00d0b746c3d9 Received: from galaxy.nsc.com by scmh1.nsc.com with ESMTP for ibis@eda.org; Wed, 16 May 2001 11:48:38 -0700 Received: from xi.nsc.com (xi.nsc.com [139.187.209.24]) by galaxy.nsc.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12604 for ; Wed, 16 May 2001 11:48:37 -0700 (PDT) Received: (from schwartz@localhost) by xi.nsc.com (8.8.8+Sun/8.8.8) id LAA00652 for ibis@eda.org; Wed, 16 May 2001 11:48:37 -0700 (PDT) Date: Wed, 16 May 2001 11:48:37 -0700 (PDT) From: "Milt Schwartz x3261" Message-ID: <200105161848.LAA00652@xi.nsc.com> To: ibis@eda.org Subject: RE: another C_comp confusion question X-Sun-Charset: US-ASCII MIME-Version: 1.0 X-WSS-ID: 171C14D536131-12-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Our C_comp measurements at National Semiconductor Interface Group. Based on bench TDR, subtracting out the package parameter which we get in a matrix from our packaging group. LVDS differential driver outputs; range is 3.15pF to 5.3pF depending on how "strong" the driver output is and the type of ESD protection circuitry. Receiver outputs, are full CMOS swing: Range from 5pF to 7pF, again depending on how "strong" the output is and the type of ESD protection. These are all CMOS process, typically 0.35 micrometer. regards, milt schwartz Interface Applications > From owner-ibis@server.eda.org Wed May 16 08:36:48 2001 > From: Bob Khederian > To: "'Wilco Hamhuis'" , Ibis > Subject: RE: another C_comp confusion question > Date: Wed, 16 May 2001 10:50:46 -0400 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Sender: owner-ibis@server.eda.org > > Hi All, > > I have also had a problem with Ccomp, but the other extreme. I have seen > Ccomp values of 5pF. Recall according to the IBIS spec, "Ccomp defines the > silicon die capacitance". I find it difficult to beleive that the > capacitance of a die (we deal with memory here) is 5pF. Has anyone had > similar concerns? Has anyone addressed this with any of the silicon > vendors? > > Bob. > > -----Original Message----- > From: Wilco Hamhuis [mailto:w.hamhuis@transfer.nl] > Sent: Wednesday, May 16, 2001 9:40 AM > To: Ibis > Subject: another C_comp confusion question > > > Hi all, > > Betty Luk initiated this topic a few months ago. Recently I received a > differential IBIS model from a vendor. I noticed that the C_comp value was > very small, 162fF. Apparently the C_comp value is also included in the VT > tables. In my case I don't have the VT tables. The driver model only > consists out of the pullup and down curves. Gnd, power, rise and fall aren't > present (ramp data is present). When I use this model in a XTK simulation I > see very large oscillation, straight through the logic threshold levels. > Increasing the C_comp value a bit and the results become significant better. > I find it VERY disturbing that C_comp has such a large impact on the > simulation results. My questions: > > - is 162fF a realistic C_comp value according to your experience? > - does anyone have any experience with questionable simulation results due > to C_comp value? > - what is the relationship between the VT tables and C_comp? > > Tanks in advance, > > Wilco > Signal Integrity Expert > From owner-ibis Wed May 16 12:05:53 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f4GJ5lT01057 for ; Wed, 16 May 2001 12:05:52 -0700 (PDT) Received: from svr-orw-exc-04.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA02025; Wed, 16 May 2001 12:03:47 -0700 (PDT) Received: by svr-orw-exc-04.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 12:03:53 -0700 Message-ID: From: "Dagostino, Tom" To: "'Milt Schwartz x3261'" , ibis@eda.org Subject: RE: another C_comp confusion question Date: Wed, 16 May 2001 12:03:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE3A.F05537C0" 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_01C0DE3A.F05537C0 Content-Type: text/plain The smallest specified C_comp I've seen is around 700fF. The largest spec'ed beleive it or not was around 35 pF. Most of what I have seen falls in the range Milt points out. Remember, the data from a datasheet usually has some pad in it. -----Original Message----- From: Milt Schwartz x3261 [mailto:schwartz@galaxy.nsc.com] Sent: Wednesday, May 16, 2001 11:49 AM To: ibis@eda.org Subject: RE: another C_comp confusion question Our C_comp measurements at National Semiconductor Interface Group. Based on bench TDR, subtracting out the package parameter which we get in a matrix from our packaging group. LVDS differential driver outputs; range is 3.15pF to 5.3pF depending on how "strong" the driver output is and the type of ESD protection circuitry. Receiver outputs, are full CMOS swing: Range from 5pF to 7pF, again depending on how "strong" the output is and the type of ESD protection. These are all CMOS process, typically 0.35 micrometer. regards, milt schwartz Interface Applications > From owner-ibis@server.eda.org Wed May 16 08:36:48 2001 > From: Bob Khederian > To: "'Wilco Hamhuis'" , Ibis > Subject: RE: another C_comp confusion question > Date: Wed, 16 May 2001 10:50:46 -0400 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Sender: owner-ibis@server.eda.org > > Hi All, > > I have also had a problem with Ccomp, but the other extreme. I have seen > Ccomp values of 5pF. Recall according to the IBIS spec, "Ccomp defines the > silicon die capacitance". I find it difficult to beleive that the > capacitance of a die (we deal with memory here) is 5pF. Has anyone had > similar concerns? Has anyone addressed this with any of the silicon > vendors? > > Bob. > > -----Original Message----- > From: Wilco Hamhuis [mailto:w.hamhuis@transfer.nl] > Sent: Wednesday, May 16, 2001 9:40 AM > To: Ibis > Subject: another C_comp confusion question > > > Hi all, > > Betty Luk initiated this topic a few months ago. Recently I received a > differential IBIS model from a vendor. I noticed that the C_comp value was > very small, 162fF. Apparently the C_comp value is also included in the VT > tables. In my case I don't have the VT tables. The driver model only > consists out of the pullup and down curves. Gnd, power, rise and fall aren't > present (ramp data is present). When I use this model in a XTK simulation I > see very large oscillation, straight through the logic threshold levels. > Increasing the C_comp value a bit and the results become significant better. > I find it VERY disturbing that C_comp has such a large impact on the > simulation results. My questions: > > - is 162fF a realistic C_comp value according to your experience? > - does anyone have any experience with questionable simulation results due > to C_comp value? > - what is the relationship between the VT tables and C_comp? > > Tanks in advance, > > Wilco > Signal Integrity Expert > ------_=_NextPart_001_01C0DE3A.F05537C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: another C_comp confusion question

The smallest specified C_comp I've seen is around = 700fF.  The largest spec'ed beleive it or not was around 35 = pF.  Most of what I have seen falls in the range Milt points = out.  Remember, the data from a datasheet usually has some pad in = it.

-----Original Message-----
From: Milt Schwartz x3261 [mailto:schwartz@galaxy.nsc.com]
Sent: Wednesday, May 16, 2001 11:49 AM
To: ibis@eda.org
Subject: RE: another C_comp confusion = question


Our C_comp measurements at National Semiconductor = Interface Group.
Based on bench TDR, subtracting out the package = parameter which we get in a matrix from our packaging group.


LVDS differential driver outputs; range is 3.15pF to = 5.3pF depending on how "strong" the driver output is and the = type of ESD protection circuitry.

Receiver outputs, are full CMOS swing: Range from 5pF = to 7pF, again depending on how "strong" the output is and the = type of ESD protection.

These are all CMOS process, typically 0.35 = micrometer.

regards, milt schwartz
Interface Applications


> From owner-ibis@server.eda.org Wed May 16 = 08:36:48 2001
> From: Bob Khederian = <RKhederian@whiteedc.com>
> To: "'Wilco Hamhuis'" = <w.hamhuis@transfer.nl>, Ibis <ibis@eda.org>
> Subject: RE: another C_comp confusion = question
> Date: Wed, 16 May 2001 10:50:46 -0400
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service = (5.5.2653.19)
> Sender: owner-ibis@server.eda.org
>
> Hi All,
>
> I have also had a problem with Ccomp, but the = other extreme.  I have seen
> Ccomp values of 5pF.  Recall according to = the IBIS spec, "Ccomp defines the
> silicon die capacitance".  I find it = difficult to beleive that the
> capacitance of a die (we deal with memory here) = is 5pF.  Has anyone had
> similar concerns?  Has anyone addressed = this with any of the silicon
> vendors? 
>
> Bob.
>
> -----Original Message-----
> From: Wilco Hamhuis [mailto:w.hamhuis@transfer.nl]<= /FONT>
> Sent: Wednesday, May 16, 2001 9:40 AM
> To: Ibis
> Subject: another C_comp confusion = question
>
>
> Hi all,
>
> Betty Luk initiated this topic a few months = ago. Recently I received a
> differential IBIS model from a vendor. I = noticed that the C_comp value was
> very small, 162fF. Apparently the C_comp value = is also included in the VT
> tables. In my case I don't have the VT tables. = The driver model only
> consists out of the pullup and down curves. = Gnd, power, rise and fall aren't
> present (ramp data is present). When I use this = model in a XTK simulation I
> see very large oscillation, straight through = the logic threshold levels.
> Increasing the C_comp value a bit and the = results become significant better.
> I find it VERY disturbing that C_comp has such = a large impact on the
> simulation results. My questions:
>
>  - is 162fF a realistic C_comp value = according to your experience?
>  - does anyone have any experience with = questionable simulation results due
> to C_comp value?
>  - what is the relationship between the VT = tables and C_comp?
>
> Tanks in advance,
>
> Wilco
> Signal Integrity Expert
>

------_=_NextPart_001_01C0DE3A.F05537C0-- From owner-ibis Fri May 18 20:40:21 2001 Received: from hotmail.com (f103.law4.hotmail.com [216.33.149.103]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4J3eJZX026770 for ; Fri, 18 May 2001 20:40:20 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 May 2001 20:39:37 -0700 Received: from 63.57.229.6 by lw4fd.law4.hotmail.msn.com with HTTP; Sat, 19 May 2001 03:39:37 GMT X-Originating-IP: [63.57.229.6] From: "Jeff Mills" To: schwartz@galaxy.nsc.com Cc: ibis@eda.org Subject: Ccomp die is this static capacitance? Date: Sat, 19 May 2001 03:39:37 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 19 May 2001 03:39:37.0890 (UTC) FILETIME=[5441B020:01C0E015]

   What I would consider in modeling for Ccomp maybe differs from what is stated as being the Ibis spec for this. Through the transition region of switching, is my issue. In this portion where the signla is transitioning to another rail, the transistor FET AC model of C gs is what I want as a function of voltage. The idea here is that with the ringing of the package inductance I could have an issue depending on how I model the load, or even if I should put small compensation close to the output to get the best speed performance with the technology. Its hard to know if the Ccomp is underestimated in not giving this figure. I can see a low Ccomp when the active output ransisor is fully biased, but my rail margin makes this a bit moot. I could see two figures of characterisation of output capaictance to constrain the edsign at the chip end to the overall performance I would want as an integrator: one to measure the full on capacitnce to constrain to a good floor plan and another to characterise the transition AC performance to model better my source waveform and tLine and load. What more?

        Am I missing that there is something else in the package compensation to adress this?

Sounds like a circular argument between chip - tool - and board - think system view and make sure it considers the concern of the application and I would be completely happy that it s a real number.

Specs are no good if they are 1-not verfiable, 2 - not constraining the desing to adequate model and control electrical sytem design and PCBboard accomodations. Rest is easy.

Jeff Mills

Gecko Electronic Consulting of Contra Costa CA.

  ps take a nice bike ride, its very clarifying and weather has been great.

 


Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-ibis Thu May 24 06:17:51 2001 Received: from mtvwca1-smrly1.gtei.net (mtvwca1-smrly1.gtei.net [128.11.176.196]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4ODHdmf019938 for ; Thu, 24 May 2001 06:17:50 -0700 (PDT) Received: from fairchild3-cp-fc.fairchildsemi.com (smtp2-fc.fairchildsemi.com [192.233.132.91]) by mtvwca1-smrly1.gtei.net (Postfix) with SMTP id 6E6994232 for ; Thu, 24 May 2001 13:16:44 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Thu May 24 09:15:10 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id JAA22069; Thu, 24 May 2001 09:15:39 -0400 Subject: Re: Clarification needed. To: ibis@eda.org, ibis-users@eda.org From: Adam.Tambone@fairchildsemi.com Date: Thu, 24 May 2001 09:15:38 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 05/24/2001 09:15:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Anbazhagan, Sounds good to me... I haven't modeled a ASIC but you seem to be on the right track. Regarding point 3. I'm not sure how the output impedance of the I/O buffer can be included in a IBIS datasheet so this is probably not necessary. Others with more experience may correct me on this. Regarding point 5. the DC sweep for I/V data is -Vcc to 2Vcc, so in your case this seems to be -3.3V to 6.6V. Do not forget that Pullup data has a domain of Vtable=Vcc - Vin, where Vin is the DC voltage sweep. For a I/O buffer here are the parameters and data you will want to form a IBIS model, you have already described most of these: Polarity Vref, Rref, Cref Ccomp Temperature Range Voltage Range Pulldown Data Pullup Data Rising and Falling Waveforms across the Voltage Range, one set at 50 Ohms to gnd, another set at 50 Ohms to Vcc ( assuming the ASIC is CMOS ) Ramp Data additionally you will want the R L C packaging parameters either pin specific or general typ, min, max values you would also want the I/V curves for the Power and GND Clamps but you have stated that these do not exist Refer to the 3.2 spec for definitions and descriptions of the above data and parameters. One other point, when requesting this data be sure to mention you want no more than 100 points per data curve. Hope this is of some help. Adam Tambone Anbu@scmmicro.co.in on 05/24/2001 02:48:13 AM To: "ibis-users@eda.org":@server.eda.org cc: Subject: Clarification needed. Hello Users, I am using XTK to simulate a PCBA. The board has a 100pin ASIC. In order to model the ASIC properly I need the IBIS model of the ASIC which I can convert it to XTK format. Now if I directly request for an IBIS model the vendor may hesistate. So I am requesting the following data from the vendor with which I can create a IBIS model. Below is the data I am requesting them. Is it OK. Does it cover everything necessary to create a proper IBIS model?. The ASIC does not have any clamp diodes. Please reply. The following data whichever is applicable for each pin of the ASIC are needed 1. Package parasitics namely, the Resistance, capacitance and Inductance. Typical, max, min values required. 2. Die capacitance as seen at the die pad. Typical, max, min values required 3. Output impedance of the I/O buffers. Typical, max, min values required. 4. Rise time and fall time values (dv/dt typical, max, min) of buffers excluding the effect of packaging but including the effect of die capacitance. Load conditions required. 6. Rising edge and falling edge waveforms (Voltage vs. time curve with the voltage values having typical, max, min values) of the driver along with the test conditions. 5. V/I characteristics of Pull up and Pull down resistor, if present, when the buffer is driven high and low respectively. The voltage sweep must be from ?3.3V to +6.6V. Current measurement with typical, max, min values are required. Thanks, Anbazhagan. From owner-ibis Thu May 24 06:26:21 2001 Received: from cambridge1-smrly1.gtei.net (cambridge1-smrly1.gtei.net [199.94.215.242]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4ODQImf019960 for ; Thu, 24 May 2001 06:26:20 -0700 (PDT) Received: from fairchild-cp-fc.fairchildsemi.com (smtp1-fc.fairchildsemi.com [192.233.132.90]) by cambridge1-smrly1.gtei.net (Postfix) with SMTP id 1DDF54A49 for ; Thu, 24 May 2001 13:25:34 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Thu May 24 09:24:11 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id JAA22935; Thu, 24 May 2001 09:24:40 -0400 Subject: Re: Clarification needed. To: ibis@eda.org, ibis-users@eda.org From: Adam.Tambone@fairchildsemi.com Date: Thu, 24 May 2001 09:24:39 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 05/24/2001 09:24:40 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Anbazhagan, oops... forgot to mention that you also want Vmeas. Adam From owner-ibis Thu May 24 06:29:33 2001 Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4ODTUmf019965; Thu, 24 May 2001 06:29:32 -0700 (PDT) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 May 2001 09:26:21 -0400 Message-ID: From: "ruston, matt" To: "'Adam.Tambone@fairchildsemi.com'" , ibis@eda.org, ibis-users@eda.org Subject: RE: Clarification needed. Date: Thu, 24 May 2001 09:26:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Adam, Anbazhagan: Hi. The output impedance of an I/O buffer is contained directly in the I/V curves of the pullup and pulldown. Add to this the package parasitics and you should have the impedance of the I/O buffer looking back through the package. Regards, Matt -----Original Message----- From: Adam.Tambone@fairchildsemi.com [mailto:Adam.Tambone@fairchildsemi.com] Sent: Thursday, May 24, 2001 9:16 AM To: ibis@eda.org; ibis-users@eda.org Subject: Re: Clarification needed. Anbazhagan, Sounds good to me... I haven't modeled a ASIC but you seem to be on the right track. Regarding point 3. I'm not sure how the output impedance of the I/O buffer can be included in a IBIS datasheet so this is probably not necessary. Others with more experience may correct me on this. Regarding point 5. the DC sweep for I/V data is -Vcc to 2Vcc, so in your case this seems to be -3.3V to 6.6V. Do not forget that Pullup data has a domain of Vtable=Vcc - Vin, where Vin is the DC voltage sweep. For a I/O buffer here are the parameters and data you will want to form a IBIS model, you have already described most of these: Polarity Vref, Rref, Cref Ccomp Temperature Range Voltage Range Pulldown Data Pullup Data Rising and Falling Waveforms across the Voltage Range, one set at 50 Ohms to gnd, another set at 50 Ohms to Vcc ( assuming the ASIC is CMOS ) Ramp Data additionally you will want the R L C packaging parameters either pin specific or general typ, min, max values you would also want the I/V curves for the Power and GND Clamps but you have stated that these do not exist Refer to the 3.2 spec for definitions and descriptions of the above data and parameters. One other point, when requesting this data be sure to mention you want no more than 100 points per data curve. Hope this is of some help. Adam Tambone Anbu@scmmicro.co.in on 05/24/2001 02:48:13 AM To: "ibis-users@eda.org":@server.eda.org cc: Subject: Clarification needed. Hello Users, I am using XTK to simulate a PCBA. The board has a 100pin ASIC. In order to model the ASIC properly I need the IBIS model of the ASIC which I can convert it to XTK format. Now if I directly request for an IBIS model the vendor may hesistate. So I am requesting the following data from the vendor with which I can create a IBIS model. Below is the data I am requesting them. Is it OK. Does it cover everything necessary to create a proper IBIS model?. The ASIC does not have any clamp diodes. Please reply. The following data whichever is applicable for each pin of the ASIC are needed 1. Package parasitics namely, the Resistance, capacitance and Inductance. Typical, max, min values required. 2. Die capacitance as seen at the die pad. Typical, max, min values required 3. Output impedance of the I/O buffers. Typical, max, min values required. 4. Rise time and fall time values (dv/dt typical, max, min) of buffers excluding the effect of packaging but including the effect of die capacitance. Load conditions required. 6. Rising edge and falling edge waveforms (Voltage vs. time curve with the voltage values having typical, max, min values) of the driver along with the test conditions. 5. V/I characteristics of Pull up and Pull down resistor, if present, when the buffer is driven high and low respectively. The voltage sweep must be from ?3.3V to +6.6V. Current measurement with typical, max, min values are required. Thanks, Anbazhagan. From owner-ibis Thu May 24 06:38:37 2001 Received: from paloalto-smrly2.gtei.net (paloalto-smrly2.gtei.net [131.119.246.6]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4ODcamf019988 for ; Thu, 24 May 2001 06:38:37 -0700 (PDT) Received: from fairchild-cp-fc.fairchildsemi.com (smtp1-fc.fairchildsemi.com [192.233.132.90]) by paloalto-smrly2.gtei.net (Postfix) with SMTP id 5241E4EDB for ; Thu, 24 May 2001 13:37:15 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Thu May 24 09:35:51 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id JAA24230; Thu, 24 May 2001 09:36:20 -0400 Subject: RE: Clarification needed. To: ibis@eda.org, ibis-users@eda.org From: Adam.Tambone@fairchildsemi.com Date: Thu, 24 May 2001 09:36:19 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 05/24/2001 09:36:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Matt, yes and thank you, in fact when I created a Mathematica based IBIS to HSPICE translator I modeled the pullup, pulldown, GND and Power clamp structures as voltage controlled resistors based on the I/V data. Adam "ruston, matt" on 05/24/2001 09:26:19 AM To: Adam Tambone/SouthPortland/Fairchild@Fairchild, ibis@eda.org, ibis-users@eda.org cc: Subject: RE: Clarification needed. Adam, Anbazhagan: Hi. The output impedance of an I/O buffer is contained directly in the I/V curves of the pullup and pulldown. Add to this the package parasitics and you should have the impedance of the I/O buffer looking back through the package. Regards, Matt -----Original Message----- From: Adam.Tambone@fairchildsemi.com [mailto:Adam.Tambone@fairchildsemi.com] Sent: Thursday, May 24, 2001 9:16 AM To: ibis@eda.org; ibis-users@eda.org Subject: Re: Clarification needed. Anbazhagan, Sounds good to me... I haven't modeled a ASIC but you seem to be on the right track. Regarding point 3. I'm not sure how the output impedance of the I/O buffer can be included in a IBIS datasheet so this is probably not necessary. Others with more experience may correct me on this. Regarding point 5. the DC sweep for I/V data is -Vcc to 2Vcc, so in your case this seems to be -3.3V to 6.6V. Do not forget that Pullup data has a domain of Vtable=Vcc - Vin, where Vin is the DC voltage sweep. For a I/O buffer here are the parameters and data you will want to form a IBIS model, you have already described most of these: Polarity Vref, Rref, Cref Ccomp Temperature Range Voltage Range Pulldown Data Pullup Data Rising and Falling Waveforms across the Voltage Range, one set at 50 Ohms to gnd, another set at 50 Ohms to Vcc ( assuming the ASIC is CMOS ) Ramp Data additionally you will want the R L C packaging parameters either pin specific or general typ, min, max values you would also want the I/V curves for the Power and GND Clamps but you have stated that these do not exist Refer to the 3.2 spec for definitions and descriptions of the above data and parameters. One other point, when requesting this data be sure to mention you want no more than 100 points per data curve. Hope this is of some help. Adam Tambone Anbu@scmmicro.co.in on 05/24/2001 02:48:13 AM To: "ibis-users@eda.org":@server.eda.org cc: Subject: Clarification needed. Hello Users, I am using XTK to simulate a PCBA. The board has a 100pin ASIC. In order to model the ASIC properly I need the IBIS model of the ASIC which I can convert it to XTK format. Now if I directly request for an IBIS model the vendor may hesistate. So I am requesting the following data from the vendor with which I can create a IBIS model. Below is the data I am requesting them. Is it OK. Does it cover everything necessary to create a proper IBIS model?. The ASIC does not have any clamp diodes. Please reply. The following data whichever is applicable for each pin of the ASIC are needed 1. Package parasitics namely, the Resistance, capacitance and Inductance. Typical, max, min values required. 2. Die capacitance as seen at the die pad. Typical, max, min values required 3. Output impedance of the I/O buffers. Typical, max, min values required. 4. Rise time and fall time values (dv/dt typical, max, min) of buffers excluding the effect of packaging but including the effect of die capacitance. Load conditions required. 6. Rising edge and falling edge waveforms (Voltage vs. time curve with the voltage values having typical, max, min values) of the driver along with the test conditions. 5. V/I characteristics of Pull up and Pull down resistor, if present, when the buffer is driven high and low respectively. The voltage sweep must be from ?3.3V to +6.6V. Current measurement with typical, max, min values are required. Thanks, Anbazhagan. From owner-ibis Thu May 24 07:28:05 2001 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4OES2mf020219; Thu, 24 May 2001 07:28:04 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OERHC06170; Thu, 24 May 2001 10:27:17 -0400 (EDT) Received: from alcmail.micro.lucent.com (h128-94-18-195.lucent.com [128.94.18.195]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4OERGG06126; Thu, 24 May 2001 10:27:17 -0400 (EDT) Received: from alcmail.micro.lucent.com by alcmail.micro.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA21652; Thu, 24 May 2001 10:27:15 -0400 (EDT) Message-ID: <3B0D1A43.F56EA1CA@alcmail.micro.lucent.com> Date: Thu, 24 May 2001 10:27:15 -0400 From: Phani Putrevu Organization: Lucent Technologies X-Mailer: Mozilla 4.76C-CCK-MCD EMS-1.5 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Adam.Tambone@fairchildsemi.com CC: ibis@eda.org, ibis-users@eda.org Subject: Required data in IBIS Models (was Re: Clarification needed.) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The IBIS spec states that the model subparameter Vmeas is optional. The ibis checker does not complain if this is not present. HSpice can read an IBIS file even if the Vmeas is not specified. But I believe some tools (ICX) require this parameter to be present. (I do not use IBIS models - I was only involved in developing the models.) Does it mean that the tool is not compliant. What additional information is derived from this parameter? Should a tool rely on this information to produce an output, or should it produce the 'approximate' output that the vendor specified in the IBIS model. regards, Phani Adam.Tambone@fairchildsemi.com wrote: > > Anbazhagan, > > oops... forgot to mention that you also want Vmeas. > > Adam From owner-ibis Thu May 24 07:56:24 2001 Received: from camcolo2-smrly1.gtei.net (camcolo2-smrly1.gtei.net [128.11.173.4]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4OEuMmf020316 for ; Thu, 24 May 2001 07:56:23 -0700 (PDT) Received: from fairchild3-cp-fc.fairchildsemi.com (smtp2-fc.fairchildsemi.com [192.233.132.91]) by camcolo2-smrly1.gtei.net (Postfix) with SMTP id 3CEA7489B for ; Thu, 24 May 2001 14:55:37 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Thu May 24 10:54:13 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id KAA02504; Thu, 24 May 2001 10:54:41 -0400 Subject: Re: Required data in IBIS Models (was Re: Clarification needed.) To: Phani Putrevu Cc: ibis@eda.org, ibis-users@eda.org From: Adam.Tambone@fairchildsemi.com Date: Thu, 24 May 2001 10:54:40 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 05/24/2001 10:54:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Phani, I am just beginning to use IBIS models in XTK, so I am not entirely aware of how the Vmeas parameter is used. I do know that it is used for timing analysis and that IBIS2XTK will complain if it is not there. I mentioned that he 'wanted' the parameter because I have received more than a few complaints from customers when I did not include it in a IBIS datasheet ( my apologies to anyone who has encountered this ). I have since reviewed all IBIS datasheets I have generated and revised them to include this parameter if it was not included originally. I would like to hear more about how this parameter is used. Adam Tambone Phani Putrevu on 05/24/2001 10:27:15 AM To: Adam Tambone/SouthPortland/Fairchild@Fairchild cc: ibis@eda.org, ibis-users@eda.org Subject: Required data in IBIS Models (was Re: Clarification needed.) The IBIS spec states that the model subparameter Vmeas is optional. The ibis checker does not complain if this is not present. HSpice can read an IBIS file even if the Vmeas is not specified. But I believe some tools (ICX) require this parameter to be present. (I do not use IBIS models - I was only involved in developing the models.) Does it mean that the tool is not compliant. What additional information is derived from this parameter? Should a tool rely on this information to produce an output, or should it produce the 'approximate' output that the vendor specified in the IBIS model. regards, Phani Adam.Tambone@fairchildsemi.com wrote: > > Anbazhagan, > > oops... forgot to mention that you also want Vmeas. > > Adam From owner-ibis Thu May 24 08:55:49 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4OFtkmf020740; Thu, 24 May 2001 08:55:48 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA16941; Thu, 24 May 2001 08:54:58 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 May 2001 08:55:18 -0700 Message-ID: <0EC6ED94FF36D511BCE900508BB83C1D4F6CFA@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'Adam.Tambone@fairchildsemi.com'" , Phani Putrevu Cc: ibis@eda.org, ibis-users@eda.org Subject: RE: Required data in IBIS Models (was Re: Clarification needed.) Date: Thu, 24 May 2001 08:55:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Adam, Yes, the ICX tool (and probably others) requires the Vmeas parameter and a timing test load. The reason is that timing cannot be computed without it. In short, device manufacturers report component delay as the time from when some input on the device switches to the time a corresponding output on the device reaches Vmeas when loaded with a specified circuit. SI tools like ICX will report the interconnect delay as the time an input on a net reaches the input logic thresholds minus the time the it would take the driver that is active to reach Vmeas into the standard load. Then the delay from the input of one device to the input of another can be computed as the sum of the component delay and the interconnect delay. The time-to-vmeas into a standard load drops out of the calculation. The reason for actually doing the simulation of time-to-vmeas instead of just publishing a number in the IBIS specification is to avoid systematic errors that may be caused by the details of how one simulator represents the driver versus another. Chris Reid -----Original Message----- From: Adam.Tambone@fairchildsemi.com [mailto:Adam.Tambone@fairchildsemi.com] Sent: Thursday, May 24, 2001 7:55 AM To: Phani Putrevu Cc: ibis@eda.org; ibis-users@eda.org Subject: Re: Required data in IBIS Models (was Re: Clarification needed.) Phani, I am just beginning to use IBIS models in XTK, so I am not entirely aware of how the Vmeas parameter is used. I do know that it is used for timing analysis and that IBIS2XTK will complain if it is not there. I mentioned that he 'wanted' the parameter because I have received more than a few complaints from customers when I did not include it in a IBIS datasheet ( my apologies to anyone who has encountered this ). I have since reviewed all IBIS datasheets I have generated and revised them to include this parameter if it was not included originally. I would like to hear more about how this parameter is used. Adam Tambone Phani Putrevu on 05/24/2001 10:27:15 AM To: Adam Tambone/SouthPortland/Fairchild@Fairchild cc: ibis@eda.org, ibis-users@eda.org Subject: Required data in IBIS Models (was Re: Clarification needed.) The IBIS spec states that the model subparameter Vmeas is optional. The ibis checker does not complain if this is not present. HSpice can read an IBIS file even if the Vmeas is not specified. But I believe some tools (ICX) require this parameter to be present. (I do not use IBIS models - I was only involved in developing the models.) Does it mean that the tool is not compliant. What additional information is derived from this parameter? Should a tool rely on this information to produce an output, or should it produce the 'approximate' output that the vendor specified in the IBIS model. regards, Phani Adam.Tambone@fairchildsemi.com wrote: > > Anbazhagan, > > oops... forgot to mention that you also want Vmeas. > > Adam From owner-ibis Thu May 24 09:09:07 2001 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4OG94mf020873; Thu, 24 May 2001 09:09:06 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 70A19F33; Thu, 24 May 2001 09:11:23 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id EA768DFB; Thu, 24 May 2001 09:11:22 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Thu, 24 May 2001 12:08:18 -0400 Message-ID: From: "Ingraham, Andrew" To: ibis@eda.org, ibis-users@eda.org Subject: RE: Required data in IBIS Models (was Re: Clarification needed.) Date: Thu, 24 May 2001 12:08:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain I believe Vmeas is used to determine whether the analog voltage at a device's pin, would be interpreted by that device as a logical High or Low. So its need would depend on how one uses the IBIS model, i.e., which tool. If the IBIS model is used only to generate simulated waveforms, then the parameter is irrelevant. If used directly for timing analysis, the parameter would be needed. HSPICE's IBIS implementation has a subcircuit with a binary output signal, whose value represents the logical level of the voltage on the pin. This makes it a bit easier for the user to check timing and other things. Presumably it needs Vmeas in order to generate that binary output voltage. Regards, Andy From owner-ibis Thu May 24 09:20:55 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4OGKrmf020989; Thu, 24 May 2001 09:20:54 -0700 (PDT) Received: from svr-orw-exc-04.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA19367; Thu, 24 May 2001 09:19:55 -0700 (PDT) Received: by svr-orw-exc-04.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 May 2001 09:20:05 -0700 Message-ID: From: "Dagostino, Tom" To: "'Adam.Tambone@fairchildsemi.com'" , Phani Putrevu Cc: ibis@eda.org, ibis-users@eda.org Subject: RE: Required data in IBIS Models (was Re: Clarification needed.) Date: Thu, 24 May 2001 09:20:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E46D.627C37D0" 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_01C0E46D.627C37D0 Content-Type: text/plain Vmeas is used by the simulator to determin the delay of the output stage driving the manufacturer's reference load to the measurement voltage (Vmeas). The prop delay of the part is specified into this load also. The simulator is trying to do a timing analysis, time of flight, which includes the time of the driver and the time of the trace on the board. This information is used when analyzing total delays so that overall system timing can be verified. Tom Dagostino Modeling Manager Mentor Graphics Corp. SAE tom_dagostino@mentor.com 503-685-1613 -----Original Message----- From: Adam.Tambone@fairchildsemi.com [mailto:Adam.Tambone@fairchildsemi.com] Sent: Thursday, May 24, 2001 7:55 AM To: Phani Putrevu Cc: ibis@eda.org; ibis-users@eda.org Subject: Re: Required data in IBIS Models (was Re: Clarification needed.) Phani, I am just beginning to use IBIS models in XTK, so I am not entirely aware of how the Vmeas parameter is used. I do know that it is used for timing analysis and that IBIS2XTK will complain if it is not there. I mentioned that he 'wanted' the parameter because I have received more than a few complaints from customers when I did not include it in a IBIS datasheet ( my apologies to anyone who has encountered this ). I have since reviewed all IBIS datasheets I have generated and revised them to include this parameter if it was not included originally. I would like to hear more about how this parameter is used. Adam Tambone Phani Putrevu on 05/24/2001 10:27:15 AM To: Adam Tambone/SouthPortland/Fairchild@Fairchild cc: ibis@eda.org, ibis-users@eda.org Subject: Required data in IBIS Models (was Re: Clarification needed.) The IBIS spec states that the model subparameter Vmeas is optional. The ibis checker does not complain if this is not present. HSpice can read an IBIS file even if the Vmeas is not specified. But I believe some tools (ICX) require this parameter to be present. (I do not use IBIS models - I was only involved in developing the models.) Does it mean that the tool is not compliant. What additional information is derived from this parameter? Should a tool rely on this information to produce an output, or should it produce the 'approximate' output that the vendor specified in the IBIS model. regards, Phani Adam.Tambone@fairchildsemi.com wrote: > > Anbazhagan, > > oops... forgot to mention that you also want Vmeas. > > Adam ------_=_NextPart_001_01C0E46D.627C37D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Required data in IBIS Models (was Re: Clarification = needed.)

Vmeas is used by the simulator to determin the delay = of the output stage driving the manufacturer's reference load to the = measurement voltage (Vmeas).  The prop delay of the part is = specified into this load also.  The simulator is trying to do a = timing analysis, time of flight, which includes the time of the driver = and the time of the trace on the board.  This information is used = when analyzing total delays so that overall system timing can be = verified.



Tom Dagostino
Modeling Manager
Mentor Graphics Corp.
SAE
tom_dagostino@mentor.com
503-685-1613


-----Original Message-----
From: Adam.Tambone@fairchildsemi.com
[mailto:Adam.Tambone@fairc= hildsemi.com]
Sent: Thursday, May 24, 2001 7:55 AM
To: Phani Putrevu
Cc: ibis@eda.org; ibis-users@eda.org
Subject: Re: Required data in IBIS Models (was Re: = Clarification
needed.)



Phani,  I am just beginning to use IBIS models = in XTK, so I am not entirely
aware of how the Vmeas parameter is used.  I do = know that it is used for
timing analysis and that IBIS2XTK will complain if = it is not there.  I
mentioned that he 'wanted' the parameter because I = have received more than
a few complaints from customers when I did not = include it in a IBIS
datasheet ( my apologies to anyone who has = encountered this ).  I have
since reviewed all IBIS datasheets I have generated = and revised them to
include this parameter if it was not included = originally.

I would like to hear more about how this parameter is = used.

Adam Tambone





Phani Putrevu <pputrevu@lucent.com> on = 05/24/2001 10:27:15 AM

To:   Adam = Tambone/SouthPortland/Fairchild@Fairchild
cc:   ibis@eda.org, = ibis-users@eda.org

Subject:  Required data in IBIS Models (was Re: = Clarification needed.)


The IBIS spec states that the model subparameter = Vmeas is optional. The
ibis
checker does not complain if this is not present. = HSpice can read an IBIS
file
even if the Vmeas is not specified. But I believe = some tools (ICX) require
this parameter to be present. (I do not use IBIS = models - I was only
involved
in developing the models.)

Does it mean that the tool is not compliant. What = additional information is
derived from this parameter? Should a tool rely on = this information to
produce
an output, or should it produce the 'approximate' = output that the vendor
specified in the IBIS model.

regards,
Phani

Adam.Tambone@fairchildsemi.com wrote:
>
> Anbazhagan,
>
> oops... forgot to mention that you also want = Vmeas.
>
> Adam



------_=_NextPart_001_01C0E46D.627C37D0-- From owner-ibis Fri May 25 11:59:32 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4PIxTCf026714 for ; Fri, 25 May 2001 11:59:31 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA22597; Fri, 25 May 2001 11:58:45 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.70.103]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L41QVL4P; Fri, 25 May 2001 11:59:06 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3B0EAB64.6878DF79@mentor.com> Date: Fri, 25 May 2001 11:58:44 -0700 From: Bob Ross X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Agenda 6/1/01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 6/1/01 Bridge Number Reservation # Passcode New Number --> (916) 356-2663 2 6352088 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Ross - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Ross - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes DAC 2001 IBIS Summit Meeting Planning de Burgh/Ross Future 2002 IBIS Meeting with JEDEC Ross IBIS Model Review Committee Angulo New Administrative Issues All 8:30 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella/Ross IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD70.3 - Golden Waveforms Edlund BIRD71 - Timing Test Loads in [Model Spec] to Support Peters PCI & PCI-X Other Pending BIRDS Ross ibischk3 Bug Tracking Ross - BUG56 - Parser Fails to Detect Always Flowing Current Flora What is the Check? New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Tue May 29 14:01:15 2001 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4TL19YH014512; Tue, 29 May 2001 14:01:13 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id VAA03957; Tue, 29 May 2001 21:00:19 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 29 May 2001 21:00:12 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 14:00:10 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A779F@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" , "'ibis-users@eda.org'" Subject: Draft IBIS-X spec now available Date: Tue, 29 May 2001 14:00:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Greetings: A draft version (ver. 0.5) of the top level IBIS-X specification is now available for public comment : http://www.eda.org/pub/ibis/futures/ IBIS-X is the next generation IBIS, intended to address the shortcomings of the current EIA/IBIS-656 specification (IBIS ver. 3.2). Specifically, IBIS-X introduces a 'macro language' (IBIS-ML) that allows the user to create new model prototype as well as nodal based package models. Please note that the above document contains the specification for the IBIS-X header, component and package sections and general mechanisms for defining new models and model types only. Two other documents are in the works -- a rewrite of the current IBIS 3.2 [Models] section into a library guide as well as a formal specification of the IBIS-ML macro language. The IBIS-ML specification will be available in time for the June IBIS Open Forum Summit at DAC (July 21st). Please address all questions, comments, suggestions, etc. to stephen.peters@intel.com (IBIS Futures committee chair). Regards, Stephen Peters Intel Corp. Vice-Chair, EIA/IBIS Open Forum