From bob@icx.com Mon Jan 31 22:57:07 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21830; Mon, 31 Jan 94 22:57:07 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA06819 for ; Tue, 1 Feb 94 00:48:42 -0500 Date: Mon, 31 Jan 94 21:19:21 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18904; Mon, 31 Jan 94 21:19:21 PST Message-Id: <9402010519.AA18904@icx.com> To: ibis@vhdl.org Subject: BIRD7.1 Hello IBIS members: Below is BIRD7.1 to reflect comments and email to date plus some compromise terminology. Revisions include: Complete set of "Open types" "Open_up" terminology introduced. "Open_down" terminology introduced to replace "Open_source". Inclusion of "_ECL" Types (different class of "open" devices). Notes section expansion to describe measurements. ANALYSIS PATH revision and expansion. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 7.1 ISSUE TITLE: Open Specification Completion REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 13 January 1994 DATE REVISED: 31 January 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model_type "Open_drain" provides insufficient coverage for "open" sided models. For completeness, additional "open" Model_types are need. Also, necessary ECL related Model_types are added for clarity and to avoid several tests required before processing the [Model]. Methods to produce [Ramp] data need to be expanded for "open" devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Under the keyword [Model], additional Model_type selections are added: Open_up, I/O_Open_up, 3-State_Open_up, Open_down, I/O_Open_down, 3-state_Open_down, Output_ECL, I/O_ECL, Input_ECL. The [Model] keyword specification in Version 1.1 is edited to show these Model_types. Changed text is separated by blank lines. NOTES ON DATA DERIVATION METHODS is revised to clarify the [Ramp] measurements for open models. The [Model] keyword is revised to the following: |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | Usage Rules: Each Input, Output, I/O, 3-state, Open_drain or Open_up, | I/O_Open_up, 3-state_Open_up, Open_down, I/O_Open_down, | 3-state_Open_down, Input_ECL, Output_ECL, and I/O_ECL model | must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names which use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Model_types with "Open_up" mean that the [Pullup] keyword is | not used and/or that I = 0mA for all voltages specified. | "Open_drain" means "Open_up" and is retained for IBIS Version | 1.X compatibility. Model_types with "Open_down" mean that the | [Pulldown] keyword is not used and/or that I = 0mA for all | voltages specified. Model_types with "_ECL" mean that the | model represents an ECL type logic which follows different | conventions for the [Pulldown] keyword. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, Open_up, I/O_Open_up, 3-state_Open_up, Open_down, I/O_open_down, 3-state_Open_down, Input_ECL, Output_ECL, I/O_ECL | List one only Polarity Non-Inverting, Inverting | List one only, -if any Enable Active-High, Active-Low | List one only, -if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired Vinl = 0.8V | input logic "low" DC voltage, -if any Vinh = 2.0V | input logic "high" DC voltage, -if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |============================================================================== Section 3) on NOTES ON DATA DERIVATION METHOD is revised as follows: 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1. Start with the silicon model, remove all packaging. 2. If: The Model_type is one of the following: Output, I/O, or 3-state (not Open or ECL types); Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. If: the Model_type is Output_ECL or I/O_ECL; Then: Attach a 50 ohm resistor to the termination voltage (Vterm = VCC - 2v). Use this load to derive both the rising and falling edges. If: The Model_type is either an Open_up type or Open_drain; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The Model_type is an Open_down type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 3. and 7.: **** Delete Items 3. and 7. **** 4. - 6.: **** Renumber these Items as 3. - 5. **** ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Open-drain is corrected to Open_drain as a Model_type selection and is kept for Version 1.1 compatibility. The terminology "Open_up" means open [Pullup] and "Open_down" means open [Pulldown]. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. The Model_types shown can be found in commercial components. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_up 3-state_Open_up I/O_Open_up | Open_drain no pulldown: | Open_down 3-state_Open_down I/O_Open_down no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. For the "Open" Model_types there exists several other naming methods based on comments received and some combinations I though of. BIRD7.1 is written in terms of (1). (1) Use "up" and "down". Retain Open_drain for Version 1.1 compatibility as a redundant Model_type. (6 new terms, 1 redundant term). no pullup: | Open_up 3-state_Open_up I/O_Open_up | Open_drain no pulldown: | Open_down 3-state_Open_down I/O_Open_down (2) Retain "Open_drain", but use "up" & "down" for generic names elsewhere. (5 new terms). no pullup: | Open_drain 3-state_Open_up I/O_Open_up no pulldown: | Open_down 3-state_Open_down I/O_Open_down (3) Use "drain", "collector", "emitter". "emitter is generic for CMOS logic & TTL no pulldown devices. (8 new terms). no pullup: | Open_drain 3-state_Open_drain I/O_Open_drain | Open_collector 3-state_Open_collector I/O_Open_collector no pulldown: | Open_emitter 3-state_Open_emitter I/O_Open_emitter (4) Use "drain" generically for "up", and "source" generically for "down" for TTL and CMOS logic. (Bird7.0 suggestion - 5 new terms) no pullup: | Open_drain 3-state_Open_drain I/O_Open_drain no pulldown: | Open_source 3-state_Open_source I/O_Open_source (5) Use "Open_drain" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (2 new terms) no pullup: | Open_drain 3-state_Open_drain I/O_Open_drain no pulldown: | Open_drain 3-state_Open_drain I/O_Open_drain (6) Retain "Open_drain, but use "Open" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (3 new terms) no pullup: | Open_drain 3-state_Open I/O_Open no pulldown: | Open 3-state_Open I/O_Open (7) Use "Open" generically to mean "Open". Retain "Open_drain" for Version 1.1 compatibility. Test for no pullup or no pulldown in [Model]. (3 new terms, 1 redundant term). no pullup: | Open 3-state_Open I/O_Open | Open_drain no pulldown: | Open 3-state_Open I/O_Open Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "Open_up" device. Omission of [Pulldown] could be interpreted as an "Open_down" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "Open". Zero valued [Pullup] data corresponds to Open_up types or Open_drain. Zero valued [Pulldown] data corresponds to Open_down types. Without the additional Model_types, the above two approaches plus the existence of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. One final consideration is that whoever generates the [Model], whether through simulation or measurement, must know beforehand the Model_type in order to generate the [Ramp] data according to the rules. Therefore it is reasonable to require that this information be included as part of a Version 2.0 specification. This avoids the inefficiency of forcing the simulator to perform many tests before processing the IBIS data. The simulator can then translate the data into its internal format and apply its own simulator- specific compaction schemes (the simulator does not have to provide all of the Model_types). With BIRD7.1, the IBIS Statement of Intent within the first paragraph is preserved: "the intention of this template is to specify a consistent format that can be parsed by software, allowing each simulation vendor to derive models compatible with their own product." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell initiated the issue in Email of October 1993 questioning whether we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the SN74ALS641 Open Collector Tranceiver as a specific example. Kellee Crisafulli in Email of July 1993 considered "open output devices (open-drain, open-collector, open-source)". Furthermore, he referred to "open collector npn" and "open collector pnp" devices. In the discussion, he proposed new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off time of high side driver) and dv/dt_f_off (turn off time of low side driver). Included it the discussion was the requirement that "If the pulldown table is missing then dV/dt_r_off is required" and "If the pullup table is missing then dV/dt_f_off is required". Kellee elaborated further on the measurement/extraction issues of the ramp values. BIRD7.1 now addresses the ramp specification. The modifications on Notes on Derivations Method by Kellee Crisafulli and Stephen Peters are added with changes for notation consistency. The usage of "Open_up" and "Open_down" is an adaptation of one of Arpad Muranyi's comments on BIRD7 suggesting "open pullup" and "open pulldown". ****************************************************************************** From 71436.1314@CompuServe.COM Mon Jan 31 23:49:09 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22222; Mon, 31 Jan 94 23:49:09 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id CAA21495; Tue, 1 Feb 1994 02:47:33 -0500 Date: 01 Feb 94 02:44:51 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: BIRD 7.1 Message-Id: <940201074451_71436.1314_HHB31-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx To: Bob Re: BIRD 7.1 Wow, you seem to have covered most of the possibilities with this bird. I think you deserve the big BIRD award. (another IBIS yoke) I am worried about using Open_up and Open_down. I believe there will be alot of confusion regarding the upper side being "open" as in missing. As opposed to this being an output with an open side, and the upper side is present. I had to think about this for a few seconds when it was first presented. I found I had to think about it for a few seconds again when I read BIRD 7.1. This is a clue to me that other's may find it difficult to use also. How about sticking with what the industry seemed to have started as you originally proposed? I therefore propose the following terms be used: Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_source, I/O_open_source, Open_sink, I/O_open_sink, Input_ECL, Output_ECL, I/O_ECL In this context Open_source -> the output has an open side and sources current Open_sink -> the output has an open side and sinks current Open_drain -> retained for backward compatibility I/O_open_drain -> added so people that see Open_drain aren't confused Also I don't understand what use 3-state_open_drain has. By definition an open drain device is 3-state when it is off (what am I missing). Great job as always Bob! From ccm!Will_Hobbs@intelhf.intel.com Tue Feb 1 10:35:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01673; Tue, 1 Feb 94 10:35:32 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRPuv-000MNsC; Tue, 1 Feb 94 10:33 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRPxp-0000bIC; Tue, 1 Feb 94 10:36 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 1 Feb 94 10:36:40 PST Date: Tue, 1 Feb 94 10:36:40 PST From: Will Hobbs Message-Id: <940201103640_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Bird #8, Monotonicity From: Kellee Crisafulli, HyperLynx Inc. To:fellow IBIS members At the last meeting it was brought up by Arpad at Intel that the monotonic specification of V/I data may not be clear enough in the present version of the specification. It would appear that we did not assign this a BIRD and never finished documenting it! I have started this BIRD by documenting what was decided at the 1993 summit meeting. ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 8 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: 29 January 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. I searched all the IBIS minutes and found the following two IBIS minutes relating to montonicity: ------------------------------------------------------------------------------ from meeting Nov 5, 1993 We engaged in a discussion on monotonic behavior. There are two aspects -to be dealt with. 1) How should we deal with output buffers that exhibit non-monotonic behavior (and in what situations does this occur) 2) Must data be entered in the IBIS file monotonically? 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ----------------------------------------------------------------------------- From the 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------ ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:' and continue for 4 lines. Note: An '*' is used to denote the changed lines) |==============================================================================| | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | | Required: Yes, if they exist in the device | | Description: The data points under these keywords define the V/I curves -of | | the pulldown and pullup structures of an output buffer -and the| | V/I curves of the clamping diodes connected to the GND -and the| | POWER pins, respectively. | | Usage Rules: In each of these sections the first column contains the | | voltage value, and the three remaining columns hold the | | typical, minimum, and maximum current values. The four | | entries, Voltage, I(typ), I(min), and I(max) must be placed on | | a single line and must be separated by at least one white | | space or tab character. | | All four columns are required under these keywords, however | | data is only required in the typical column. If minimum | | and/or maximum current values are not available, the reserved | | word "NA" must be used. "NA" can be used for currents in the | | typical column, but numeric values MUST be specified for the | | first and last voltage points on any V/I curve. Each V/I | | curve must have at least 2, but not more than 100, voltage | | points. | * At least one axis of the data (voltage or current) is -required| * to be monotonic. For example if the voltage is monotonic and | * increasing, each seqential voltage point must be larger than | * the previous value. | | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | | [POWER_clamp] structures are 'Vcc relative', meaning that the | | voltage values are referenced to the Vcc pin. The voltages in | | the data tables are derived from the equation: | | Vtable = Vcc - Voutput | | Therefore, for a 5V component, -5 V in the table actually | | means 5 V above Vcc, which is +10 V with respect to ground; | | and 10 V means 10 V below Vcc, which is -5 V with respect to | | ground. Vcc-relative data is necessary to model a pullup | | structure properly, since the output current of a pullup | | structure depends on the voltage between the output and Vcc | | pins and not the voltage between the output and ground pins. | | Note that the [GND_clamp] V/I curve can include quiescent | | input currents, or the currents of a 3-stated output if so | | desired. | |------------------------------------------------------------------------------| ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions and recorded the results of the summit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: The interest at the summit seemed to be to make the data more human readable. As the approach proposed at the summit doesn't seem to have any particular advantages to simulators. (Have I missed something?) The original intention I had was to require the data be monotonic on both axes. This would make it easy for all simulators to handle the data. If the data has multivalue points, i.e. it is multistable, it could be difficult to assure that all simulators can find a stable DC operating point, and that they always switch properly. We have modified how the HyperLynx simulator handles non-monotonic data to insure that this problem will not occur. Is this a problem for any of the other simulators like SPICE? On the other hand, at least one simulator company representative felt that it is imperative to allow non-monotonic data on one axis to properly represent the effects of some devices. The IBIS_CHK program must also be modified to test for this condition. ****************************************************************************** From speters@ichips.intel.com Tue Feb 1 18:00:35 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06024; Tue, 1 Feb 94 18:00:35 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 1 Feb 94 17:59:00 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 1 Feb 94 17:58:49 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 1 Feb 94 17:58:55 PST Message-Id: <9402020158.AA15413@xtg801.intel.com> To: ibis@vhdl.org Subject: tskew and BIRD 6.X Date: Tue, 01 Feb 1994 17:58:54 -0800 From: Stephen Peters Hello Fellow IBISans -- While reading over the mail on BIRD 6.1 and the tskew specification it occurs to me that we don't spec the much more general parameter of skew between outputs. In fact, for an IC designed for clock driving, this specification is CRITICAL. For this and other reasons (see below) I belive a lot more more thought is required before lumping in a tskew spec with BIRD 6 (I agree, however, that BIRD 6 is still needed for specifing differential output associations). At the least, I propose a separate bird that addresses the tskew specification in general; both for differential outputs and output to output skew for clock drivers. I'd like to kick off a separate discussion of tskew independent of BIRD 6. Some points to address: 1. Do others feel the output-to-output skew is important? 1. Is an IBIS specification the appropriate place for including a parameter that goes beyond the basic I/O buffer and package characteristics? (Is this just like specifying the propagation delay of a device?) 3. The tskew spec is dependent on the specific interaction of the packaging, internal xsistor delays, etc. Can this really be modeled accurately? For example, suppose the tskew spec for an IC is 1ns. Would simply delaying the xsistion of one waveform by 1ns result in the output waveforms crossing the logic threshold 1ns apart after going thru the packaging LRCs? To put it another way, how does a simulator know when to start the two transitions so that they end up 'tskew'ns apart? Best Regards, Stephen Peters Intel Corp. From bob@icx.com Tue Feb 1 22:01:28 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08591; Tue, 1 Feb 94 22:01:28 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA10170 for ; Wed, 2 Feb 94 00:44:14 -0500 Date: Tue, 1 Feb 94 17:29:41 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA25415; Tue, 1 Feb 94 17:29:41 PST Message-Id: <9402020129.AA25415@icx.com> To: ibis@vhdl.org Subject: RAMP NOTE Dear IBIS folks: Here is how I interpret the [Ramp] specification in IBIS Version 1.1. This interpretation is based on two factors: (1) The NOTES ON DATA DERIVATION METHOD specify that the dv/dt_r and dV/dt_f variables be derived from the 20% and 80% points of a rising and falling transition under the loads specified (spanning 0.6 of the full voltage transition). (2) The time durations can be assumed to be the same for any resistive load (as a first order approximation). This was mentioned at the IBIS Summit in November. Therefore, if the [Ramp] specification is to be translated into a 0% to 100% time ramp (such as in the Spice PULSE specification) then the translation is as follows: trise(0-100%) = (dt_r)/.6 tfall(0-100%) = (dt_f)/.6 For example, the numbers in IBIS Version 1.1 translate as shown: |----------------------------------------------------------------------- [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n |======================================================================= trise(0-100%) 3.00n 4.17n 1.83n tfall(0-100%) 2.50n 3.83n 1.33n Bob Ross, Interconnectix, Inc. From bob@icx.com Tue Feb 1 22:41:01 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08784; Tue, 1 Feb 94 22:41:01 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA10081 for ; Wed, 2 Feb 94 00:43:55 -0500 Date: Tue, 1 Feb 94 16:10:11 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA24722; Tue, 1 Feb 94 16:10:11 PST Message-Id: <9402020010.AA24722@icx.com> To: ibis@vhdl.org Subject: BIRD7.2 Hello IBIS members and Kellee: Please send BIRD7.1 to the bird cage. Kellee, I really like your counter proposal, so I have revised BIRD7.1 exactly as you have specified. You are right that 3-state-Open-XXXX is functionally the same as setting the device in the off state. I looked at the terms in the Toshiba ASICs, and not closely at the content. If there are any distinctions, they are not relevant in IBIS, so the extra 3-state_open_xxx Model_types are removed. I think we are in complete agreement on functionality. Revisions include: Complete set of "Open types" "Open_sink" terminology introduced and means open AND sink. "Open_source" terminology introduced and means open AND source. "I/O_open_drain added for backward consistency. Inclusion of "_ECL" Types (different class of "open" devices). Notes section expansion to describe measurements. ANALYSIS PATH revision and expansion. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 7.2 ISSUE TITLE: Open Specification Completion REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 13 January 1994 DATE REVISED: 31 January 1994, 1 February 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model_type "Open_drain" provides insufficient coverage for "open" sided models. For completeness, additional "open" Model_types are need. Also, necessary ECL related Model_types are added for clarity and to avoid several tests required before processing the [Model]. Methods to produce [Ramp] data need to be expanded for "open" devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Under the keyword [Model], additional Model_type selections are added: I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Output_ECL, I/O_ECL, Input_ECL. The [Model] keyword specification in Version 1.1 is edited to show these Model_types. Changed text is separated by blank lines. NOTES ON DATA DERIVATION METHODS is revised to clarify the [Ramp] measurements for open models. The [Model] keyword is revised to the following: |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, and I/O_ECL model must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names which use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Model_types with "open_sink" specify that the output has | an OPEN side (the [Pullup] keyword is not used or I = 0mA | for all voltages specified) AND the output SINKS current. | Model_types with "open_drain" have the identical meaning and | are retained for backward compatibility. Model_types with | "open_source" specify that the output has an OPEN side (the | [Pulldown keyword is not used or I = 0mA for all voltages | specified) AND the output SOURCES current. Model_types with | "_ECL" specify that the model represents and ECL type logic | which follows different conventions for the [Pulldown] keyword. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL | List one only Polarity Non-Inverting, Inverting | List one only, -if any Enable Active-High, Active-Low | List one only, -if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired Vinl = 0.8V | input logic "low" DC voltage, -if any Vinh = 2.0V | input logic "high" DC voltage, -if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |============================================================================== Section 3) on NOTES ON DATA DERIVATION METHOD is revised as follows: 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1. Start with the silicon model, remove all packaging. 2. If: The Model_type is one of the following: Output, I/O, or 3-state (not open or ECL types); Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. If: the Model_type is Output_ECL or I/O_ECL; Then: Attach a 50 ohm resistor to the termination voltage (Vterm = VCC - 2v). Use this load to derive both the rising and falling edges. If: The Model_type is either an open_sink type or open_drain type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The Model_type is an open_source type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 3. and 7.: **** Delete Items 3. and 7. **** 4. - 6.: **** Renumber these Items as 3. - 5. **** ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Open-drain is corrected to Open_drain as a Model_type selection and is kept for backward compatibility. I/O_open_drain is added. The new types with "open_sink" and "open_source" are added to generically describe an output with either an open [Pullup] or [Pulldown] and an output that sinks or sources current. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_Open_source no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. For the "open" Model_types there exists several other naming methods based on comments received and some combinations I though of. BIRD7.2 is written in terms of (0). (0) Retain "Open_drain" and add "I/O_open_drain" for Version 1.1 consistency. Add "open_sink" and "open_source" Model_types. (5 new terms, 2 redundant terms). no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_open_source (1) Use "up" and "down". Retain Open_drain for Version 1.1 compatibility as a redundant Model_type. (Bird7.1 - 4 new terms, 1 redundant term). no pullup: | Open_up I/O_Open_up | Open_drain no pulldown: | Open_down I/O_Open_down (2) Retain "Open_drain", but use "up" & "down" for generic names elsewhere. (3 new terms). no pullup: | Open_drain I/O_Open_up no pulldown: | Open_down I/O_Open_down (3) Use "drain", "collector", "emitter". "emitter is generic for CMOS logic & TTL no pulldown devices. (5 new terms). no pullup: | Open_drain I/O_Open_drain | Open_collector I/O_Open_collector no pulldown: | Open_emitter I/O_Open_emitter (4) Use "drain" generically for "up", and "source" generically for "down" for TTL and CMOS logic. (Bird7.0 - 3 new terms) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_source I/O_Open_source (5) Use "Open_drain" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (1 new term) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_drain I/O_Open_drain (6) Retain "Open_drain, but use "Open" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (2 new terms) no pullup: | Open_drain I/O_Open no pulldown: | Open I/O_Open (7) Use "Open" generically to mean "Open". Retain "Open_drain" for Version 1.1 compatibility. Test for no pullup or no pulldown in [Model]. (2 new terms, 1 redundant term). no pullup: | Open I/O_Open | Open_drain no pulldown: | Open I/O_Open Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "open_sink" device. Omission of [Pulldown] could be interpreted as an "open_source" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink" or "open_drain" types. Zero valued [Pulldown] data corresponds to "open_source" types. Without the additional Model_types, the above two approaches plus the existance of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. One final consideration is that whoever generates the [Model], whether through simulation or measurement, must know beforehand the Model_type in order to generate the [Ramp] data according to the rules. Therefore it is reasonable to require that this information be included as part of a Version 2.0 specification. This avoids the inefficiency of forcing the simulator to perform many tests before processing the IBIS data. The simulator can then translate the data into its internal format and apply its own simulator- specific compaction schemes (the simulator does not have to provide all of the Model_types). With BIRD7.2, the IBIS Statement of Intent within the first paragraph is preserved: "the intention of this template is to specify a consistent format that can be parsed by software, allowing each simulation vendor to derive models compatible with their own product." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell initiated the issue in Email of October 1993 questioning whether we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the SN74ALS641 Open Collector Tranceiver as a specific example. Kellee Crisafulli in Email of July 1993 considered "open output devices (open-drain, open-collector, open-source)". Furthermore, he referred to "open collector npn" and "open collector pnp" devices. In the discussion, he proposed new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off time of high side driver) and dv/dt_f_off (turn off time of low side driver). Included it the discussion was the requirement that "If the pulldown table is missing then dV/dt_r_off is required" and "If the pullup table is missing then dV/dt_f_off is required". Kellee elaborated further on the measurement/extraction issues of the ramp values. BIRD7.1 now addresses the ramp specification. The modifications on Notes on Derivations Method by Kellee Crisafulli and Stephen Peters are added with changes for notation consistency. The usage of "Open_up" and "Open_down" is an adaptation of one of Arpad Muranyi's comments on BIRD7 suggesting "open pullup" and "open pulldown". Kellee Crisafulli's last suggestion on notation has been adopted in BIRD7.2. ****************************************************************************** From 71436.1314@CompuServe.COM Tue Feb 1 22:43:31 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08789; Tue, 1 Feb 94 22:43:31 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id BAA05759; Wed, 2 Feb 1994 01:41:52 -0500 Date: 02 Feb 94 01:39:49 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: BIRD 6.x (regarding tskew) Message-Id: <940202063949_71436.1314_HHB44-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx To: IBISians and Stephen Peters,Intel Re: Stephen Peters comments on tskew in Bird 6.x I believe that tskew for clock buffers is one of those grey areas. It is most probably an issue for digital simulation like any other in-pin to out-pin delay term. If this is the case than I believe we should ignore pin-pin skew at least for version 2.0 IBIS. On the other hand I believe some people could make a case that for optimal signal integrity analysis we may wish to analyze multiple clock nets simutaneously and watch for cross-talk etc. This would require knowledge of out-pin to out-pin skew. However if this is the case than how about other clock net's relative to each other. Or what about a clock buffered by two different clock chips. This looks like it could be a venomous snake pit to me! I propose we handle tskew for diffential mode outputs and leave other tskew issues for rev. 3 of the specification or later. Best Regards, Kellee HyperLynx Inc. From JAYD@RALVM29.VNET.IBM.COM Wed Feb 2 05:26:42 1994 Return-Path: Received: from vnet.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17083; Wed, 2 Feb 94 05:26:42 PST Message-Id: <9402021326.AA17083@vhdl.vhdl.org> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2511; Wed, 02 Feb 94 08:24:06 EST Date: Wed, 2 Feb 94 08:24:09 EST From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" X-Addr: Transceiver Technology Dev't, D63/061 IBM Network Hdwe. Div. P. O. Box 12195 Research Triangle Park, NC 27709 To: ibis@vhdl.org Subject: RAMP NOTES Hello IBIS folks, I'd like to add my two cents to Bob Ross' comments on the above. Bob's approach of scaling the ramp rate by 0.6 to obtain the 0-100% rise/fall time from the present 20-80% rise/fall times in the IBIS 1.1 specification value makes the assumption that the waveforms are perfectly trapezoidal in nature. That is anything but the case in most real circuits, where the edges are rounded, and will result in very pessimistic (fast) 0-100% rise and fall times. If you want 20-80% numbers, measure those, if you want 0-100% numbers, measure those. I would suggest that due to the shape of the waveforms the 0-100% rise/fall times are not terribly useful for the purpose of signal integrity analysis; in fact, I'm curious as to how the spec. ended up at 20-80%, since the generally accepted method for measuring rise and fall times in hardware is from 10 to 90% or vice versa. Jay Diepenbrock From cer@Cadence.COM Wed Feb 2 07:10:40 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17979; Wed, 2 Feb 94 07:10:40 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id HAA22028 for ; Wed, 2 Feb 1994 07:09:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma022007; Wed Feb 2 07:08:08 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA02913; Wed, 2 Feb 94 07:01:49 -0800 Received: by oahu (5.65+/1.5) id AA07770; Wed, 2 Feb 94 10:07:07 -0500 Date: Wed, 2 Feb 94 10:07:07 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9402021507.AA07770@oahu> To: ibis@vhdl.org Subject: RAMP NOTES Ibis Folk, I assumed the ramp specification was supposed to be the linear portion of the ramp, representing an "ideal" slew rate. We therefore calculate the rise time to be (delta-V)/(slew-rate) where delta-V is the total voltage swing. In a simulation a trapezoidal waveform with this rise-time drives the switching time between two V/I curves (PullUp and PullDown). This produces a waveform with a linear portion that has approximately the specified slew-rate. Chris Reid cer@cadence.com From 71436.1314@CompuServe.COM Wed Feb 2 08:01:07 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18747; Wed, 2 Feb 94 08:01:07 PST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id KAA11988; Wed, 2 Feb 1994 10:59:31 -0500 Date: 02 Feb 94 10:56:57 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Ramp Times (kellee's two cents) Message-Id: <940202155656_71436.1314_HHB71-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx Re: Ramp Notes: I agree with Jay Diepenbrock completely. The ramp time should not be converted directly to a linear slew except for the region from 20% to 80%. If you need a method of creating the output curves, a suggested spice model for IBIS created by Arpad at Intel is useful for a starting point on a new simulator. Perhaps we should consider adding this to the specification as a reference point (An appendix perhaps)? As to why 20% to 80% was chosen instead of 10% and 90%, I don't remember the specifics, however I believe that only 2 or 3 semiconductor house people were available during the initial release to contribute to this effort. They were a major source for these percentages. Apparently some of the semiconductor people do use 20% to 80%. Hopefully this won't be a major problem. If it turns out to be a problem we could consider extending the measurement points linearly to 10% and 90%. (Are you interested in another BIRD on this Bob?) Have a great day IBISians! Kellee From ccm!Arpad_Muranyi@intelhf.intel.com Wed Feb 2 08:58:16 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19793; Wed, 2 Feb 94 08:58:16 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRksW-000MNsC; Wed, 2 Feb 94 08:56 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRkus-0000sFC; Wed, 2 Feb 94 08:59 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 08:59:02 PST Date: Wed, 2 Feb 94 08:59:02 PST From: Arpad Muranyi Message-Id: <940202085902_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re(x) T_skew Text item: Text_1 Hi IBIS folks, Regarding 20-80%, as far as I remember, we (my group at Intel) started to use 20-80% (and not 10-90%) in IBIS measurements simply because it is not always easy to obtain a clean slope between 10-90% due to the parasitics and noise. Since the ramp in my original implementation of the behavioral HSPICE model is a perfect trapezoidal representing an idealized internal node, I felt that I should get the straightest part of the slope from a measurement. This straight line ramp is then rounded by the packaging and C_comp parasitics. Arpad Intel Corporation From qdt!sal!jonp@uunet.UU.NET Wed Feb 2 09:17:12 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19946; Wed, 2 Feb 94 09:17:12 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwbnp12720; Wed, 2 Feb 94 12:15:26 -0500 Received: from qdt.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 121333.24208; Wed, 2 Feb 1994 12:13:33 EST Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00491; Wed, 2 Feb 94 08:53:18 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA05515; Wed, 2 Feb 94 08:53:18 PST Date: Wed, 2 Feb 94 08:53:18 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9402021653.AA05515@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA06231; Wed, 2 Feb 94 08:53:20 PST To: ibis@vhdl.org Subject: BIRD 6.etc I have a question concerning the input threshold specification on the differential receivers. In the data books that I have looked at (most TI) they specify a possitive differential threshold and a negative differential threshold (just like regular single ended receivers). In the examples I looked at the possitive TH (called Vth) was +.2 and the negative (Vtl) was -.2. I don't know if these guys are always inverses of each other. Is this the intent at how Vpp is to be used? That is, if the pins are more that +vpp away we have a HIGH and if they are further that -vpp away we have a LOW? Is is guaranteed that Vtl and Vth are always symetric? yes, I'm back from the hospital, and most of my house is still standing, jon powell From ccm!Arpad_Muranyi@intelhf.intel.com Wed Feb 2 10:15:48 1994 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20447; Wed, 2 Feb 94 10:15:48 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRm56-000MP4C; Wed, 2 Feb 94 10:13 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRm7V-0000aEC; Wed, 2 Feb 94 10:16 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 10:16:09 PST Date: Wed, 2 Feb 94 10:16:09 PST From: Arpad Muranyi Message-Id: <940202101609_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Resending Re(x) T_skew Text item: Text_1 Author: MAILER-DAEMON@hermes.intel.com at Internet_Gateway Date: 2/2/94 9:13 AM Priority: Normal Hi IBIS folks, Regarding 20-80%, as far as I remember, we (my group at Intel) started to use 20-80% (and not 10-90%) in IBIS measurements simply because it is not always easy to obtain a clean slope between 10-90% due to the parasitics and noise. Since the ramp in my original implementation of the behavioral HSPICE model is a perfect trapezoidal representing an idealized internal node, I felt that I should get the straightest part of the slope from a measurement. This straight line ramp is then rounded by the packaging and C_comp parasitics. Arpad Intel Corporation From huq@rockie.nsc.com Wed Feb 2 11:22:11 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21303; Wed, 2 Feb 94 11:22:11 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA24187 for ibis@vhdl.org; Wed, 2 Feb 94 11:20:35 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22108 for ibis@vhdl.org; Wed, 2 Feb 94 11:20:33 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA00416; Wed, 2 Feb 94 11:24:23 PST Date: Wed, 2 Feb 94 11:24:23 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9402021924.AA00416@rockie.nsc.com> To: ibis@vhdl.org Subject: RE: Vth BIRD 6.etc Cc: huq@rockie.nsc.com Hi jon, I hope this explanation helps. For a diff. rcvr, the Vth and Vtl or VT+ and VT- are levels swinging above and below 0 volts differential and not 0 volts ground. Here is an example. Let's say Receiver inputs are VIH=+1.5V and VIL=+1.3V For the First cycle VT+ = 1.5-1.3 = +0.2 volts. On the next cycle, VT- = 1.3-1.5 = -0.2V. That's how you get a +/- number. Note that the VIH and VIL were always +ve voltages. Ideally the Vth and Vtl are symetrical. Regards, Syed Huq ----- Begin Included Message ----- From qdt!sal!jonp@uunet.UU.NET Wed Feb 2 09:30:20 1994 Date: Wed, 2 Feb 94 08:53:18 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) To: ibis@vhdl.org Subject: BIRD 6.etc Content-Length: 735 I have a question concerning the input threshold specification on the differential receivers. In the data books that I have looked at (most TI) they specify a possitive differential threshold and a negative differential threshold (just like regular single ended receivers). In the examples I looked at the possitive TH (called Vth) was +.2 and the negative (Vtl) was -.2. I don't know if these guys are always inverses of each other. Is this the intent at how Vpp is to be used? That is, if the pins are more that +vpp away we have a HIGH and if they are further that -vpp away we have a LOW? Is is guaranteed that Vtl and Vth are always symetric? yes, I'm back from the hospital, and most of my house is still standing, jon powell ----- End Included Message ----- From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 22:58:14 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28824; Wed, 2 Feb 94 22:58:14 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRxzP-000MNPC; Wed, 2 Feb 94 22:56 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRy1m-00007HC; Wed, 2 Feb 94 22:59 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 22:59:01 PST Date: Wed, 2 Feb 94 22:59:01 PST From: Derrick Duehren Message-Id: <940202225901_1@ccm.hf.intel.com> To: ibis@vhdl.org Cc: Randy_L_Wilhelm@ccm.hf.intel.com, Jerry_Budelman@ccm.hf.intel.com Subject: IBIS Open Forum 1/28/94 Minutes Text item: Text_1 Date: February 2, 1994 From: Derrick Duehren (503) 696-4299, fax (503) 696-4904 dduehren@ichips.intel.com Intel Program Manager (Will Hobb's IBIS Assistant) Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Will Hobbs (503) 696-4369, fax (503) 696-4210 Intel Modeling Manager Subject: Minutes from IBIS Open Forum 1/28/94 To: Anacad Petra Osterman AnSoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran, Mike Venthon* Digital Equipment Corp. Berry Catz* High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* IBM Jay Diepenbrock IBM-Motorola alliance Lynn Warner*, Soa Quoc* Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens* IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong MicroSim Arthur Wong*, Jerry Brown, Graham Bell National Semiconductor Syed Huq* North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell Quantic Labs Mike Ventham, Zhen Mu Siemens Nixdorf Werner Rissiek, Olaf Rethmeier* Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu*, George Opsahl*, Samie Samaan, Tay Wu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the 1/28/94 meeting are indicated by * Upcoming Meetings: Date: Bridge: Res: 2/18/94 (415) 904-8800 661436 3/11/94 (415) 904-8944 661901 4/1/94 (415) 904-8944 661905 All meetings are 8:00 AM to 10:00 AM PST. 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, as always, ask for the IBIS Open Forum and give the bridge operator the reservation number. Please note: If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), or have updates to your e-mail address, send e-mail to ibis-request@vhdl.org. ------------------------------------------------------------------------ Meeting Agenda -------------- In keeping with the wishes of various participants, Will arranges the order to keep technical discussions later. 8:15 Check-in 8:20 Introductions of new IBIS members/participants Hobbs 8:25 1/7 minutes review Duehren Opens for new issues All Treasurers Report Hobbs 8:35 Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 Hobbs Forms of EDA support of IBIS Duehren IBIS Cookbook Hobbs Dues? For what? Hobbs 8:50 BIRD 6, Differential Pin Spec. Ross BIRD 7, Open Specification Completion Ross Egg 1, mutual pin coupling Bracken Spice to IBIS Converter Lipa 9:15 Canright paper Ward Formal BNF notation Reed, Harr BIRD 2, VIH, VIL Thresholds for Inputs Powell 9:30 3D Modeling (U of NC) Bracken, et. al. High freq. $ EMI Goyal, et. al. 9:45 Phased turn-on/off of multiple devices Powell Foils of IBIS Summit Hobbs 9:55 Wrap-up, Next Meeting Plans Hobbs Minutes ------- 1. New members, 11/12 Minutes review, Open time for new issues: There were no new members to announce and no corrections were made to last month's minutes. 2. Opens for new issues Derrick will post all the BIRDs to the forum this week. He has cleaned up formatting inconsistencies and problems (such as converting tabs to spaces). The files are named with p (new/pending), a (approved), or d (dead) prefixes (such as abird3_0.txt, for approved BIRD 3.0). Arpad Muranyi: We need agreement on when to clamp the low state of the pull-down curve of tri-stateable components. AR Arpad M.: Post your ideas to reflector. In regard to monotonic current tracing, one axis must be monotonic. It is not specified well and needs a BIRD. Discussion to be continued on the reflector. AR Kellee C.: Please be the owner for this BIRD. Intel has Pentium(TM) processor chip set IBIS models on vhdl.org. No other company directories exist. 3. Press updates HyperLynx press release in Test & Measurement World, Jan. '94. 4. Progress toward enlisting new IC vendors NEC and another IC vendor have shown IBIS interest. 5. Treasurers Report Contractor work on the parser has been paid. We now have a $2,195.21 balance. 6. IBIS 2.0 Clarification of last meeting's decision. Will suggests a full-day meeting to ratify 2.0, perhaps during the DAC (design automation conference) conference (June 6- 10? in San Diego). 7. Forms of EDA support of IBIS Derrick has compiled a database of all forum members. AR Derrick D.: Send out existing database with instructions for participants to fill out/correct their information. 2/2/94 Update: Done. Numerous responses already received. 8. IBIS Cookbook Intel is producing an internal cookbook that describes how to generate IBIS models from simulated and actual data. It needs to be more robust. Intel will make non-proprietary parts available to the forum. Lynn Warner expressed need for basic instructions now. He was directed to the Overview book and Steven Peters volunteered to help. 9. Dues? For what? Will asked the forum to consider what dues (if collected) would be used for. The following ideas were voiced: o Cookbook contractor o DAC booth o IBIS checker program (parser) maintenance 10. BIRD 6, Differential Pin Spec. Bob Ross summarized BIRD 6. IBIS needs to support differential devices. Bob Ward asked for clarification on definition of the differential devices; signal/signal differential around a common reference. Lively discussion ensued with Kumar, Syed H., Steven P., and Kellee C. Bob Ross would like to have this referenced to the data book. Kumar asked how you do the V/I differentially? Answer: No, two single- ended V/I measurements. You would model each pin individually. Syed: NSC is interested in developing such models, the reference is not necessarily around zero. HyperLynx: We need some type of skew specification. Bob: min, typ or max or just max? Kellee: all three allowed, typ is required. If not specified, = 0? Is that min or typ? How about low-to-high skew versus high-to-low? Min will always be zero. AR Bob Ross: Revise Bird 6 to address skew and post for discussion. 11. BIRD 7, Open Specification Completion Bob Ross, summarized and gave the background of the BIRD. Bob wants to expand the BIRD (spread its wings). The fundamental question is: should we explicitly specify all the model types, even though the data may make it implicit (no pull-up vi=> open pull-up, e.g.,). There is human readability value. Bob favors the latter, and expanding to include ECL and pull-up resistors, etc. For IBIS version 2, new model types will be required to be specified, whereas in 1.1, open side is inferable and will remain so. Kellee: The recommendation we have in version 1.1 for derivation of ramp rates only really works well for CMOS. It needs revision. Kumar proposed terminal mapping. Need to ensure backward compatibility. AR Bob Ross to update the BIRD to 7.1 and post for discussion. Terminator issue are to be left to another BIRD. 12. Egg 1, mutual pin coupling Eric B. summarized the Egg. Sparse matrix versus banded matrix. DEC feels mutuals are very important. IBM has requirement for this capability in a full diagonal matrix (banded or sparse will not be sufficient)or else IBIS won't work for IBM. Mutuals account for 90% of the capacitance of the package, particularly with ball grid array. Capacitive and inductive parameters are only ones required. NSC and TI also feel this is important, too. Bob Ward also emphasized that the power and ground pins need to be included, too. On a 200 pin package, that would be a 200x200 matrix, 40,000 entries! Lynn of IBM: Recommended breaking it into several triangular matrices, one for capacitance, one for inductances, etc. An include file looks like a win here, so we can change packages. Kellee points out we have side issues with include files: file naming conventions, directory conventions. And if we have a part that comes in multiple packages, could the IBIS file have all the pointers for each of the package types? Lynn: Are we focusing too much on file size and not enough on functionality? AR Eric: Generate Egg 1.1 for more discussion. 13. Spice to IBIS Converter A Ph.D. student has a grant to write a first-level converter. We need to discuss this issue on reflector. Lingering question: what flavor of PUBLIC Spice model as source? 14. Canright paper No discussion, out of time. 15. Formal BNF notation No discussion, out of time. 16. BIRD 2, VIH, VIL Thresholds for Inputs No discussion, out of time. 17. 3D Modeling (U of NC) No discussion, out of time. 18. High freq. $ EMI No discussion, out of time. 19. Phased turn-on/off of multiple devices No discussion, out of time. 20. Foils of IBIS Summit 5 copies of the IBIS foils of the November summit are available from Derrick Duehren (address information above). 21. Wrap-up, Next Meeting Plans We decided to start the meeting at 8:00 in the future so we'll have a full two hours. From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:21:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28968; Wed, 2 Feb 94 23:21:08 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRyLd-000MNOC; Wed, 2 Feb 94 23:19 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyO1-0000YoC; Wed, 2 Feb 94 23:22 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 23:22:01 PST Date: Wed, 2 Feb 94 23:22:01 PST From: Derrick Duehren Message-Id: <940202232201_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS BIRDs (all of them) Text item: Text_1 Attached are all of the cleaned up BIRD files as of 2/2/94. (They should end up concatenated below. These will also be posted to vhdl.org as soon as I figure out how to get them there.) I have cleaned up formatting inconsistencies and problems (such as converting tabs to spaces). I have named the files with p (new/pending), a (approved), and d (dead) prefixes (such as abird3_0.txt, for approved BIRD 3.0). - Derrick Duehren Text item: bird.txt 2/2/94 10:01A BIRD filename convention: pbirdn_n.txt new/pending abirdn_n.txt approved dbirdn_n.txt dead -------------------------------------------------------------------------------- Howdy, 9/15/93 The following is your key to getting issues resolved in the IBIS Open Forum. It's called a "Buffer Issue Resolution Document" or "BIRD". Issues must be well thought out and clearly documented using this template to be placed on the agenda of a future IBIS Open Forum. Here's how the process works. Write up your issue and submit it to Will. Will's group will do a preliminary check for completeness and (potentially) send your BIRD back to you. If not, Will will post the issue to the reflector. Each issue must be out for review for two weeks before the Open Forum will vote on it. During that time, you will be expected to answer questions related to your BIRD. In each meeting announcement, Will will list those BIRDs that are ready for a vote at that meeting. A BIRD will be accepted if EVERYONE at the meeting agrees with it. Please note that Open Forum time will not be used for detailed BIRD review, but rather for confirming consensus. Detailed review MUST ensue during the two-week review cycle via emails. Dissenters should not wait until the Open Forum to express their opinions. So far the group has been exceedingly cooperative, achieving a 1.0 spec in only a couple of months. Hopefully this process will allow us to use time more efficiently, while maintaining the same flavor in the larger group setting. Regards, Don Telian NOTE: All text in french brackets is for explanation only and should be deleted. ---------------------------- cut here ----------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: {don't fill in, will be filled in by Will Hobbs for tracking} ISSUE TITLE: {one line description of your issue} REQUESTOR: {your name and company} DATE SUBMITTED: {date you sent to Will} DATE REVISED: {revision date} DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: {Place a short description of your issue here. People should be able tell by reading this if they care about this in less than 1 minute.} ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: {For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a future IBIS specification. If this is a change, state the old text and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give intended location in the specification.} ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: {There are many "experts" reviewing this document. Your reasons, analysis, and justifications must be precise and well documented, or your BIRD will be sent back to you. Use this section to show that you've done your homework, and answer all questions that will undoubtedly be asked. If your issue is a change instead of an enhancement, document how backward compatibility is to be addressed.} ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ******************************************************************************* Text item: pbird8_0.txt 2/2/94 10:17A ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.0 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. I searched all the IBIS minutes and found the following two IBIS minutes relating to montonicity: ------------------------------------------------------------------------------- From meeting Nov 5, 1993 We engaged in a discussion on monotonic behavior. There are two aspects -to be dealt with. 1) How should we deal with output buffers that exhibit non-monotonic behavior (and in what situations does this occur)? 2) Must data be entered in the IBIS file monotonically? 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ From the 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:' and continue for 4 lines. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All four columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. * At least one axis of the data (voltage or current) is -required * to be monotonic. For example if the voltage is monotonic and * increasing, each seqential voltage point must be larger than * the previous value. | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions and recorded the results of the summit. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The interest at the summit seemed to be to make the data more human readable. As the approach proposed at the summit doesn't seem to have any particular advantages to simulators. (Have I missed something?) The original intention I had was to require the data be monotonic on both axes. This would make it easy for all simulators to handle the data. If the data has multivalue points, i.e. it is multistable, it could be difficult to assure that all simulators can find a stable DC operating point, and that they always switch properly. We have modified how the HyperLynx simulator handles non-monotonic data to insure that this problem will not occur. Is this a problem for any of the other simulators like SPICE? On the other hand, at least one simulator company representative felt that it is imperative to allow non-monotonic data on one axis to properly represent the effects of some devices. The IBIS_CHK program must also be modified to test for this condition. ******************************************************************************** Text item: pbird7_2.txt 2/2/94 10:12A ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 7.2 ISSUE TITLE: Open Specification Completion REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: January 13, 1994 DATE REVISED: January 31, 1994, February 1, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model_type "Open_drain" provides insufficient coverage for "open" sided models. For completeness, additional "open" Model_types are need. Also, necessary ECL related Model_types are added for clarity and to avoid several tests required before processing the [Model]. Methods to produce [Ramp] data need to be expanded for "open" devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Under the keyword [Model], additional Model_type selections are added: I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Output_ECL, I/O_ECL, Input_ECL. The [Model] keyword specification in Version 1.1 is edited to show these Model_types. Changed text is separated by blank lines. NOTES ON DATA DERIVATION METHODS is revised to clarify the [Ramp] measurements for open models. The [Model] keyword is revised to the following: |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, and I/O_ECL model must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names which use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Model_types with "open_sink" specify that the output has | an OPEN side (the [Pullup] keyword is not used or I = 0mA | for all voltages specified) AND the output SINKS current. | Model_types with "open_drain" have the identical meaning and | are retained for backward compatibility. Model_types with | "open_source" specify that the output has an OPEN side (the | [Pulldown keyword is not used or I = 0mA for all voltages | specified) AND the output SOURCES current. Model_types with | "_ECL" specify that the model represents and ECL type logic | which follows different conventions for the [Pulldown] keyword. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL | List one only Polarity Non-Inverting, Inverting | List one only, -if any Enable Active-High, Active-Low | List one only, -if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired Vinl = 0.8V | input logic "low" DC voltage, -if any Vinh = 2.0V | input logic "high" DC voltage, -if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |============================================================================== Section 3) on NOTES ON DATA DERIVATION METHOD is revised as follows: 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1. Start with the silicon model, remove all packaging. 2. If: The Model_type is one of the following: Output, I/O, or 3-state (not open or ECL types); Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. If: the Model_type is Output_ECL or I/O_ECL; Then: Attach a 50 ohm resistor to the termination voltage (Vterm = VCC - 2v). Use this load to derive both the rising and falling edges. If: The Model_type is either an open_sink type or open_drain type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The Model_type is an open_source type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 3. and 7.: **** Delete Items 3. and 7. **** 4. - 6.: **** Renumber these Items as 3. - 5. **** ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Open-drain is corrected to Open_drain as a Model_type selection and is kept for backward compatibility. I/O_open_drain is added. The new types with "open_sink" and "open_source" are added to generically describe an output with either an open [Pullup] or [Pulldown] and an output that sinks or sources current. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_Open_source no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. For the "open" Model_types there exists several other naming methods based on comments received and some combinations I though of. BIRD7.2 is written in terms of (0). (0) Retain "Open_drain" and add "I/O_open_drain" for Version 1.1 consistency. Add "open_sink" and "open_source" Model_types. (5 new terms, 2 redundant terms). no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_open_source (1) Use "up" and "down". Retain Open_drain for Version 1.1 compatibility as a redundant Model_type. (Bird7.1 - 4 new terms, 1 redundant term). no pullup: | Open_up I/O_Open_up | Open_drain no pulldown: | Open_down I/O_Open_down (2) Retain "Open_drain", but use "up" & "down" for generic names elsewhere. (3 new terms). no pullup: | Open_drain I/O_Open_up no pulldown: | Open_down I/O_Open_down (3) Use "drain", "collector", "emitter". "emitter is generic for CMOS logic & TTL no pulldown devices. (5 new terms). no pullup: | Open_drain I/O_Open_drain | Open_collector I/O_Open_collector no pulldown: | Open_emitter I/O_Open_emitter (4) Use "drain" generically for "up", and "source" generically for "down" for TTL and CMOS logic. (Bird7.0 - 3 new terms) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_source I/O_Open_source (5) Use "Open_drain" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (1 new term) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_drain I/O_Open_drain (6) Retain "Open_drain, but use "Open" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (2 new terms) no pullup: | Open_drain I/O_Open no pulldown: | Open I/O_Open (7) Use "Open" generically to mean "Open". Retain "Open_drain" for Version 1.1 compatibility. Test for no pullup or no pulldown in [Model]. (2 new terms, 1 redundant term). no pullup: | Open I/O_Open | Open_drain no pulldown: | Open I/O_Open Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "open_sink" device. Omission of [Pulldown] could be interpreted as an "open_source" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink" or "open_drain" types. Zero valued [Pulldown] data corresponds to "open_source" types. Without the additional Model_types, the above two approaches plus the existance of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. One final consideration is that whoever generates the [Model], whether through simulation or measurement, must know beforehand the Model_type in order to generate the [Ramp] data according to the rules. Therefore it is reasonable to require that this information be included as part of a Version 2.0 specification. This avoids the inefficiency of forcing the simulator to perform many tests before processing the IBIS data. The simulator can then translate the data into its internal format and apply its own simulator- specific compaction schemes (the simulator does not have to provide all of the Model_types). With BIRD7.2, the IBIS Statement of Intent within the first paragraph is preserved: "the intention of this template is to specify a consistent format that can be parsed by software, allowing each simulation vendor to derive models compatible with their own product." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell initiated the issue in Email of October 1993 questioning whether we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the SN74ALS641 Open Collector Tranceiver as a specific example. Kellee Crisafulli in Email of July 1993 considered "open output devices (open-drain, open-collector, open-source)". Furthermore, he referred to "open collector npn" and "open collector pnp" devices. In the discussion, he proposed new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off time of high side driver) and dv/dt_f_off (turn off time of low side driver). Included it the discussion was the requirement that "If the pulldown table is missing then dV/dt_r_off is required" and "If the pullup table is missing then dV/dt_f_off is required". Kellee elaborated further on the measurement/extraction issues of the ramp values. BIRD7.1 now addresses the ramp specification. The modifications on Notes on Derivations Method by Kellee Crisafulli and Stephen Peters are added with changes for notation consistency. The usage of "Open_up" and "Open_down" is an adaptation of one of Arpad Muranyi's comments on BIRD7 suggesting "open pullup" and "open pulldown". Kellee Crisafulli's last suggestion on notation has been adopted in BIRD7.2. ****************************************************************************** Text item: pbird6_1.txt 2/2/94 10:04A ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 6.1 ISSUE TITLE: Differential Pin Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: January 12, 1994 DATE REVISED: January 29, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Several components contain pins which operate in a differential mode with respect to other pins. Since this operation in inherent to a component, the IBIS document should be extended to specify this functionality. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional optional keyword, [Diff_Pin], is added to the specification. |============================================================================== | Keyword: [Diff_Pin] | Required: Optional |Description: Used to associate differential pins, their peak-to-peak | differential voltages and timing skews. | Sub-Params: inv_pin, vdiff, tskew_typ, tskew_min, tskew_max |Usage Rules: Entries follow these rules: Only differential pin pairs | are entered. The [Diff_pin] column contains a non-inverting | pin number and the inv_pin column always contains the | corresponding inverting pin number for output and I/O output. | The vdiff column contains the specified peak-to-peak voltage | between pins if the pins are Input or I/O Model_types. | For Output only differential pins, the vdiff entry is 0V. |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff_pin] column will be Non-Inverting and the pin in the | inv_pin column will be Inverting. This convention allows | one [Model] to be used for both pins. | | Column length limits are: | [Diff_Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tskew_typ 9 characters max | tskew_min 9 characters max | tskew_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tskew_typ or tskew_min columns, its | entry will be interpreted as 0V or 0ns. If "NA" appears in | the tskew_max column, its value will be interpreted as the | tskew_typ value. When using six columns, the headers | tskew_min and tskew_max must be listed. |------------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tskew_typ tskew_min tskew_max | 3 4 150mV 1ns 0ns 2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tskew = 0ns 22 21 NA NA | Output*, tskew = 0ns | * Could be Input or I/O with vdiff = 0V ********************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins that provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have a differential input sensitivity specification such as "Vpp" or "VT+" and "VT-" which defines a peak-to-peak voltage between two input pins. The vdiff column is introduced for such specification limits (as a positive value) which would trigger an output transition. One application is for timing analysis. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | | |<-- tmax -->| | | |<-- tmin ->|| __________ || ____________ __ \ || / A0 __\||/__ \/ vdiff DIFFERENTIAL INPUT __ /\ __ / \ __________/ \____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. Tskew can be shown per National Interface Databook, diagram on pg 1-121: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ \ / \ / ^ D0 | Vo/2 \ / \/ Vo/2 Vo v______\ /__ __|/\|_____v DIFFERENTIAL OUTPUT |\/| / \ | |/\| /| |\ v____________/ \__________/ | | \_______ D0 | | | | | | Tskew | | Tskew Tskew = |tPLH - tPHL| Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ******************************************************************************** ANY OTHER BACKGROUND INFORMATION: Introducing a [Tskew] keyword similar to [Package] (used for defaults) was suggested and could be considered as another method for dealing with skew. An alternative polarity mechanism for differential outputs could have been based on the Polarity sub-parameter within the [Model]. This was not done because Polarity is optional and also because two [Model]s would be required: one for the "Non-inverting" pin and another for the "Inverting" pin. In BIRD6.1, vdiff is used as an absolute difference regardless of polarity for Input specfication, so "polarity" no longer is applicable for inputs. However, it still may be reasonable to require two Output or I/O [Model]s for easier translation into simulator databases. In this case, the "inv_pin" name could be changed to "2nd_pin". Also, with a Polarity sub-parameter, the possibility exists that the [Models] are in phase with each other. This may be useful for double strength buffer options. ******************************************************************************* Text item: pbird2_0.txt 1/27/94 10:41P ****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 2.0 ISSUE TITLE: Requiring VIH VIL Thresholds for Input Devices REQUESTOR: Jon Powell, Quad Desgin DATE SUBMITTED: October 4, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: {likely to be superceeded} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The V1.1 IBIS specification does not require the presence of input thresholds on input devices. This allows data-generators to omit thresholds and still create "IBIS LEGAL" models. Input devices with no stated digital logic input thresholds would only be usefull if the inputs were totaly analog devices (a condition that is not in the main-stream of IBIS targetted devices). Requiring a low and high threshold for all input devices is therefor a reasonable requirement that adds information without creating undo restrictions. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: No new keywords are required. The following text to be added to the Other Notes section of the [Model] keyword description: The sub-parameters Vinl and Vinh are required for Model_types of: "Input" and "I/O". Omission of Vinl or Vinh for these devices will cause a parser error. Any other device type that contains a Vinl or Vinh parameter will cause a parser warning. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: There are devices that are not Input or Outputs and are not handled by our current set of model types. For instance: Termination Resistor Packs Termination Diode Packs Descrete 2 port devices I believe that more change is needed in this particular area but that that change is large enough that we should discuss it at our meeting as opposed to random email messages. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ****************************************************************************** Text item: dbird1_0.txt 1/27/94 10:41P ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 1.0 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: DATE ACCEPTED BY IBIS OPEN FORUM: {transmutted to BIRD 4.0} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are three in number: (1) Adding one more choice to the [Model] keyword sub-parameter 'Model_type' (2) Lessening the required voltage range over which an ECL output is characterized (3) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to add the choice of 'ECL' to the list of allowed choices for the 'Model_type' sub-parameter used with the [Model] keyword. This choice must be used when the device output being described has an ECL type output structure. Specifically, change the description of the [Model] keyword as follows: WAS: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain | List only one . . . PROPOSED: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, ECL | list only one . . . (2) The second change is to relax (decrease ) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Finally, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: In the following discussion I am assuming the reader understands the basic operation of an ECL logic gate and the emitter follower output structure. I am also defining VCC to be the most positive supply, while GND as the most negative supply. A "totem-pole" output is the standard type output structure with the source (emitter) of a pullup transistor connected to the drain (collector) of a pulldown transistor. (1) The purpose in requiring the user to specify 'ECL' in the Model_type sub-parameter is to give a simulator an explicit indication that the device being modeled has an ECL type output structure. As far as the IBIS spec is concerned, the fundamental difference between an ECL output and the standard totem-pole or open-drain/collector output is that, for ECL, data in the PULLDOWN table is referenced to VCC and changes in VCC effect the logic low voltage output level. This means when simulating an ECL output a simulator must construct a different model and make different assumptions regarding the output characteristics of the device. The following discussion explains these differences in more detail. Currently, voltage data points in the pulldown table are referenced to GND. This is because in a standard totem-pole type output the output voltage in the logic low state is determined by Vds (or Vce) of the pulldown transistor, and the source (emitter) of this transistor is tied to ground. However, in ECL type outputs the output voltage in the logic low state is determined by the voltage at the base of the output emitter follower, and this voltage is with respect to VCC, not GND. As a specific example, it does not matter whether VCC is defined as 0v or 5v, the output voltage of an ECL gate in the low state is always going to be about 1.7v below the VCC supply. By the same reasoning, a shift in VCC with respect to the other supply will not change the logic low output voltage of a totem-pole output but it will change the logic low level of an ECL type output. Because the simulator cannot, apriori, determine the proper output model (totem-pole or ECL) some indication of the output type is required. One could argue that the simulator could inspect the data in both tables and assume that if the range was 0 to -2.5 it was dealing with an ECL type output, however, I don't believe this is (a) reliable (can we GUARANTEE that no other device will be specified with those voltage ranges) and (b) the IBIS specification should place specific implementation requirements on a simulator. Therefore, the easiest and most reliable way to explicitly specify the output type is with the Model_type sub-parameter. (2) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. Note also that there are no gnd or power clamp diodes on ECL outputs (or inputs for that matter) and so those are 'don't care' issues. (3) The third proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* Text item: abird5_2.txt 1/27/94 10:09P ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.2 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: December 6, 1993 DATE REVISED: December 17, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: January 7, 1994 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NC. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. Bird 5.2 has been issued in response to comments from the Forum members over the use of the term "NA" in Bird to indicate the lack of a connection. NA = "not available," which would have caused confusion. This version of the Bird has been updated to use "NC" (= "no connection") instead. Otherrwise, there are no changes from Bird 5.1. ****************************************************************************** Text item: abird4_0.txt 1/27/94 10:22P ****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 4.0 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: November 5, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are two in number: (1) Lessening the required voltage range over which an ECL output is characterized. (2) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to relax (decrease) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Secondly, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: (1) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. (3) The second proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** Text item: abird3_0.txt 1/27/94 10:42P ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 3.0 ISSUE TITLE: Multiple Power Supplies and References REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: November 4, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993 ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: The IBIS specification currently does not address devices that use more than one supply, or devices in which the pullups, pulldowns, power_clamp or gnd_clamp diodes are referenced to voltages other than that specified by the [Voltage range] keyword. This BIRD proposes a general way in which both multiple power supplies can be defined and V/I curve can be referenced to specific supplies. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The specific change involves adding four new keywords: [Pullup reference], [Pulldown reference], [POWER_clamp reference] and [GND_clamp reference]. These keywords are defined as shown below. The following text replaces the current text for the [Voltage range] keyword. |========================================================================== | Keyword: [Voltage range] | Required: Yes |Description: Used to define the power supply voltage tolerance over which | the the model is intended to operate. It also specifies the | default voltage rail the pullup and POWER_clamp V/I data is | referenced to. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |--------------------------------------------------------------------------- | variable typ min max [Voltage range] 5.0v 4.5v 5.5v |=========================================================================== | Keyword: [Pullup reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the pullup V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [Pulldown reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the pulldown V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown reference] 0V 0V 0V |=========================================================================== | Keyword: [POWER_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the POWER_clamp V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |--------------------------------------------------------------------------- | variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [GND_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the GND_clamp V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section | below. |--------------------------------------------------------------------------- | variable typ min max [GND_clamp reference] 0V 0V 0V |============================================================================ | NOTES ON SPECIFYING POWER SUPPLIES | It is the intention that standard TTL and CMOS devices be specified | using only the [Voltage range] keyword. However, in cases where | the output characteristics of a device depend on more than a single | supply and ground, or a pullup, pulldown or clamp structure is referenced | to something other than the default supplys, the additional 'reference' | keywords are to be used. | | If the [Voltage range] keyword is not present then all four of the | other keywords must be present. If the [Voltage range] keyword is | present the other keywords are optional and may or may not be used as | required. It is legal (although redundant) for an optional keyword to | specify the same voltage as specified by the [Voltage range] keyword. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Most of the above is fairly self-explanatory. The key here is to realize that the four 'reference' keywords, in effect, create separate power supply rails that override the default [Voltage range] supply. The intention was to create a very general and flexible way to handle multiple supply devices and ECL. To illustrate with some examples: 1. An RS23 line driver has a +/- 12V output swing. One way to specify this device is shown below typ min max [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and | POWER_clamp ref [Pulldown reference] -12.0V -12.5V -11.5V | fixes pulldown ref [GND_clamp reference] -12.0V -12.5v -11.5V | fixes GND_clamp ref Optionally, the [Voltage range] keyword could be replaced with the [Pullup reference] and [POWER_clamp] reference. 2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for it's internal logic. The power clamp diodes are referenced to the 5V supply. Their are two equally valid ways this device can be specified. typ min max [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp | reference typ min max [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and | POWER_clamp reference [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage | range] specification | on the pullup 3. When specifying a device with an ECL type output structure, the pulldown curves must be referenced to the most positive supply (the same one that the pullup curves are referenced to). The easiest way to do this is define the value of the [Voltage range] as 0v. Both the pullup AND pulldown V/I curves will be referenced to 0v (remember, the pulldown defaults to 0v). typ min max [Voltage range] 0V 0V 0V | VCC supply [Pulldown reference] 0V 0V 0V | not really | required, its | specified for | completeness [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Alternately, one could specify the VEE supply and then override the default values of the pullup and pulldown references typ min max [Voltage range] -4.5V -4.0V -5.5v | VEE supply [Pullup reference] 0v 0v 0V [Pulldown reference] 0v 0v 0v [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Finally, to specify ECL logic that is used with a +5V supply (positive ECL) one can do the following: typ min max [Voltage range] 5.0V 4.5V 5.5V | VCC supply [Pulldown reference] 5.0V 4.5V 5.5V | override default The default references are used for the pullup and GND_clamp V/I curves. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:43:07 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29083; Wed, 2 Feb 94 23:43:07 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRygt-000MNOC; Wed, 2 Feb 94 23:41 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyjL-0000YSC; Wed, 2 Feb 94 23:44 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 23:44:03 PST Date: Wed, 2 Feb 94 23:44:03 PST From: Derrick Duehren Message-Id: <940202234403_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS approved BIRD 3.0 and template Text item: Text_1 Let's try this again...in smaller chunks. This is approved BIRD 3.0 and the BIRDS.TXT instructions/template file. >Attached are all of the cleaned up BIRD files as of 2/2/94. (They should end >up concatenated below. These will also be posted to vhdl.org as soon as I >figure out how to get them there.) I have cleaned up formatting >inconsistencies and problems (such as converting tabs to spaces). I have named >the files with p (new/pending), a (approved), and d (dead) prefixes (such as >abird3_0.txt, for approved BIRD 3.0). - Derrick Duehren ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ birds.txt ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ BIRD filename convention: pbirdn_n.txt new/pending abirdn_n.txt approved dbirdn_n.txt dead -------------------------------------------------------------------------------- Howdy, 9/15/93 The following is your key to getting issues resolved in the IBIS Open Forum. It's called a "Buffer Issue Resolution Document" or "BIRD". Issues must be well thought out and clearly documented using this template to be placed on the agenda of a future IBIS Open Forum. Here's how the process works. Write up your issue and submit it to Will. Will's group will do a preliminary check for completeness and (potentially) send your BIRD back to you. If not, Will will post the issue to the reflector. Each issue must be out for review for two weeks before the Open Forum will vote on it. During that time, you will be expected to answer questions related to your BIRD. In each meeting announcement, Will will list those BIRDs that are ready for a vote at that meeting. A BIRD will be accepted if EVERYONE at the meeting agrees with it. Please note that Open Forum time will not be used for detailed BIRD review, but rather for confirming consensus. Detailed review MUST ensue during the two-week review cycle via emails. Dissenters should not wait until the Open Forum to express their opinions. So far the group has been exceedingly cooperative, achieving a 1.0 spec in only a couple of months. Hopefully this process will allow us to use time more efficiently, while maintaining the same flavor in the larger group setting. Regards, Don Telian NOTE: All text in french brackets is for explanation only and should be deleted. ---------------------------- cut here ----------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: {don't fill in, will be filled in by Will Hobbs for tracking} ISSUE TITLE: {one line description of your issue} REQUESTOR: {your name and company} DATE SUBMITTED: {date you sent to Will} DATE REVISED: {revision date} DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: {Place a short description of your issue here. People should be able tell by reading this if they care about this in less than 1 minute.} ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: {For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a future IBIS specification. If this is a change, state the old text and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give intended location in the specification.} ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: {There are many "experts" reviewing this document. Your reasons, analysis, and justifications must be precise and well documented, or your BIRD will be sent back to you. Use this section to show that you've done your homework, and answer all questions that will undoubtedly be asked. If your issue is a change instead of an enhancement, document how backward compatibility is to be addressed.} ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ******************************************************************************* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ abird3_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 3.0 ISSUE TITLE: Multiple Power Supplies and References REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: November 4, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993 ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: The IBIS specification currently does not address devices that use more than one supply, or devices in which the pullups, pulldowns, power_clamp or gnd_clamp diodes are referenced to voltages other than that specified by the [Voltage range] keyword. This BIRD proposes a general way in which both multiple power supplies can be defined and V/I curve can be referenced to specific supplies. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The specific change involves adding four new keywords: [Pullup reference], [Pulldown reference], [POWER_clamp reference] and [GND_clamp reference]. These keywords are defined as shown below. The following text replaces the current text for the [Voltage range] keyword. |========================================================================== | Keyword: [Voltage range] | Required: Yes |Description: Used to define the power supply voltage tolerance over which | the the model is intended to operate. It also specifies the | default voltage rail the pullup and POWER_clamp V/I data is | referenced to. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |--------------------------------------------------------------------------- | variable typ min max [Voltage range] 5.0v 4.5v 5.5v |=========================================================================== | Keyword: [Pullup reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the pullup V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [Pulldown reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the pulldown V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown reference] 0V 0V 0V |=========================================================================== | Keyword: [POWER_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the POWER_clamp V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |--------------------------------------------------------------------------- | variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [GND_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the GND_clamp V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section | below. |--------------------------------------------------------------------------- | variable typ min max [GND_clamp reference] 0V 0V 0V |============================================================================ | NOTES ON SPECIFYING POWER SUPPLIES | It is the intention that standard TTL and CMOS devices be specified | using only the [Voltage range] keyword. However, in cases where | the output characteristics of a device depend on more than a single | supply and ground, or a pullup, pulldown or clamp structure is referenced | to something other than the default supplys, the additional 'reference' | keywords are to be used. | | If the [Voltage range] keyword is not present then all four of the | other keywords must be present. If the [Voltage range] keyword is | present the other keywords are optional and may or may not be used as | required. It is legal (although redundant) for an optional keyword to | specify the same voltage as specified by the [Voltage range] keyword. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Most of the above is fairly self-explanatory. The key here is to realize that the four 'reference' keywords, in effect, create separate power supply rails that override the default [Voltage range] supply. The intention was to create a very general and flexible way to handle multiple supply devices and ECL. To illustrate with some examples: 1. An RS23 line driver has a +/- 12V output swing. One way to specify this device is shown below typ min max [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and | POWER_clamp ref [Pulldown reference] -12.0V -12.5V -11.5V | fixes pulldown ref [GND_clamp reference] -12.0V -12.5v -11.5V | fixes GND_clamp ref Optionally, the [Voltage range] keyword could be replaced with the [Pullup reference] and [POWER_clamp] reference. 2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for it's internal logic. The power clamp diodes are referenced to the 5V supply. Their are two equally valid ways this device can be specified. typ min max [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp | reference typ min max [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and | POWER_clamp reference [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage | range] specification | on the pullup 3. When specifying a device with an ECL type output structure, the pulldown curves must be referenced to the most positive supply (the same one that the pullup curves are referenced to). The easiest way to do this is define the value of the [Voltage range] as 0v. Both the pullup AND pulldown V/I curves will be referenced to 0v (remember, the pulldown defaults to 0v). typ min max [Voltage range] 0V 0V 0V | VCC supply [Pulldown reference] 0V 0V 0V | not really | required, its | specified for | completeness [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Alternately, one could specify the VEE supply and then override the default values of the pullup and pulldown references typ min max [Voltage range] -4.5V -4.0V -5.5v | VEE supply [Pullup reference] 0v 0v 0V [Pulldown reference] 0v 0v 0v [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Finally, to specify ECL logic that is used with a +5V supply (positive ECL) one can do the following: typ min max [Voltage range] 5.0V 4.5V 5.5V | VCC supply [Pulldown reference] 5.0V 4.5V 5.5V | override default The default references are used for the pullup and GND_clamp V/I curves. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:48:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29146; Wed, 2 Feb 94 23:48:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRyli-000MNOC; Wed, 2 Feb 94 23:46 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyo9-0000PhC; Wed, 2 Feb 94 23:49 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 23:49:01 PST Date: Wed, 2 Feb 94 23:49:01 PST From: Derrick Duehren Message-Id: <940202234901_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Approved BIRDs 4.0 and 5.2 Text item: Text_1 Following are approved BIRDs 4.0 and 5.2. - Derrick Duehren ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ abird4_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 4.0 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: November 5, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are two in number: (1) Lessening the required voltage range over which an ECL output is characterized. (2) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to relax (decrease) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Secondly, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: (1) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. (3) The second proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ abird5_2.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.2 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: December 6, 1993 DATE REVISED: December 17, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: January 7, 1994 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NC. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. Bird 5.2 has been issued in response to comments from the Forum members over the use of the term "NA" in Bird to indicate the lack of a connection. NA = "not available," which would have caused confusion. This version of the Bird has been updated to use "NC" (= "no connection") instead. Otherrwise, there are no changes from Bird 5.1. ****************************************************************************** From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:53:07 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29161; Wed, 2 Feb 94 23:53:07 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRyqa-000MNOC; Wed, 2 Feb 94 23:51 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyt0-0000aEC; Wed, 2 Feb 94 23:54 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 2 Feb 94 23:54:02 PST Date: Wed, 2 Feb 94 23:54:02 PST From: Derrick Duehren Message-Id: <940202235402_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Pending BIRDs 2.0 and 6.1 Text item: Text_1 Following are pending BIRDs 2.0 and 6.1. - Derrick Duehren ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ pbird2_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 2.0 ISSUE TITLE: Requiring VIH VIL Thresholds for Input Devices REQUESTOR: Jon Powell, Quad Desgin DATE SUBMITTED: October 4, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: {likely to be superceeded} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The V1.1 IBIS specification does not require the presence of input thresholds on input devices. This allows data-generators to omit thresholds and still create "IBIS LEGAL" models. Input devices with no stated digital logic input thresholds would only be usefull if the inputs were totaly analog devices (a condition that is not in the main-stream of IBIS targetted devices). Requiring a low and high threshold for all input devices is therefor a reasonable requirement that adds information without creating undo restrictions. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: No new keywords are required. The following text to be added to the Other Notes section of the [Model] keyword description: The sub-parameters Vinl and Vinh are required for Model_types of: "Input" and "I/O". Omission of Vinl or Vinh for these devices will cause a parser error. Any other device type that contains a Vinl or Vinh parameter will cause a parser warning. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: There are devices that are not Input or Outputs and are not handled by our current set of model types. For instance: Termination Resistor Packs Termination Diode Packs Descrete 2 port devices I believe that more change is needed in this particular area but that that change is large enough that we should discuss it at our meeting as opposed to random email messages. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ****************************************************************************** ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ pbird6_1.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 6.1 ISSUE TITLE: Differential Pin Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: January 12, 1994 DATE REVISED: January 29, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Several components contain pins which operate in a differential mode with respect to other pins. Since this operation in inherent to a component, the IBIS document should be extended to specify this functionality. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional optional keyword, [Diff_Pin], is added to the specification. |============================================================================== | Keyword: [Diff_Pin] | Required: Optional |Description: Used to associate differential pins, their peak-to-peak | differential voltages and timing skews. | Sub-Params: inv_pin, vdiff, tskew_typ, tskew_min, tskew_max |Usage Rules: Entries follow these rules: Only differential pin pairs | are entered. The [Diff_pin] column contains a non-inverting | pin number and the inv_pin column always contains the | corresponding inverting pin number for output and I/O output. | The vdiff column contains the specified peak-to-peak voltage | between pins if the pins are Input or I/O Model_types. | For Output only differential pins, the vdiff entry is 0V. |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff_pin] column will be Non-Inverting and the pin in the | inv_pin column will be Inverting. This convention allows | one [Model] to be used for both pins. | | Column length limits are: | [Diff_Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tskew_typ 9 characters max | tskew_min 9 characters max | tskew_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tskew_typ or tskew_min columns, its | entry will be interpreted as 0V or 0ns. If "NA" appears in | the tskew_max column, its value will be interpreted as the | tskew_typ value. When using six columns, the headers | tskew_min and tskew_max must be listed. |------------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tskew_typ tskew_min tskew_max | 3 4 150mV 1ns 0ns 2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tskew = 0ns 22 21 NA NA | Output*, tskew = 0ns | * Could be Input or I/O with vdiff = 0V ******************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins that provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have a differential input sensitivity specification such as "Vpp" or "VT+" and "VT-" which defines a peak-to-peak voltage between two input pins. The vdiff column is introduced for such specification limits (as a positive value) which would trigger an output transition. One application is for timing analysis. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | | |<-- tmax -->| | | |<-- tmin ->|| __________ || ____________ __ \ || / A0 __\||/__ \/ vdiff DIFFERENTIAL INPUT __ /\ __ / \ __________/ \____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. Tskew can be shown per National Interface Databook, diagram on pg 1-121: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ \ / \ / ^ D0 | Vo/2 \ / \/ Vo/2 Vo v______\ /__ __|/\|_____v DIFFERENTIAL OUTPUT |\/| / \ | |/\| /| |\ v____________/ \__________/ | | \_______ D0 | | | | | | Tskew | | Tskew Tskew = |tPLH - tPHL| Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ******************************************************************************** ANY OTHER BACKGROUND INFORMATION: Introducing a [Tskew] keyword similar to [Package] (used for defaults) was suggested and could be considered as another method for dealing with skew. An alternative polarity mechanism for differential outputs could have been based on the Polarity sub-parameter within the [Model]. This was not done because Polarity is optional and also because two [Model]s would be required: one for the "Non-inverting" pin and another for the "Inverting" pin. In BIRD6.1, vdiff is used as an absolute difference regardless of polarity for Input specfication, so "polarity" no longer is applicable for inputs. However, it still may be reasonable to require two Output or I/O [Model]s for easier translation into simulator databases. In this case, the "inv_pin" name could be changed to "2nd_pin". Also, with a Polarity sub-parameter, the possibility exists that the [Models] are in phase with each other. This may be useful for double strength buffer options. ******************************************************************************* From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:59:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29185; Wed, 2 Feb 94 23:59:18 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRywT-000MNOC; Wed, 2 Feb 94 23:57 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyyu-0001CiC; Thu, 3 Feb 94 00:00 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 3 Feb 94 00:00:08 PST Date: Thu, 3 Feb 94 00:00:08 PST From: Derrick Duehren Message-Id: <940203000008_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Pending BIRD 7.2 Text item: Text_1 Following are pending BIRDs 7.2 and 8.0, and dead BIRD 1.0. - Derrick Duehren ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ pbird7_2.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 7.2 ISSUE TITLE: Open Specification Completion REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: January 13, 1994 DATE REVISED: January 31, 1994, February 1, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model_type "Open_drain" provides insufficient coverage for "open" sided models. For completeness, additional "open" Model_types are need. Also, necessary ECL related Model_types are added for clarity and to avoid several tests required before processing the [Model]. Methods to produce [Ramp] data need to be expanded for "open" devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Under the keyword [Model], additional Model_type selections are added: I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Output_ECL, I/O_ECL, Input_ECL. The [Model] keyword specification in Version 1.1 is edited to show these Model_types. Changed text is separated by blank lines. NOTES ON DATA DERIVATION METHODS is revised to clarify the [Ramp] measurements for open models. The [Model] keyword is revised to the following: |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, and I/O_ECL model must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names which use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Model_types with "open_sink" specify that the output has | an OPEN side (the [Pullup] keyword is not used or I = 0mA | for all voltages specified) AND the output SINKS current. | Model_types with "open_drain" have the identical meaning and | are retained for backward compatibility. Model_types with | "open_source" specify that the output has an OPEN side (the | [Pulldown keyword is not used or I = 0mA for all voltages | specified) AND the output SOURCES current. Model_types with | "_ECL" specify that the model represents and ECL type logic | which follows different conventions for the [Pulldown] keyword. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL | List one only Polarity Non-Inverting, Inverting | List one only, -if any Enable Active-High, Active-Low | List one only, -if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired Vinl = 0.8V | input logic "low" DC voltage, -if any Vinh = 2.0V | input logic "high" DC voltage, -if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |============================================================================== Section 3) on NOTES ON DATA DERIVATION METHOD is revised as follows: 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1. Start with the silicon model, remove all packaging. 2. If: The Model_type is one of the following: Output, I/O, or 3-state (not open or ECL types); Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. If: the Model_type is Output_ECL or I/O_ECL; Then: Attach a 50 ohm resistor to the termination voltage (Vterm = VCC - 2v). Use this load to derive both the rising and falling edges. If: The Model_type is either an open_sink type or open_drain type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The Model_type is an open_source type; Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 3. and 7.: **** Delete Items 3. and 7. **** 4. - 6.: **** Renumber these Items as 3. - 5. **** ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Open-drain is corrected to Open_drain as a Model_type selection and is kept for backward compatibility. I/O_open_drain is added. The new types with "open_sink" and "open_source" are added to generically describe an output with either an open [Pullup] or [Pulldown] and an output that sinks or sources current. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_Open_source no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. For the "open" Model_types there exists several other naming methods based on comments received and some combinations I though of. BIRD7.2 is written in terms of (0). (0) Retain "Open_drain" and add "I/O_open_drain" for Version 1.1 consistency. Add "open_sink" and "open_source" Model_types. (5 new terms, 2 redundant terms). no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_open_source (1) Use "up" and "down". Retain Open_drain for Version 1.1 compatibility as a redundant Model_type. (Bird7.1 - 4 new terms, 1 redundant term). no pullup: | Open_up I/O_Open_up | Open_drain no pulldown: | Open_down I/O_Open_down (2) Retain "Open_drain", but use "up" & "down" for generic names elsewhere. (3 new terms). no pullup: | Open_drain I/O_Open_up no pulldown: | Open_down I/O_Open_down (3) Use "drain", "collector", "emitter". "emitter is generic for CMOS logic & TTL no pulldown devices. (5 new terms). no pullup: | Open_drain I/O_Open_drain | Open_collector I/O_Open_collector no pulldown: | Open_emitter I/O_Open_emitter (4) Use "drain" generically for "up", and "source" generically for "down" for TTL and CMOS logic. (Bird7.0 - 3 new terms) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_source I/O_Open_source (5) Use "Open_drain" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (1 new term) no pullup: | Open_drain I/O_Open_drain no pulldown: | Open_drain I/O_Open_drain (6) Retain "Open_drain, but use "Open" generically to mean "Open". Test for no pullup or no pulldown in [Model]. (2 new terms) no pullup: | Open_drain I/O_Open no pulldown: | Open I/O_Open (7) Use "Open" generically to mean "Open". Retain "Open_drain" for Version 1.1 compatibility. Test for no pullup or no pulldown in [Model]. (2 new terms, 1 redundant term). no pullup: | Open I/O_Open | Open_drain no pulldown: | Open I/O_Open Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "open_sink" device. Omission of [Pulldown] could be interpreted as an "open_source" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink" or "open_drain" types. Zero valued [Pulldown] data corresponds to "open_source" types. Without the additional Model_types, the above two approaches plus the existance of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. One final consideration is that whoever generates the [Model], whether through simulation or measurement, must know beforehand the Model_type in order to generate the [Ramp] data according to the rules. Therefore it is reasonable to require that this information be included as part of a Version 2.0 specification. This avoids the inefficiency of forcing the simulator to perform many tests before processing the IBIS data. The simulator can then translate the data into its internal format and apply its own simulator- specific compaction schemes (the simulator does not have to provide all of the Model_types). With BIRD7.2, the IBIS Statement of Intent within the first paragraph is preserved: "the intention of this template is to specify a consistent format that can be parsed by software, allowing each simulation vendor to derive models compatible with their own product." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell initiated the issue in Email of October 1993 questioning whether we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the SN74ALS641 Open Collector Tranceiver as a specific example. Kellee Crisafulli in Email of July 1993 considered "open output devices (open-drain, open-collector, open-source)". Furthermore, he referred to "open collector npn" and "open collector pnp" devices. In the discussion, he proposed new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off time of high side driver) and dv/dt_f_off (turn off time of low side driver). Included it the discussion was the requirement that "If the pulldown table is missing then dV/dt_r_off is required" and "If the pullup table is missing then dV/dt_f_off is required". Kellee elaborated further on the measurement/extraction issues of the ramp values. BIRD7.1 now addresses the ramp specification. The modifications on Notes on Derivations Method by Kellee Crisafulli and Stephen Peters are added with changes for notation consistency. The usage of "Open_up" and "Open_down" is an adaptation of one of Arpad Muranyi's comments on BIRD7 suggesting "open pullup" and "open pulldown". Kellee Crisafulli's last suggestion on notation has been adopted in BIRD7.2. ****************************************************************************** From ccm!Derrick_Duehren@intelhf.intel.com Wed Feb 2 23:59:23 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29189; Wed, 2 Feb 94 23:59:23 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pRywa-000MNSC; Wed, 2 Feb 94 23:57 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pRyz1-0001CiC; Thu, 3 Feb 94 00:00 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 3 Feb 94 00:00:15 PST Date: Thu, 3 Feb 94 00:00:15 PST From: Derrick Duehren Message-Id: <940203000015_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Pending BIRD 8.0 and Dead 1.0 Text item: Text_1 Following is pending BIRD 8.0 and dead BIRD 1.0. - Derrick Duehren ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ pbird8_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.0 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. I searched all the IBIS minutes and found the following two IBIS minutes relating to montonicity: ------------------------------------------------------------------------------- From meeting Nov 5, 1993 We engaged in a discussion on monotonic behavior. There are two aspects -to be dealt with. 1) How should we deal with output buffers that exhibit non-monotonic behavior (and in what situations does this occur)? 2) Must data be entered in the IBIS file monotonically? 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ From the 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:' and continue for 4 lines. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All four columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. * At least one axis of the data (voltage or current) is -required * to be monotonic. For example if the voltage is monotonic and * increasing, each seqential voltage point must be larger than * the previous value. | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions and recorded the results of the summit. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The interest at the summit seemed to be to make the data more human readable. As the approach proposed at the summit doesn't seem to have any particular advantages to simulators. (Have I missed something?) The original intention I had was to require the data be monotonic on both axes. This would make it easy for all simulators to handle the data. If the data has multivalue points, i.e. it is multistable, it could be difficult to assure that all simulators can find a stable DC operating point, and that they always switch properly. We have modified how the HyperLynx simulator handles non-monotonic data to insure that this problem will not occur. Is this a problem for any of the other simulators like SPICE? On the other hand, at least one simulator company representative felt that it is imperative to allow non-monotonic data on one axis to properly represent the effects of some devices. The IBIS_CHK program must also be modified to test for this condition. ******************************************************************************** ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ dbird1_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 1.0 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: not recorded DATE ACCEPTED BY IBIS OPEN FORUM: {transmutted to BIRD 4.0} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are three in number: (1) Adding one more choice to the [Model] keyword sub-parameter 'Model_type' (2) Lessening the required voltage range over which an ECL output is characterized (3) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to add the choice of 'ECL' to the list of allowed choices for the 'Model_type' sub-parameter used with the [Model] keyword. This choice must be used when the device output being described has an ECL type output structure. Specifically, change the description of the [Model] keyword as follows: WAS: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain | List only one . . . PROPOSED: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, ECL | list only one . . . (2) The second change is to relax (decrease ) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Finally, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: In the following discussion I am assuming the reader understands the basic operation of an ECL logic gate and the emitter follower output structure. I am also defining VCC to be the most positive supply, while GND as the most negative supply. A "totem-pole" output is the standard type output structure with the source (emitter) of a pullup transistor connected to the drain (collector) of a pulldown transistor. (1) The purpose in requiring the user to specify 'ECL' in the Model_type sub-parameter is to give a simulator an explicit indication that the device being modeled has an ECL type output structure. As far as the IBIS spec is concerned, the fundamental difference between an ECL output and the standard totem-pole or open-drain/collector output is that, for ECL, data in the PULLDOWN table is referenced to VCC and changes in VCC effect the logic low voltage output level. This means when simulating an ECL output a simulator must construct a different model and make different assumptions regarding the output characteristics of the device. The following discussion explains these differences in more detail. Currently, voltage data points in the pulldown table are referenced to GND. This is because in a standard totem-pole type output the output voltage in the logic low state is determined by Vds (or Vce) of the pulldown transistor, and the source (emitter) of this transistor is tied to ground. However, in ECL type outputs the output voltage in the logic low state is determined by the voltage at the base of the output emitter follower, and this voltage is with respect to VCC, not GND. As a specific example, it does not matter whether VCC is defined as 0v or 5v, the output voltage of an ECL gate in the low state is always going to be about 1.7v below the VCC supply. By the same reasoning, a shift in VCC with respect to the other supply will not change the logic low output voltage of a totem-pole output but it will change the logic low level of an ECL type output. Because the simulator cannot, apriori, determine the proper output model (totem-pole or ECL) some indication of the output type is required. One could argue that the simulator could inspect the data in both tables and assume that if the range was 0 to -2.5 it was dealing with an ECL type output, however, I don't believe this is (a) reliable (can we GUARANTEE that no other device will be specified with those voltage ranges) and (b) the IBIS specification should place specific implementation requirements on a simulator. Therefore, the easiest and most reliable way to explicitly specify the output type is with the Model_type sub-parameter. (2) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. Note also that there are no gnd or power clamp diodes on ECL outputs (or inputs for that matter) and so those are 'don't care' issues. (3) The third proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From ccm!Will_Hobbs@intelhf.intel.com Thu Feb 3 10:58:15 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10942; Thu, 3 Feb 94 10:58:15 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pS9EF-000MNhC; Thu, 3 Feb 94 10:56 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pS9GY-0000PZC; Thu, 3 Feb 94 10:59 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 3 Feb 94 10:58:55 PST Date: Thu, 3 Feb 94 10:58:55 PST From: Will Hobbs Message-Id: <940203105855_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: TERMINATION, NEW BIRD 9 Hello IBIS members: Here is a cut at a "terminator" specification. This one is for a minimal extension using the existing IBIS components plus introducing two additional resistors [Rpower] and [Rgnd]. It does not introduce a "terminator" Model_type. Such an extension is an option, but it also may be related to pending BIRD2 regarding Vinl and Vinh. The resistor elements are desirable for efficiency. They are technically available using [Power_clamp] and [Gnd_clamp] structures. Simulators support resistor elements, and using them for analysis is much more efficient than using tabular data. Bob Ross, Interconnectix, Inc. ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 9 ISSUE TITLE: Terminator Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 2 February 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Terminators are used in design and can exist as packaged parts. Therefore they are candidates for IBIS modeling. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two additional keywords, [Rpower] and [Rgnd], are proposed to represent resistors connected to power (VCC) and ground (GND) or to the voltages based on the voltage reference rules in BIRD3 as they apply to [POWER_clamp] and [GND_clamp]. |============================================================================= | Keywords: [Rgnd], [Rpower] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and -the POWER pins, | respectively. | Usage Rules: For each of these sections the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All three columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum values are not available, the reserved word "NA" must be used indicating the R(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND_clamp reference] | voltages, if defined, apply to [Rgnd]. [POWER_clamp reference] | voltages, if defined, apply to [Rpower]. | Either or both [Rgnd] -and [Rpower] may be defined and may | co-exist with [GND_clamp], [POWER_clamp], [Pulldown], and | [Pullup] structures. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [Rgnd] 330Ohm 300Ohm 360Ohm [Rpower] 220Ohm 200Ohm NA |============================================================================== | The "Other Notes:" text within the [Model] Keyword description is changed | to include references to [Rpower] and [Rgnd]: | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], [Rgnd], [Rpower], | and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A set of terminator components is useful to be formatted using IBIS because they are found as packaged components. All of the options can support (typ), (min) and (max) specifications. (1) Parallel Resistor Termination: The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI Passive Bus Terminator series would be modeled with these elements. At least two other techniques could be used in IBIS Version 1.1. The [POWER_clamp] or [GND_clamp] tables could be used (with as few as two data points each) to represent resistors. Another method could be to use R_pkg (or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a very low impedance. Processing tabular data for these purposes would be less efficient and less obvious than working with resistive elements directly. The following terminators do not require extensions: (2) Diode Termination: Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode Bus-Termination Arrays can be modeled using existing [POWER_clamp] and [GND_clamp] structures. (3) Internal Series Resistance Terminations: R_pkg (or R_pin) can be used to model internal series terminations. An alternative would be to specify an internal [Rseries] component. (4) RC (or AC) Termination: R_pkg (or R_pin) and C_comp can provide RC terminations. An alternative would be to specify [Rac] connected to [Cac] components. Other passive networks including capacitive loads are already available through existing package and C_comp elements. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD partially addresses the issue related to BIRD2 regarding Termination Resistor Packs and Termination Diode Packs. It does not address Discrete two-port devices except through one partial solution with internal series terminators. The adoption of this BIRD would require some text changes in BIRD3 to reference the new keywords. ****************************************************************************** From bert@ibmoto.com Thu Feb 3 11:52:25 1994 Return-Path: Received: from apple.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11408; Thu, 3 Feb 94 11:52:25 PST Received: from [129.38.12.13] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA23747; Thu, 3 Feb 94 11:49:50 -0800 for ibis@vhdl.org Received: from lw.ibmoto.com by cerberus.ibmoto.com with SMTP id AA23846 (5.65c/IDA-1.5 for ); Thu, 3 Feb 1994 13:49:13 -0600 Received: by lw.ibmoto.com id AA22612 (5.65c/IDA-1.5); Thu, 3 Feb 1994 19:49:13 GMT Message-Id: <199402031949.AA22612@lw.ibmoto.com> To: ibis@vhdl.org Cc: bert@ibmoto.com Subject: IBIS questions and concerns Date: Thu, 03 Feb 94 13:49:13 -0600 From: Lynn Warriner...bert@ibmoto.com...512.795.7234 I am new to this forum and committee so please forgive my ignorance about the methodology of making inquires and perhaps about the subjects in this inquiry. If the information already exists please point me to it. *** Is there a "Standard Driver"? I have spoken with several people as to whether there is a standard driver topology for SPICE simulation of an IBIS data set. I would like to correlate my data in an IBIS based model of a complex circuit. I have been told -- well just copy this data set --------. That is not what I would call a quality answer. I have been told that voltage controlled current sources OR votage controlled resistors work. My thoughts are that current sources are better for bi-polar and resistors are better for CMOS. So, am I barking up the wrong tree? Has everyone settled this one, and I am just the new kid on the block? *** Quality of support? Some tools vendors implement IBIS in mathematical form, some vendors use electrical models. With all this variability how do I know that an IBIS table is going to give me the same results on different tools? This is not, "its the customer's problem" situation. With many dollars to loose for my customer -- and then for me, I need to know that there are some quality standards. Does the IBIS community monitor itself? Is there a published table of tool tolerances? Do the customer's really care? Do other silicon houses really care? *** Drive for "true" standardization? Is anyone interested in making this an industry standard, say, through Semitec or IEEE? I know that this will require a lot of contraints, but then that is what a "standard" implies. From ccm!Derrick_Duehren@intelhf.intel.com Thu Feb 3 18:06:39 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14421; Thu, 3 Feb 94 18:06:39 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pSFul-000MP3C; Thu, 3 Feb 94 18:04 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pSFxK-0000eaC; Thu, 3 Feb 94 18:07 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 3 Feb 94 18:07:38 PST Date: Thu, 3 Feb 94 18:07:38 PST From: Derrick Duehren Message-Id: <940203180738_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Pending BIRD 9.0 (cleaned up) Text item: Text_1 ******************************************************************************** ******************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 9.0 ISSUE TITLE: Terminator Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: February 2, 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************** ******************************************************************************** STATEMENT OF THE ISSUE: Terminators are used in design and can exist as packaged parts. Therefore they are candidates for IBIS modeling. ******************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two additional keywords, [Rpower] and [Rgnd], are proposed to represent resistors connected to power (VCC) and ground (GND) or to the voltages based on the voltage reference rules in BIRD 3.x as they apply to [POWER_clamp] and [GND_clamp]. |============================================================================= | Keywords: [Rgnd], [Rpower] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively. | Usage Rules: For each of these sections, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All three columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum values are not available, the reserved word | "NA" must be used indicating the R(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND_clamp reference] | voltages, if defined, apply to [Rgnd]. [POWER_clamp reference] | voltages, if defined, apply to [Rpower]. | Either or both [Rgnd] -and [Rpower] may be defined and may | co-exist with [GND_clamp], [POWER_clamp], [Pulldown], and | [Pullup] structures. |------------------------------------------------------------------------------- | variable R(typ) R(min) R(max) [Rgnd] 330Ohm 300Ohm 360Ohm [Rpower] 220Ohm 200Ohm NA |=============================================================================== | The "Other Notes:" text within the [Model] Keyword description is changed | to include references to [Rpower] and [Rgnd]: | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], [Rgnd], [Rpower], and [Ramp]. However, some | models may have only a subset these keywords. For example, an | input structure normally only needs the [Voltage range], | [GND_clamp], and possibly the [POWER_clamp] keywords. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------- ******************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A set of terminator components is useful to be formatted using IBIS because they are found as packaged components. All of the options can support (typ), (min) and (max) specifications. (1) Parallel Resistor Termination: The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd, or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI Passive Bus Terminator series would be modeled with these elements. At least two other techniques could be used in IBIS Version 1.1. The [POWER_clamp] or [GND_clamp] tables could be used (with as few as two data points each) to represent resistors. Another method could be to use R_pkg (or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a very low impedance. Processing tabular data for these purposes would be less efficient and less obvious than working with resistive elements directly. The following terminators do not require extensions: (2) Diode Termination: Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode Bus-Termination Arrays can be modeled using existing [POWER_clamp] and [GND_clamp] structures. (3) Internal Series Resistance Terminations: R_pkg (or R_pin) can be used to model internal series terminations. An alternative would be to specify an internal [Rseries] component. (4) RC (or AC) Termination: R_pkg (or R_pin) and C_comp can provide RC terminations. An alternative would be to specify [Rac] connected to [Cac] components. Other passive networks including capacitive loads are already available through existing package and C_comp elements. ******************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD partially addresses the issue related to BIRD 2.x regarding Termination Resistor Packs and Termination Diode Packs. It does not address Discrete two-port devices except through one partial solution with internal series terminators. The adoption of this BIRD would require some text changes in BIRD 3.x to reference the new keywords. ******************************************************************************** From 71436.1314@CompuServe.COM Thu Feb 3 21:21:16 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15782; Thu, 3 Feb 94 21:21:16 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id AAA23648; Fri, 4 Feb 1994 00:19:38 -0500 Date: 04 Feb 94 00:15:42 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Response to Lynn from Kellee@HyperLynx Message-Id: <940204051541_71436.1314_HHB31-1@CompuServe.COM> Subject: IBIS questions and concerns Date: Thu, 03 Feb 94 13:49:13 -0600 From: "Lynn Warriner...bert@ibmoto.com...512.795.7234" Q1) Is there a "Standard Driver"? A1) Yes! It was created by Arpad at Intel. And it addresses most of your concerns quite nicely. It has been brought up more than once that this spice model should be available as part of the IBIS specification. It sounds like a good BIRD. Are you or Arpad interested in putting up the BIRD? Arpad has done alot of work to create a great start on a universal simulation model. It is a continuously evolving tool and most of the simulation vendors have their own methods. We went through a comparision phase when IBIS was first started to insure all the vendors simulations compared accurately. Intel was unbiased the judge for the first validation suite. Note: The original version of the IBIS spice model created by Arpad did not completely address open-side issues. Q2) Am I just the new kid on the block? A2) Mostly yes, but we love new kids that bring ideas! Q3) Does the IBIS community monitor itself? Is there a published table of tool tolerances? Do the customer's really care? Do other silicon houses really care? A3) Yes, No, ?, ? Q4)*** Drive for "true" standardization? A4) This was originally discussed, and we decided it was important to get IBIS off the ground and bypass the usually 2-3 years IEEE quoted as "standard" for the first release of this type of specification. It seems reasonable to evolved IBIS into a standard IEEE/VHDL/ etc .. IBIS is an evolving standard, built from a loose coupling of companies sharing a enough common interests to make it happen. Greetings Lynn, by the way "new kids" must submit at least one IBIS yoke. Some of us are prone to abuse the IBIS language, birds, eggs, yokes, etc.... Have a great day! Kellee Crisafulli, HyperLynx From bob@icx.com Thu Feb 3 22:16:00 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16186; Thu, 3 Feb 94 22:16:00 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12519 for ; Fri, 4 Feb 94 01:08:28 -0500 Date: Thu, 3 Feb 94 18:46:35 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03043; Thu, 3 Feb 94 18:46:35 PST Message-Id: <9402040246.AA03043@icx.com> To: ibis@vhdl.org Subject: BIRD8 To IBIS members and Kellee: (This is a test to see if I get a response before I come in tommorrow) I generally agree with your BIRD8. I would prefer just to specify only the voltage table as monotonic. Is there any specific situation where it is advantageous to have the current monotonic and the voltage non- monotonic? Bob Ross Interconnectix, Inc. From bob@icx.com Thu Feb 3 22:26:09 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16234; Thu, 3 Feb 94 22:26:09 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12472 for ; Fri, 4 Feb 94 01:08:05 -0500 Date: Thu, 3 Feb 94 18:04:49 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA02958; Thu, 3 Feb 94 18:04:49 PST Message-Id: <9402040204.AA02958@icx.com> To: ibis@vhdl.org Subject: RAMP NOTE COMMENT Dear IBIS folks: I enjoyed seeing your responses to the RAMP NOTE. My purpose for sending it out originally was for information only. The first tendency with a ramp rate expressed as dV/dt is to extrapolate the slope to full voltage swing values - but this is not consistent with actual device operation. The second tendency based on examples given is to assume the data is expressed as 100% ramp numbers. For example, dV/dt ramps for Pentium(TM) Processor User's Manual, Vol.2 pg. 8-3 go rail to rail for min and max voltages (dV = 4.5 and 5.5). The IBIS specification provides clear methodology to derive [Ramp] data and what it means. However, the example is somewhat misleading and needs to be fixed, expecially for dV/dt_r, since one would not expect 60% of the transition to cover 4.2, 3.5 and 5 volts for VCCs of 5, 4.5 and 5.5. So the voltages in the example should be adjusted downward. Current IBIS data in the Intel directory show lower voltage swings and could be the basis of a revised example in the Version 2.0 specification. Version 1.1 example - should be revised |----------------------------------------------------------------------- [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n |======================================================================= I favor keeping the 20%-80% method for compatibility. While 10%-90% is commonly used for validation of specifications, I think it is reasonable to use the reduced range for getting parameters for modeling. The other elements in the model should degrade the response slightly. Also, some ECL response specifications are based on 20%-80%. Finally, I would rather err on the side of being too fast. The [Ramp] data, as defined, should provide models which are reasonable and defendable. Eventually, the real issue is how to get a more accurate model. Discussions underway regarding V-I-T (3-D characterization), slew-rate controlled devices, packaging, and perhaps EMI issues are addressing portions of the problem. Full V-T time response data for the measurement conditions specified (50 Ohm loads) would be one way to accurately present the response to document its shape. But, this opens the door for some very complicated considerations such as: (1) Effect of the non-linear DC high state and low state output resistance on the response (probably less than expected) (2) Effect of the non-linear AC output impedance characteristics on the response (probably more that expected when using 50 ohm loads), but the only AC impedance parameters modeled are C_comp and the package paramaters. (3) For some devices, 50 Ohm load is appropriate; but for others, it may provide characterizations well out of the normal operating range. (On the other hand, some devices work well with 50 Ohm loads, and give much different responses with higher resistance loads.) (4) Pullup loads to 5V may be appropriate for CMOS logic. But for one TTL device I got significantly different results for dt_f when the load was connected to 5V versus 3.5V and 1.75V. This may be just one case, but the measurement methods may become more of a consideration to provide more accurate models for different technologies. Given all of the possible variables, I am not convinced that just modifying the [Ramp] specification in IBIS Version 1.1 will give better models. Bob Ross, Interconnectix, Inc. From qdt!sal!jonp@uunet.UU.NET Fri Feb 4 07:47:17 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25037; Fri, 4 Feb 94 07:47:17 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwbut05632; Fri, 4 Feb 94 10:45:36 -0500 Received: from qdt.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 104303.11714; Fri, 4 Feb 1994 10:43:03 EST Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00481; Fri, 4 Feb 94 07:35:28 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA12735; Fri, 4 Feb 94 07:35:28 PST Date: Fri, 4 Feb 94 07:35:28 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9402041535.AA12735@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA07101; Fri, 4 Feb 94 07:35:32 PST To: ibis@vhdl.org Subject: [uunet!CompuServe.COM!71436.1314: Response to Lynn from Kellee@HyperLynx] in response to: Return-Path: Date: 04 Feb 94 00:15:42 EST From: Kellee Crisafulli To: IBIS ALL Subject: Response to Lynn from Kellee@HyperLynx Subject: IBIS questions and concerns Date: Thu, 03 Feb 94 13:49:13 -0600 From: "Lynn Warriner...bert@ibmoto.com...512.795.7234" Q1) Is there a "Standard Driver"? A1) Yes! It was created by Arpad at Intel. And it addresses most of your concerns quite nicely. It has been brought up more than once that this spice model should be available as part of the IBIS specification. It sounds like a good BIRD. Are you or Arpad interested in putting up the BIRD? Arpad has done alot of work to create a great start on a universal simulation model. It is a continuously evolving tool and most of the simulation vendors have their own methods. We went through a comparision phase when IBIS was first started to insure all the vendors simulations compared accurately. Intel was unbiased the judge for the first validation suite. Note: The original version of the IBIS spice model created by Arpad did not completely address open-side issues. JNP: I disagree, I recall no discussion about a "Standard Driver" nor public agreement to abide by one. I have always considered comparison to physical measurement to be the only appropriate guide. jon powell quad design From ccm!Will_Hobbs@intelhf.intel.com Fri Feb 4 08:32:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25514; Fri, 4 Feb 94 08:32:10 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pSTQQ-000MNoC; Fri, 4 Feb 94 08:30 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pSTT4-0000ZYC; Fri, 4 Feb 94 08:33 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 4 Feb 94 08:33:17 PST Date: Fri, 4 Feb 94 08:33:17 PST From: Will Hobbs Message-Id: <940204083317_8@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, Derrick_Duehren@ccm.hf.intel.com, ibis@vhdl.org Subject: Pending BIRD 9.0 (cleaned up) Derrick, et al, For some bizarre reason, our mail program, cc:Mail, chooses to add carriage returns and dashes and generally mangles files. I always go through and clean them up before posting to the reflector. When it comes back from vhdl.org, the program does it again. I have assumed that it only happend to incoming mail and have dealt with it that way. I suspect this is happening to Derrick, too, since he is on the same mail program. But I may be wrong-- is the corruption happening on the way out, too, or are we at Intel just being penalized on incoming mail. In other words, did you, Derrick, clean up Bird 9 because of these extraneous incoming additions, courtesy of Lotus' cc:Mail, or did the mail get mangled going out? Did other members of the forum receive an un-mangled version from me, or did some lines look like the following: *************************************************************** - ** etc., etc.? I did notice that the word "pending" was put in in the filed of when accepted. Good change. Will From ccm!Will_Hobbs@intelhf.intel.com Fri Feb 4 08:33:23 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25523; Fri, 4 Feb 94 08:33:23 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pSTQO-000MO0C; Fri, 4 Feb 94 08:30 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pSTT2-0000fgC; Fri, 4 Feb 94 08:33 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 4 Feb 94 08:33:15 PST Date: Fri, 4 Feb 94 08:33:15 PST From: Will Hobbs Message-Id: <940204083315_7@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, ibis@vhdl.org, 71436.1314@CompuServe.COM Subject: Response to Lynn from Kellee@HyperLynx Kellee, Regarding your comment in your last mail, I think we need a bird on this one. Please don't try to duck the issue. The comment: Kellee: Greetings Lynn, by the way "new kids" must submit at least one IBIS yoke. Some of us are prone to abuse the IBIS language, birds, eggs, yokes, etc.... Will Hobbs Intel From ccm!Derrick_Duehren@intelhf.intel.com Fri Feb 4 09:12:07 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25738; Fri, 4 Feb 94 09:12:07 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pSU35-000MOhC; Fri, 4 Feb 94 09:10 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pSU5j-0000SLC; Fri, 4 Feb 94 09:13 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 4 Feb 94 09:13:15 PST Date: Fri, 4 Feb 94 09:13:15 PST From: Derrick Duehren Message-Id: <940204091315_7@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Subject: Re: Pending BIRD 9.0 (cleaned up) Will, et al, Besides cleaning up any screwy line returns, I've made all of the formatting as consistent as possible, used consistent date format, put in the appropriate phrase under the approved-date heading, and fixed any grievous grammar/spelling errors found. To verify that no tabs or non-spaced indentations exist, and to ensure no lines exceed 80 columns, I edit the BIRDs in Word for Windows using a nonproportional font, with all hidden codes enabled. I then save it as an ASCII file and recheck it in Norton Notepad (ASCII editor). - Derrick ______________________________ Reply Separator _________________________________ Subject: Pending BIRD 9.0 (cleaned up) Author: Will Hobbs at JFCCM2 Date: 2/4/94 8:06 AM Derrick, et al, For some bizarre reason, our mail program, cc:Mail, chooses to add carriage returns and dashes and generally mangles files. I always go through and clean them up before posting to the reflector. When it comes back from vhdl.org, the program does it again. I have assumed that it only happened to incoming mail and have dealt with it that way. I suspect this is happening to Derrick, too, since he is on the same mail program. But I may be wrong-- is the corruption happening on the way out, too, or are we at Intel just being penalized on incoming mail. In other words, did you, Derrick, clean up Bird 9 because of these extraneous incoming additions, courtesy of Lotus' cc:Mail, or did the mail get mangled going out? Did other members of the forum receive an un-mangled version from me, or did some lines look like the following: *************************************************************** - ** etc., etc.? I did notice that the word "pending" was put in the filed of when accepted. Good change. Will From bob@icx.com Sun Feb 6 02:26:10 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22594; Sun, 6 Feb 94 02:26:10 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04380 for ; Sun, 6 Feb 94 05:10:32 -0500 Date: Sat, 5 Feb 94 19:19:53 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA09321; Sat, 5 Feb 94 19:19:53 PST Message-Id: <9402060319.AA09321@icx.com> To: ibis@vhdl.org Subject: BIRD6.2 MIGRATION Hello IBIS members: Thank you for your responses on BIRD6.1. BIRD6.1 shifts to BIRD6.2 toward my understanding of a common position. Refer first to the ANY OTHER BACKGROUND INFORMATION section for change discussion. More comments are welcome. Changes: clarifications in "vdiff" definition and description "tskew" replaced by polarity sensitive "tdelay" Analysis Path text and diagram revisions Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 6.2 ISSUE TITLE: Differential Pin Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 12 January 1994 DATE REVISED: 29 January 1994, 5 February 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Several components contain pins which operate in a differential mode with respect to other pins. Since this operation in inherent to a component, the IBIS document should be extended to specify this functionality. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional optional keyword, [Diff_Pin], is added to the specification. |========================================================================== | Keyword: [Diff_Pin] | Required: Optional |Description: Used to associate differential pins, their differential | threshold voltages and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Entries follow these rules: Only differential pin pairs | are entered. The [Diff_pin] column contains a non-inverting | pin number and the inv_pin column always contains the | corresponding inverting pin number for output and I/O output. | The vdiff column contains the specified differential threshold | voltage between pins if the pins are Input or I/O Model_types. | For Output only differential pins, the vdiff entry is 0V. | The tdelay columns contain launch delays of the non-inverting | pins relative to the inverting pins. The values can be either | polarity. |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff_pin] column will be Non-Inverting and the pin in the | inv_pin column will be Inverting. This convention allows | one [Model] to be used for both pins. | | Column length limits are: | [Diff_Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ or tdelay_min columns, its | entry will be interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value will be interpreted as the | tdelay_typ value. When using six columns, the headers | tdelay_min and tdelay_max must be listed. Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff | regardless of its polarity is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins which provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have differential input sensitivity specifications such as "Vpp" or "VT+" and "VT-" which define the differential threshold voltages between two input pins. The vdiff column is introduced for such specification limits (the magnitudes used for both polarities) which would trigger an output change. Two switching cycles show that the actual switching can occur at either polarity vdiff relative to one pin (A0_bar). If the actual switching completes near tmax (the threshold past the cross-over), then the first switching completes when (A0 - A0_bar) is negative and the second when (A0 - A0_bar) is positive. One application of vdiff is for timing analysis bounds. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | __ | Polarities of vdiff relative to A0 signal show both |<-- tmax -->| polarities used to bound the transition region | | |<-- tmin ->|| (output = 0) (output = 1) __________ || ____________ _____________ \ || / \ / A0 __\||/__ __\ /__ + \/ - vdiff - \/ + DIFFERENTIAL INPUT __ /\ __ __ /\ __ / \ / \ __ __________/ \____________/ \_____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The Tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. tdelay may relate to Tskew values of unloaded outputs, but are considered separate in IBIS as a launch delay of the non-inverting output relative to the inverting output. tdelay can be either polarity. Tskew can be shown per National Interface Databook, diagram on pg 1-121 along with tdelay: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ |\ Tskew/ \ / ^ D0 | Vo/2 | \|<>|/ \/ Vo/2 Vo v__ | _\ /__ __|/\|_____v DIFFERENTIAL OUTPUT | \/ / \ | | /\ /| |\ v_________|__/ \__________/ | | \_______ D0 | | | | | | >| |< Tskew Tskew = |tPLH - tPHL| | | >| |< tdelay (positive value) Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Introducing a [Tskew] keyword similar to [Package] (used for defaults) was suggested and could be considered as another method for dealing with skew. (This would not apply for tdelay due to polarity convention.) An alternative polarity mechanism for differential outputs could have been based on the Polarity sub-parameter within the [Model]. This was not done because Polarity is optional and also because two [Model]s would be required: one for the "Non-inverting" pin and another for the "Inverting" pin. In BIRD6.1, vdiff is used as an absolute difference regardless of polarity for Input specfication, so "polarity" no longer is applicable for inputs. However, it still may be reasonable to require two Output or I/O [Model]s for easier translation into simulator databases. In this case, the "inv_pin" name could be changed to "2nd_pin". Also, with a Polarity sub-parameter, the possibility exists that the [Models] are in phase with each other. This may be useful for double strength buffer options. *** BIRD6.0 to BIRD6.1 Changes *** vpp renamed to vdiff, and polarity specification modified. tskew_typ, tskew_max, tskew_min columns added. Note regarding vinl and vinh removed since it was not relevant. Analysis Path text revised and expanded. Note on vdiff notation: Motorola uses Vpp in ECLinPS family TI uses VT+ and VT- in Data Transmission Circuits Family National uses VTH in Interface Databook *** BIRD6.1 to BIRD6.2 Changes *** On "vdiff", clarification and definition changes: As Syed Hug pointed out this parameter can be used as a (maximum) differential voltage threshold limit between two inputs, and to respond to Jon Powell's polarity question he gave an example of how this limit would be one polarity for the first transition, and the opposite polarity for the second transition (relative to one of the pins). Since neither Jon nor I have seen any example where the VT+ and VT- limits are of different magnitudes, the "vdiff" is specified by one value. I have taken the liberty to redefine the parameter in the text as "differential threshold voltage" to emphasize that it is a threshold limit voltage specification rather than an actual voltage. The diagram in the Analysis Path shows two cycles and the polarities of "vdiff". On "tskew", name and context change to "tdelay": My attempt to correlate "tskew" with anything published failed based on the comments from Bob Canright, Will Hobbs and Kellee Crisafulli. In fact data book "tskew" numbers would not be relevant for technical reasons including load, incomplete partioning of other parameters such as output capacitance, etc. The original intent of the parameter was to capture the "launch" time differences between the non-inverting and inverting outputs of differential pins. The term has been changed to "tdelay" to mean the delay of the non-inverting transition relative to the inverting transition. The delay can be + or -. If it is "+", then the non-inverting transition is launched at "tdelay" after the inverting transition starts. If the delay is "-", then the inverting transition is launched at |tdelay| after the non-inverting transition starts. The description and diagram have been modified to show this. Based on comments from Stephen Peters, the tdelay specification has to be one provided by the manufacturer. It could relate to internal transistor delays, packaging delays, etc. Thus, if the manufacturer provides a full package description showing different L_pin values, the tdelay entries might be 0ns. Alternatively, the tdelay entries may account for variations when only L_pkg is used. The manufacturer can provide entries of tdelay based on other known internal variations or variation limits. No action is taken regarding the parameters brought up by Stephen and Syed such as differential propagation delay and output-to-output skew. It is not clear that such information should fall within IBIS. ****************************************************************************** From bert@ibmoto.com Mon Feb 7 07:56:55 1994 Return-Path: Received: from apple.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07924; Mon, 7 Feb 94 07:56:55 PST Received: from [129.38.12.13] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA10655; Mon, 7 Feb 94 07:55:11 -0800 for ibis@vhdl.org Received: from lw.ibmoto.com by cerberus.ibmoto.com with SMTP id AA07897 (5.65c/IDA-1.5 for ); Mon, 7 Feb 1994 09:55:04 -0600 Received: by lw.ibmoto.com id AA18574 (5.65c/IDA-1.5); Mon, 7 Feb 1994 15:55:04 GMT Message-Id: <199402071555.AA18574@lw.ibmoto.com> To: ibis@vhdl.org Cc: bert@ibmoto.com Subject: typ, min, max condition specification Date: Mon, 07 Feb 94 09:55:04 -0600 From: Lynn Warriner...bert@ibmoto.com...512.795.7234 I have studied the IBIS OVerview, Version 1.0. I have the following questions concerning "typ", "min", and "max" conditions: 1) Are the specified temperatures the only ones that are allowable? Our parts are spec'd at 10C to 105C, should I then be using these numbers? Or, does some multidimensional curve fitting mandate certain limits? It looks to me that I should do my extractions at my real extremes -- right? 2) Relative to the process limits I assume that I chose my slowest process data for the "min" condition and the fastest process data for the "max" condition? Thanks ... From ccm!Will_Hobbs@intelhf.intel.com Mon Feb 7 08:18:35 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08200; Mon, 7 Feb 94 08:18:35 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pTYdt-000MOYC; Mon, 7 Feb 94 08:16 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pTYgu-0000S7C; Mon, 7 Feb 94 08:20 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 7 Feb 94 08:20:04 PST Date: Mon, 7 Feb 94 08:20:04 PST From: Will Hobbs Message-Id: <940207082004_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: mail failed, returning to sender This is a re-post. Our Mailer-Daemon said it didn't make it out of the system. Will IBIS members and onlookers, Derrick Duehren has submitted all birds past, present, pending, passed and passed away, to the vhdl.org BBS and Randy Harr has filed them in the "birds" directory in the IBIS area. Randy also passes on the following general instructions for people to get items off of the vhdl.org machine. Regards, Will Hobbs Accessing Documents and Literature on the VHDL International Users' Forum Standards Online Support system 24 August 1993, version 1.0 Many reference documents and related information are all available via the VHDL International Internet Repository. You can access and download the files in many different ways. Each is described further here. Email Access: ------------- There is an FTP archive server which is accessible via email. Send an email message to archive@vhdl.org. The subject is ignored. If a line in the body begins with the word "help", then a descriptive file of commands available is sent. Basically, you communicate with the server through commands in the body of your mail message. It then responds automatically and immediately to your request. (Note: immediate is relative to your connection mechanism to the Internet mail services.) You should always include the command: path in every request to assure the server knows where to send the message back to (otherwise it has to guess from the return path encoded in the mail message which does not always work) The following are a few examples of useful commands you could send in the body of your mail message. Each assumes you have requested to mail a message to archive@vhdl.org and included the path command in the body. To get help: help or to get this document: send docs pub.access.txt To get a listing of available files and directories for a given level: index vi/vital send vi/vital 00README To ask that a file be downloaded: send vi/vital email.archive As an example, for Joe Smith of XYZ (login name joes) to get the VITAL version 2.0 spec, he would send an email request to "archive@vhdl.org" with the following body: path joes@xyz.com send vi/vital vitalspec20.ps.Z Dial-Up Access: --------------- Dial-up to the vhdl.org system at 408.945.4170. Any baud (upto 14,400), parity, start & stop bits, and v.* settings will do. Login using the "guest" account. Once in, simple UNIX commands such as "cd vi/vital", "ls" and "cat 00README" are available. Also, you can download desired files using "kermit", "zmodem" or "sz" (zmodem). Internet Access: ---------------- Use "ftp vhdl.org" (or "ftp 198.31.14.3") and login as user "anonymous". Look in to "vi/vital". Also, gopher is available and highly recommended if you have it available. Gopher to "vhdl.org". Remember to set "binary" mode for any binary files (*.doc, *.fm, *.xls) you may elect to receive. In general, most documents are available in source (binary) form (such as WORD, EXCEL or FrameMaker formats), in an ASCII exchange format (such as RTF, SyLK, and MIF; respectively), and in postscript form ready to be sent to your printer directly. The file size increases accordingly as you move away from the source form. If you have any problems, send an email to support@vhdl.org. docs/pub.access.txt From ccm!Will_Hobbs@intelhf.intel.com Mon Feb 7 13:38:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11490; Mon, 7 Feb 94 13:38:18 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pTdcn-000MO0C; Mon, 7 Feb 94 13:36 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pTdfp-0000DnC; Mon, 7 Feb 94 13:39 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 7 Feb 94 13:39:17 PST Date: Mon, 7 Feb 94 13:39:17 PST From: Will Hobbs Message-Id: <940207133917_7@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, qdt!sal!jonp@uunet.UU.NET, ibis@vhdl.org Subject: Re: Standard circuit, validation of EDA "IBIS-capability" Jon, et al, This is a good topic. Arpad's circuit is a suggested implementation, but as Jon points out, is not the only one possible. If, as in Jon's case, an EDA vendor feels they can achieve better results with a different circuit that employs the same data, then the vendor is free to do so. Which brings up the question, how does anyone know if the results are trustworthy? As someone pointed out already, Intel has seen the results of a standard PCI driver simulation into the three load topologies, as outlined in the Overview Document. We have seen extraordinary agreement in all but one case. This work was done by Don Telian's group last summer and others have joined the forum since then. I personally cannot volunteer my group to be the validator of each EDA tool, and I doubt if Don would like to volunteer his group to be independent validator. On the other hand, the data we were using for the initial test is still valid and a good sanity check. Maybe we can get some neutral third party to act as quality checker(?). Does anyone have any ideas on how we can approach this problem? The alternative is that Intel has its list of vendors we know is "IBIS-capable" and TI, NSC, IBM, DEC, etc., generate their own list independently. That seems wasteful. Will in response to: Q1) Is there a "Standard Driver"? A1) Yes! It was created by Arpad at Intel. And it addresses most of your concerns quite nicely. It has been brought up more than once that this spice model should be available as part of the IBIS specification. It sounds like a good BIRD. Are you or Arpad interested in putting up the BIRD? Arpad has done alot of work to create a great start on -a universal simulation model. It is a continuously evolving tool and most of -the simulation vendors have their own methods. We went through a comparision phase when IBIS was first started to insure all the vendors simulations compared -accurately. Intel was unbiased the judge for the first validation suite. Note: -The original version of the IBIS spice model created by Arpad did not completely -address open-side issues. JNP: I disagree, I recall no discussion about a "Standard Driver" nor -public agreement to abide by one. I have always considered comparison to physical measurement -to be the only appropriate guide. jon powell quad design From bracken@valhalla.performance.com Mon Feb 7 14:37:58 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12194; Mon, 7 Feb 94 14:37:58 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA16647; Mon, 7 Feb 94 17:38:06 EST Message-Id: <9402072238.AA16647@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: EGG 1.0 (Package models) Date: Mon, 07 Feb 94 17:38:05 -0500 From: bracken@valhalla.performance.com All, During the last meeting, a number of good ideas were offered for a package model specification. I'll try to summarize what I heard; if I forgot something, or if anyone wants to add anything or discuss this some more, please speak up! --Eric Bracken (bracken@performance.com) Package Model Desiderata: ------------------------ 1) Re-usability: several different parts may be shipped in the same "package". In this case it's desirable not to have to repeat the package information in every IBIS file (especially not if that information takes up a lot of space...) This argues for a special [Package_Model_File] keyword in the IBIS deck which is used to indicate the name of a separate file containing the package model. One thought is to give these files the extension ".pkg". The only problem here, as someone pointed out, is how to ensure that all of the necessary files get transmitted to the user. ('tar' and 'pkzip' seem like good solutions...) 2) Support for Several Incarnations of the Same Part: A single IC may also be shipped in several DIFFERENT packages. Again, it seems like a good idea to have separate .pkg files so that IBIS "components" with the same nonlinear characteristics can reference different pkg models. One question here is whether or not the NONLINEAR part of the model has to be duplicated. I think the answer is "no", since the IBIS "models" are global to an entire file. If all of the various versions of the same part are described in the same IBIS file, then the I-V models only need to be specified ONCE, and then re-used by several different "components". Anybody know how practical this would be? For instance, would the tendency be for the IC vendor to ship an IBIS file containing the SMT, Plastic PGA, and Ceramic PGA versions of the Frotz-9000 CPU, or would they be more likely to ship out one library for all their surface-mount IC's, and another for all the DIP/PGAs, etc.? 3) Completeness: it may be necessary to specify ALL of the mutual inductive, capacitive and resistive couplings between EVERY pair of pins. Symmetry ensures that only the half of the matrix above (or below) and including the main diagonal needs to be provided. But even so, this could be a BIG file... (100 pins -> ~150 Kbytes). 4) Multiple representations: in cases where the vendor (or the user) wants a quicker, dirtier simulation and doesn't want to specify ALL the couplings, both a banded-matrix or a sparse-matrix representation can be used to make the package model file a LOT smaller. It would be nice to give the modelling engineer different options for specifying the package model. Did I miss anything? From qdt!sal!jonp@uunet.UU.NET Mon Feb 7 14:46:14 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12259; Mon, 7 Feb 94 14:46:14 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwcgw01098; Mon, 7 Feb 94 17:44:35 -0500 Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 174311.22536; Mon, 7 Feb 1994 17:43:11 EST Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00849; Mon, 7 Feb 94 14:40:30 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA00754; Mon, 7 Feb 94 14:40:30 PST Date: Mon, 7 Feb 94 14:40:29 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9402072240.AA00754@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA11736; Mon, 7 Feb 94 14:40:34 PST To: ibis@vhdl.org Subject: Standard circuit, validation of EDA "IBIS-capability" Dear Ibis type people: I don't believe it the IBIS forums job to say whether or not someones simulator is giving the right answer. What we can show is that a certain level of accuracy of simulation can be achieved with the data we are providing. It is up to the individual simulator vendors to make sure that their use of that data is "good". Some of this may be up the the personal decisions of the various companies. For instance, you can imagine a product that does not do anything with waveforms at all but guarantees to give wire delays within 10% and run a billion times faster than a honda. If this is what the customer wants (as shown by his wallet) then far be it for the comittee to say that someones waveforms weren't good. nuff said, jon From idodd@ian.edaco.ingr.com Mon Feb 7 15:04:31 1994 Return-Path: Received: from ian.edaco.ingr.com (ian.dazixco.ingr.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12365; Mon, 7 Feb 94 15:04:31 PST Received: by ian.edaco.ingr.com (4.1/SMI-4.1) id AA04209; Mon, 7 Feb 94 16:02:53 MST Date: Mon, 7 Feb 94 16:02:53 MST From: idodd@ian.edaco.ingr.com (Ian Dodd) Message-Id: <9402072302.AA04209@ian.edaco.ingr.com> To: ibis@vhdl.org Subject: Re: EGG 1.0 (Package Models) All, There was a proposal to allow packages objects as distinct entities in an IBIS "library". Individual IBIS part descriptions could then reference shared package descriptions. Sockets are in many ways similar to packages, it seems that it would be useful to allow sockets to be described using a similar syntax. The choice of whether to socket, or not to socket is many times left to the manufacturing step, so I normally would expect that the binding between a part description and a socket description would be made on an instance by instance basis. Ian Dodd Intergraph Electronics idodd@ingr.com (303) 581 2358 From speters@ichips.intel.com Tue Feb 8 12:21:40 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26641; Tue, 8 Feb 94 12:21:40 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 8 Feb 94 12:19:46 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 8 Feb 94 12:19:10 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 8 Feb 94 12:19:13 PST Message-Id: <9402082019.AA17173@xtg801.intel.com> To: bert@ibmoto.com Cc: ibis@vhdl.org Subject: RE: typ, min, max condition specification Date: Tue, 08 Feb 1994 12:19:12 -0800 From: Stephen Peters Hello Bert -- To answer your second question first: The 'min' data is taken under the conditions that cause the slowest ristime/weakest drive while the 'max' data is taken under the conditions that cause the fastest risetime/strongest drive. Your first question is a good one. According to Don Telian (one of the originators of IBIS) the original intention was to start with a typical model and then vary the voltage/temp/process to get a "reasonable" min/max model. The temperature points of 50, 0 and 100 were convienent and spaned a wide temperature range. There is nothing in the spec that says you can't do it over a different temperature range, however, it might be good to include a note in the file saying what temp range your models min and max were taken at. Best Regards, Stephen Peters Intel Corp. --------------- original from Bert ------------ >I have studied the IBIS OVerview, Version 1.0. I have the following >questions concerning "typ", "min", and "max" conditions: > >1) Are the specified temperatures the only ones that are allowable? >Our parts are spec'd at 10C to 105C, should I then be using these >numbers? Or, does some multidimensional curve fitting mandate certain >limits? It looks to me that I should do my extractions at my real >extremes -- right? > >2) Relative to the process limits I assume that I chose my slowest >process data for the "min" condition and the fastest process data for >the "max" condition? > >Thanks ... > From bob@icx.com Tue Feb 8 20:22:22 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29780; Tue, 8 Feb 94 20:22:22 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11228 for ; Tue, 8 Feb 94 21:36:11 -0500 Date: Tue, 8 Feb 94 17:21:04 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18681; Tue, 8 Feb 94 17:21:04 PST Message-Id: <9402090121.AA18681@icx.com> To: ibis@vhdl.org Subject: Examples for Bird9 | Hello IBIS Members: | | Examples of Terminator Packages per BIRD9 showing [Rpower] and [Rgnd] | | These components could be created by the user and loaded with the rest | of the design components. Bob Ross, Interconnectix, Inc. | TERMINATORS | [IBIS Ver] 1.1 [File name] term.ibs [File Rev] 1.0 [Date] 2/8/94 [Source] User creates these models based on Component Connections | PARALLEL TERMINATOR USING [Rpower] and [Rgnd] (For Future Version of IBIS) | |*************************************************************************** [Component] PARALLEL_R_PACK [Manufacturer] Anyone [Package] | typ min max R_pkg 0 NA NA | Parasitics Ignored Here C_pkg 0 NA NA L_pkg 0 NA NA |*************************************************************************** [Pin] signal_name model_name 1 Vcc POWER 2 In1 Rparallel | 220 Ohm to VCC, 330 Ohm to GND 3 In2 Rparallel 4 In3 Rparallel | .... | 20 GND GND |*************************************************************************** [Model] Rparallel Model_type Input | typ min max C_comp 0 NA NA |*************************************************************************** | typ min max [Voltage range] 5.0 4.5 5.5 |*************************************************************************** | typ min max [Rpower] 220 200 240 | R = 220 Ohm to VCC [Rgnd] 330 300 360 | R = 330 Ohm to GND |*************************************************************************** | RC TERMINATOR PACKAGE CURRENTLY AVAILABLE IN IBIS VERSION 1.1 | |*************************************************************************** [Component] RC_PACK [Manufacturer] Anyone [Package] | typ min max R_pkg 47 42 52 | R Part of RC Terminator to GND C_pkg 0 NA NA L_pkg 0 NA NA |*************************************************************************** [Pin] signal_name model_name 1 In1 RCModel | C Part of RC Terminator to GND 2 In2 RCModel | R = 47 Ohm, C = 33 pF 3 In3 RCModel | .... | 20 GND GND |*************************************************************************** [Model] RCModel Model_type Input | typ min max C_comp 33p 30p 36p | C Part of RC Terminator to GND |*************************************************************************** | typ min max [Voltage range] 5.0 4.5 5.5 |*************************************************************************** [End] From slipa@eos.ncsu.edu Wed Feb 9 11:36:15 1994 Return-Path: Received: from rand.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10049; Wed, 9 Feb 94 11:36:15 PST Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA13854; Wed, 9 Feb 1994 14:34:26 -0500 From: slipa@eos.ncsu.edu Message-Id: <9402091934.AA13854@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis (SPICE TO IBIS PROGRAM) Status report Date: Wed, 09 Feb 94 14:34:23 EST Dear IBIS Community: Hi. This is a short report to update you on the status of s2ibis, the SPICE to IBIS conversion program that I am working on. At this point I am able to put out what I think is a syntactically correct xxxx.ibs file including the header ([IBIS Ver] through [Pin]) and [Model] sections which include [Pullup], [Pulldown], [GND_clamp], and [POWER_clamp] tables for TYP conditions. The hooks are there for doing the MIN and MAX conditions, and the [Ramp] table. The input to s2ibis consists of a normal [Pin] section with an extra line after each pin (except NC pins) that helps s2ibis to set up the simulations followed by a SPICE deck. The extra line (I will call it the pindata line from now on...) after each pin in the [Pin] section has the following syntax: For input pins: * model_type SPICE_NODE polarity vil vih For output pins: * model_type SPICE_NODE ramp_sim_time input_pin [enable_pin] For POWER pins: * model_type SPICE_NODE vpwr_typ [vpwr_min] [vpwr_max] --------------------------------------------------------------- s2ibis automatically sets up all the simulation runs, runs the simulations, extracts the tables from the SPICE output decks, and writes the xxxx.ibs file. For Output, I/O, and 3-state model types, all the [Model] tables are generated (except Ramp at this point). For Open_drain, all of the above except [Pullup] and [POWER_clamp] are generated. For Inputs, only the POWER_clamp and GND_clamp tables are generated. The simulation strategy at this point is simple-minded, and doesn't always work, but it is easy to modify!: For [Pulldown] tables, the appropriate input is driven to the vil or vih given on its pindata line depending on whether it is inverting or not. If an enable pin is associated with the output is is also conditioned properly. All other input pins are simply driven to zero volts to help convergence. A .DC analysis is used with the output under test as the driven pin. [Pullup] tables are treated the same as [Pulldown]s, but the associated input is driven the opposite way. In [GND_clamp] and [POWER_clamp] simulations all disable-able outputs are disabled and all inputs (except the pin under test if it is an input or I/O) are driven to zero volts. A .DC analysis is used with the appropriate range. Unfortunately, the simulations I have been running on my simple test cases have not always converged. For instance, with a simple 2.3:1 CMOS input buffer with input clamp diodes to both rails, my GND_clamp simulation on the input pin will not converge (the starting input voltage is -5V). --------------------------------------------------------------- I really need some feedback regarding the simulation strategy, especially with regard to convergence issues. Are convergence problems typical among those of you who are generating IBIS models from SPICE runs or am I doing something wrong? If they are, is it really reasonable to automatically run the simulations? If they aren't, and we can address this convergence issue effectively, the program could be released fairly soon. Also, I have not received any real-world examples from anyone, so s2ibis can only be tested on my simple test cases. Is it possible for someone to send me an example to see if s2ibis gets the same results? Would a non-disclosure agreement help??? Steve Lipa slipa@eos.ncsu.edu 919-515-3947 From 71436.1314@CompuServe.COM Thu Feb 10 09:37:58 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24335; Thu, 10 Feb 94 09:37:58 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id MAA08997; Thu, 10 Feb 1994 12:34:58 -0500 Date: 10 Feb 94 12:32:42 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "Steve Lipa (SPICE2IBIS)" Cc: IBIS ALL Subject: Spice to IBIS update (excellent news) Message-Id: <940210173242_71436.1314_HHB74-1@CompuServe.COM> From: Kellee Crisafulli To: Steve and IBIS members Re: Spice to IBIS I think your progress is excellent! It sounds like we need to help you get some spice models. I was hoping that one of the semiconductor people would have given you their model files by now. HyperLynx does not have any spice models that we can send you without violating non-disclosure agreements. (Note to Bob Ward): Is there any possiblity of getting models for Steve from TI? Please..... Relative to the problems with getting the models to converge. This is not uncommon. I have used several vendors spice models and found numerous problems with getting them to converge. If I use one of the commercial spice packages as opposed to Berkley standard release I find the converge problems are reduced significantly. Which spice package are you using? Also I have noticed that if I stay close to the values that I receive the model set to that they work fine. If I sweep the data too broadly it causes problems. Perhaps this should be an input parameter to the converter. From ccm!Derrick_Duehren@intelhf.intel.com Thu Feb 10 21:10:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29250; Thu, 10 Feb 94 21:10:08 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pUq7A-000MNYC; Thu, 10 Feb 94 21:08 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pUqAc-0000DMC; Thu, 10 Feb 94 21:12 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 10 Feb 94 21:12:01 PST Date: Thu, 10 Feb 94 21:12:01 PST From: Derrick Duehren Message-Id: <940210211201_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Membership Roster Text item: Text_1 =============================================================================== IBIS Consortium Membership Roster As of 2/10/94 (updated quarterly) Submit changes/updates to: Derrick Duehren, Intel Corp. dduehren@ichips.intel.com (503) 696-4299, Fax (503) 696-4904 =============================================================================== Anacad Contact: Steffen Rochel Email: sr@anacad.de Phone: +49 (731) 9545414, FAX: +49 (731) 9545450 Address: Helmholtzstr.20 89081 Ulm Germany Support: Anacad can translate IBIS descriptions into models using their analog behavioral modeling language HDL-A. Together with Eldo and a VHDL simulator, highly accurate investigations of mixed signal designs are then possible. Ansoft Corporation Contact: Henri Maramis Email: maramis@ansoft.com Phone: (412) 261-3200, Fax: (412) 471-9427 Address: 4 Station Square, Suite 660 Pittsburgh, PA. 15219 Support: Work is in progress to support IBIS models/library in native file/format. Atmel Corporation Contact: Dan Terry Email: Phone: Address: Support: Cadence Design Systems Contact: C. Kumar Email: cpk@cadence.com Phone: (508) 262-6481 Phone: (508) 262-6488, Fax: 508-262-6600 Address: 270 Billerica Rd, Chelmsford, MA 01824 Support: Cadence fully supports Ibis behavior models at the I/O cell and package levels. Customers can convert IBIS 1.1 files to Cadence library format by using translator program IBIS2Cadence Contec Microelectronics USA Inc. Contact: Maah Sango, Clark Cochran Email: maah@contec.com Phone: (408) 434-6767, Fax: (408) 434-6884 Address: 2188 Bering Drive San Jose, CA 95131 Support: A Contec product will support IBIS models in native mode. Digital Equipment Corp. Contact: Barry Katz Email: katz@decsim.enet.dec.com Phone: (508) 568-6016 Address: 77 Reed Road, HLO2-2/H13 Hudson, MA 01749 Support: Digital is interested in generating IBIS models for some of its components and supporting these and other IBIS models in our in-house simulation tools. High Design Technology Contact: Michael Smith Email: Phone: Address: Support: HyperLynx Contact: Kellee Crisafulli Email: 71436,1314@compuserve.com Phone: (206) 869-2320, Fax: (206) 881-1008 Address: P.O. Box 3578 Redmond, WA 98073-3578 Support: The Linesim Pro product supports IBIS as follows: 1) Any IBIS file can be used directly as a 'NATIVE' file (Version 3.0 or newer). 2) A single model in an IBIS file can selected, loaded, and viewed directly. 3) Several IBIS models can be included in a single file and used as a library. Note: this library file still complies completely with the IBIS specification and can be checked with the IBIS check program. IBM Contact: (unofficially) Joseph C. (Jay) Diepenbrock Email: jayd@ralvm29.vnet.ibm.com Phone: (919) 543-8804 Address: IBM Network Hdwe. Div. Transceiver Technology Dev't, D63/061 P. O. Box 12195 Research Triangle Park, NC 27709 Support: No formal declaration of support. IBM-Motorola (PowerPC) Contact: Lynn Warner, Soa Quoc Email: Phone: Address: Support: Integrity Engineering Contact: Greg Doyle Email: Phone: Address: Support: The Integrity Simulators and Parasitic Extractor tools, SImnet, SImnet X, and Autospice are shipped with an IBIS2IEI translation program that enables any IBIS file to be directly converted for use with the simulator or SPICE extractor. The next revisions of IEI programs, slated for delivery 2Q '94, will support IBIS models in native mode. A utility will be provided to read, edit and view IBIS files directly. Intel Corporation Contact: Will Hobbs Email: will_hobbs@ccm.hf.intel.com Phone: (503) 696-4369, Fax: (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel Interconnectix, Inc. Contact: Bob Ross Email: bob@icx.com Phone: (503) 684-6641, Fax: (503) 639-3469 Address: 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Support: Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. Intergraph Contact: Ian Dodd, David Wiens Email: idodd@ingr.com, dwiens@ingr.com Phone: (303) 581-2300 Address: 6101 Lookout Road, Suite A Boulder, CO 80301 Support: IntuSoft Contact: Charles Hymowitz Email: Phone: Address: Support: IntuSoft takes a customer's netlist or model and translates it into a Spice model, free of charge. IntuSoft has the Golden Parser source but hasn't, as of yet, automated the process. IntuSoft is waiting until there are more IBIS models available. Logic Modeling Corp. Contact: Randy Harr Email: randyh@lmc.com Phone: (408) 945-9181 Address: 1520 McCandless Dr. Milpitas, CA 95035 Support: None at this time Mentor Graphics Contact: Ravender Goyal Email: Ravender_Goyal@mentororg.com Phone: Address: 8005 SW Boeckman Rd. Willsonville, OR 97070-7777 Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Meta-Software Contact: Mei Wong Email: Phone: Address: Support: MicroSim Corp. Contact: Arthur Wong Email: Phone: (714) 770-3022, FAX: (714) 455-0554 Address: 20 Fairbanks Irvine, CA 92718 Support: MicroSim can automatically generate PSpice models for vendors who provide data in a file format conforming to the IBIS Ver 1.1 specification. The models can then be simulated with PSpice. MicroSim has made IBIS models for Intel's Pentium processor 82430 PCIset available to customers. National Semiconductor Corp. Contact: Syed Huq Email: huq@rockie.nsc.com Phone: (408)721-4874, Fax:(408)721-4785 Address: 2900 Semiconductor Drive M/S E-200 Santa Clara, CA 95052 Support: National Semiconductor is willing to write some IBIS files and see how they work with a simulator of choice. North Carolina State University Contact: Michael Steer, Paul Franzon, Steve Lipa Email: mbs@ncsu.edu paulf@ncsu.edu slipa@eos.ncsu.edu Phone: 919-515-5191 919-515-7351 919-515-3947 FAX for all three: 919-515-5523 Address: ECE Dept. Box 7911 NC State Univ. Raleigh, NC 27695-7911 Support: (as of 2/94) A Spice to IBIS converter is being developed. A measurement based procedure is being developed for extracting IBIS models. A yacc/lex parser for IBIS models is being develped. All software and techniques will be put in the public domain. Performance Signal Integrity Contact: Eric Bracken Email: Phone: Address: Support: Quad Design Contact: Jon Powell Email: jonp@qdt.com Phone: (805) 988-8250 Address: Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and will be generally distributed with the XTK 5.2 release (available in Feb. 1994). Quantic Labs Contact: Mike Ventham, Zhen Mu Email: ventham@quantic.mb.ca mu@quantic.mb.ca Phone: (204) 942-4000, Fax: (204) 957-1158 Address: 12th Floor, 191 Lombard Ave Winnipeg, Manitoba, Canada R3B 0X1 Support: Quantic will be providing an IBIS reader (based on the Golden Parser) that will read IBIS models and automatically generate data files for Phidias (our graphical VI curve device modellor) and database files that associate the component definitions with the pin models. From Phidias, both SPICE models for Greenfield Phyllis (our PHYsical Load and Line Simulator) and models for BoardScan, (our PC board scanner for signal integrity and crosstalk) can be created. The release date has not been set yet. An application note is available regarding using IBIS models with Phidias. Siemens Nixdorf Contact: Werner Rissiek, Olaf Rethmeier Email: wr@cadlab.cadlab.de, olaf@cadlab.cadlab.de Phone: ++49-5251-284-155, ++49-5251-284-222, Fax: ++49-5251-284-105 Address: Siemens Nixdorf Informationssysteme AG Cadlab / Analog System Engineering Bahnhofstrasse 32 D-33102 Paderborn, Germany Support: Siemens Nixdorf uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. Siemens Nixdorf can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. Siemens Nixdorf uses an IBIS parser, developed by Siemens Nixdorf, and a semi-automatic process for the parametrization of the FREACS macromodels. The translation of IBIS to FREACS is available as a service for customers. A fully automated process will be developed when there are more IBIS models available. Additionally, so called 'reference lists' are set-up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit informations in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS-informations, as well. In this way a controlled set-up of a library is possible using IBIS-files as basis. Detailed information will be available on request. Texas Instruments Contact: Bob Ward Email: bward@dadhb1.ti.com Phone: (713) 274-4146, Fax (713) 274-3911 Address: Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Zeelan Technology Contact: Hiro Moriyasu, George Opsahl, Samie Samaan, Tay Wu Email: Phone: (503) 520-1000 Address: 10550 SW Allen Blvd. Beaverton, OR 97005 Support: From ccm!Arpad_Muranyi@intelhf.intel.com Fri Feb 11 15:52:43 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11267; Fri, 11 Feb 94 15:52:43 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pV7dT-000MOrC; Fri, 11 Feb 94 15:50 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pV7h2-0000UxC; Fri, 11 Feb 94 15:54 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 11 Feb 94 15:54:40 PST Date: Fri, 11 Feb 94 15:54:40 PST From: Arpad Muranyi Message-Id: <940211155440_16@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, Don_A_Telian@ccm.hf.intel.com, Derrick_Duehren@ccm.hf.intel.com, ibis@vhdl.org Subject: Re: Pending BIRD 9.0 (cleaned up) To our bosses (with more power), I think we should complain to Lotus (CCMAIL) because this is driving me crazy too. Especially when I get ASCII files for spice. Try to clean that up and not miss a negative sign for a number! Arpad Derrick, et al, For some bizarre reason, our mail program, cc:Mail, chooses to add carriage returns and dashes and generally mangles files. I always go through and clean them up before posting to the reflector. When it comes back from vhdl.org, the program does it again. I have assumed that it only happend to incoming mail and have dealt with it that way. I suspect this is happening to Derrick, too, since he is on the same mail program. But I may be wrong-- is the corruption happening on the way out, too, or are we at Intel just being penalized on incoming mail. In other words, did you, Derrick, clean up Bird 9 because of these extraneous incoming additions, courtesy of Lotus' cc:Mail, or did the mail get mangled going out? Did other members of the forum receive an un-mangled version from me, or did some lines look like the following: *************************************************************** - ** etc., etc.? I did notice that the word "pending" was put in in the filed of when accepted. Good change. Will From ccm!Derrick_Duehren@intelhf.intel.com Fri Feb 11 17:30:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11862; Fri, 11 Feb 94 17:30:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pV99j-000MOqC; Fri, 11 Feb 94 17:28 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pV9DI-0000hHC; Fri, 11 Feb 94 17:32 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 11 Feb 94 17:32:04 PST Date: Fri, 11 Feb 94 17:32:04 PST From: Derrick Duehren Message-Id: <940211173204_21@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Open Forum 2/18 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 2/18/94 Bridge: Res: (415) 904-8800 661436 All meetings are 8:00 AM to 10:00 AM PST. When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. Omissions From 1/28/94 Minutes ------------------------------ We have three new members. They are: Digital Equipment Corp. IBM-Motorola Alliance National Semiconductor Meeting Agenda -------------- Note: We need to close out many of these issues. 8:00 Check-in 8:05 Intros of new IBIS members/participants Hobbs 8:10 Review of 1/28 minutes Hobbs Miscellany/Announcements Hobbs BIRDs Roster posted Please use CRLFs (Duehren) Opens for new issues All Treasurer's Report Hobbs 8:20 Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 (ratification at DAC?, process?) Hobbs IBIS Cookbook Hobbs Dues (shelved till DAC?) Hobbs Standard driver? Muranyi, Powell Quality of support, validation Hobbs 8:40 BIRD 6, Differential Pin Spec. Ross BIRD 7, Open Specification Completion Ross BIRD 8, Specification of V/I data monotonicity Crisafulli Egg 1, mutual pin coupling Bracken BIRD 9, Other model types Ross Monotonic current tracing Crisafulli Ramp measurement Reid, Ross, et. al. Spice to IBIS Converter Lipa (NCSU) 9:25 Canright paper Ward Formal BNF notation (BIRD?) Reed, Harr BIRD 2, VIH, VIL Thresholds for Inputs Powell 9:35 High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs From Will_Hobbs@ccm2.jf.intel.com Tue Feb 15 17:51:24 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04679; Tue, 15 Feb 94 17:51:24 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 15 Feb 94 17:49:39 -0800 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 15 Feb 94 17:49:26 -0800 Received: from ccMail by jfsmt2.intel.com id AA761363385 Tue, 15 Feb 94 17:49:45 PST Date: Tue, 15 Feb 94 17:49:45 PST From: "Hobbs, Will" Message-Id: <9401157613.AA761363385@jfsmt2.intel.com> To: ibis@vhdl.org, Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org, whobbs@ichips.intel.com Subject: test message, please disregard This is a test to see where the line mangling problem in Intel's mail system occurs. This is a test of our mail system. We have been informed that this problem only occurs when lines contain more than 80 characters. The first paragraph allowed the system to wrap the line. The first line of this paragraph is terminated at 80 characters with a crlf. The second line wraps into the third after 79 characters, then the wrapped line terminates with a crlf. This test is an attempt to set the limits of line length, crlf presence and absence that triggers the problem. I am mailing this message through our internal mail system, and two external gateways to the reflector to see the effect. Sorry for the noise on your mailbox, but our system support group has been unable to reproduce the problem that has been causing Derrick, Arpad and me so much trouble with the BIRDs. Regards, Will Hobbs Intel From ccm!Will_Hobbs@intelhf.intel.com Tue Feb 15 18:01:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04749; Tue, 15 Feb 94 18:01:08 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pWbXy-000MOhC; Tue, 15 Feb 94 17:59 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pWbc3-0000VWC; Tue, 15 Feb 94 18:03 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 15 Feb 94 18:03:39 PST Date: Tue, 15 Feb 94 18:03:39 PST From: Will Hobbs Message-Id: <940215180339_48@ccm.hf.intel.com> To: whobbs@ichips_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org_at_smtpgate@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Subject: test message, please disregard Text item: Text_1 This is a test to see where the line mangling problem in Intel's mail system occurs. This is a test of our mail system. We have been informed that this problem only occurs when lines contain more than 80 characters. The first paragraph allowed the system to wrap the line. The first line of this paragraph is terminated at 80 characters with a crlf. The second line wraps into the third after 79 characters, then the wrapped line terminates with a crlf. This test is an attempt to set the limits of line length, crlf presence and absence that triggers the problem. I am mailing this message through our internal mail system, and two external gateways to the reflector to see the effect. Sorry for the noise on your mailbox, but our system support group has been unable to reproduce the problem that has been causing Derrick, Arpad and me so much trouble with the BIRDs. Regards, Will Hobbs Intel From JAYD@RALVM29.VNET.IBM.COM Wed Feb 16 07:19:57 1994 Return-Path: Received: from vnet.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18838; Wed, 16 Feb 94 07:19:57 PST Message-Id: <9402161519.AA18838@vhdl.vhdl.org> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 8203; Wed, 16 Feb 94 10:15:15 EST Date: Wed, 16 Feb 94 10:05:56 EST From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" X-Addr: Transceiver Technology Dev't, D63/061 IBM Network Hdwe. Div. P. O. Box 12195 Research Triangle Park, NC 27709 To: ibis@vhdl.org Subject: General Info Hello IBISers, Being a relative newcomer to this forum, I seem to be lacking understanding of some basic things. I'm hoping that there's some document that will explain them, but I don't see it in the index of 1.0 or 1.1. Here goes: 1. What is the circuit topology to be used to extract the DC pin character- istics? If a voltage source that's swept from, say, -5 to +10 V, how do the results relate to those when driving a "real" load that has non- zero impedance? I'm a little uncomfortable with the method, but I've not seen any specifics about how to do it, so am making assumptions (you all know what results from that!). Is there some general IBIS document that addresses this kind of question? 2. Getting back to a question raised by Lynn Warriner a couple of weeks ago, I'd like to ask the signal integrity tool providers how we the prospec- tive customers are supposed to choose our tools... claims of "more accurate than xyz" are not practical to validate. I'd feel a lot better if there were some standard benchmarks (either net configurations or, better still, hardware) by which we could make choices. I recognize the need for tool vendors to differentiate their products, but I'm frankly not interested in doing detailed evaluations of several tools before starting a project that needs one. Any thoughts would be welcome. Thanks for your patience. Jay Diepenbrock From bracken@valhalla.performance.com Wed Feb 16 08:15:57 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19312; Wed, 16 Feb 94 08:15:57 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA02992; Wed, 16 Feb 94 11:15:54 EST Message-Id: <9402161615.AA02992@valhalla.performance.com> To: "J. C. (Jay) Diepenbrock ((919)-543-8804)" Cc: ibis@vhdl.org Subject: Re: General Info In-Reply-To: Your message of "Wed, 16 Feb 94 10:05:56 EST." <9402161519.AA18838@vhdl.vhdl.org> Date: Wed, 16 Feb 94 11:15:50 -0500 From: bracken@valhalla.performance.com Jay, With regard to your first question, using a voltage source sweep is quite adequate for characterizing the "DC" behavior of the gate. You're going to get an I-V curve that describes the behavior of the gate for all voltages "of interest" during the simulation. With this curve, you can see how the gate will behave when it's loaded by any impedance. For example, suppose your voltage sweep determines this I-V curve for the pull-down element of an output buffer: i ^ * | * 100mA - * | * | * | * | * | * | * 0 mA -+*****-------------|----> v 0V 5v Now suppose that the load is a 50-ohm transmission line initially at 5V, which you wish to pull down to 0V. The voltage at the driver is going to be 5V - (50 Ohms)*i (i is the current the driver can sink.) In other words, if we can only sink 0 mA, the voltage will stay at 5V; if we can sink a full 100 mA, the voltage will drop to 0V. The plot of voltage vs. current for the load is a straight line, called the "load line". You can impose this "load line" on the I-V curve and find the solution graphically: i ^ * | * 100mA o * | o * | o * | o* <---- answer is here! | * o | * o | * o 0 mA -+*****--------------|---> v 0V 5v The point where the two curves cross gives you the answer because it's consistent with both of the "constraints." The CAD tools out there use numerical methods to find this point of crossing. So, nonzero impedances are handled properly. With regard to AC behavior, the IV curve alone isn't sufficient. That's why the IBIS model has the first-order RLC values of the buffer's pin in addition to IV models. Enhancements to make the models work at still higher frequencies are being discussed in the forum right now. --Eric From ccm!Will_Hobbs@intelhf.intel.com Wed Feb 16 08:44:40 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19452; Wed, 16 Feb 94 08:44:40 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pWpKz-000MObC; Wed, 16 Feb 94 08:42 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pWpP8-0000IIC; Wed, 16 Feb 94 08:47 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 16 Feb 94 08:47:13 PST Date: Wed, 16 Feb 94 08:47:13 PST From: Will Hobbs Message-Id: <940216084713_5@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, JAYD@RALVM29.VNET.IBM.COM, ibis@vhdl.org Subject: Re: General Info Jay, Have you received the IBIS overview document? If not, send me your U.S. mailing address and I'll get it out to you. It covers some of your questions about the dc sweep. Regarding your second question, it is on the agenda for Friday's phone conference, though I fear we won't bottom out on it there, since it seems to be a somewhat volatile issue. Issues like this may indicate the need for an earlier summit than the one being considered for DAC. Regards, Will Hobbs Intel Hello IBISers, Being a relative newcomer to this forum, I seem to be lacking understanding of some basic things. I'm hoping that there's some document that will explain them, but I don't see it in the index of 1.0 or 1.1. Here goes: 1. What is the circuit topology to be used to extract the DC pin character- istics? If a voltage source that's swept from, say, -5 to +10 V, how do the results relate to those when driving a "real" load that has non- zero impedance? I'm a little uncomfortable with the method, but I've not seen any specifics about how to do it, so am making assumptions (you all know what results from that!). Is there some general IBIS document that addresses this kind of question? 2. Getting back to a question raised by Lynn Warriner a couple of weeks ago, I'd like to ask the signal integrity tool providers how we the prospec- tive customers are supposed to choose our tools... claims of "more accurate than xyz" are not practical to validate. I'd feel a lot better if there were some standard benchmarks (either net configurations or, better still, hardware) by which we could make choices. I recognize the need for tool vendors to differentiate their products, but I'm frankly not interested in doing detailed evaluations of several tools before starting a project that needs one. Any thoughts would be welcome. Thanks for your patience. Jay Diepenbrock From qdt!sal!jonp@uunet.UU.NET Wed Feb 16 16:17:47 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23461; Wed, 16 Feb 94 16:17:47 PST Received: from uucp4.uu.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwdoj06458; Wed, 16 Feb 94 19:15:51 -0500 Received: from qdt.UUCP by uucp4.uu.net with UUCP/RMAIL ; Wed, 16 Feb 1994 19:15:53 -0500 Received: from sal.qdt.com by qdt (4.1/SMI-4.1) id AA01086; Wed, 16 Feb 94 16:01:35 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA02053; Wed, 16 Feb 94 16:01:34 PST Date: Wed, 16 Feb 94 16:01:34 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9402170001.AA02053@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA26365; Wed, 16 Feb 94 16:01:42 PST To: ibis@vhdl.org Subject: bird2.1 Hey guys, Here is my long promised try at bird 2.1. I had to make more change suggestions than I wanted to but it seems that this is a good time to get this stuff out and discussed before we make the new parser etc. Buffer Issue Resolution Document (BIRD) BIRD ID#: 2.1 ISSUE TITLE: Requiring VIH VIL thresholds for input devices REQUESTOR: Jon Powell, Quad Desgin DATE SUBMITTED: 10/4/93 rev 2.1 2/16/94 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The V1.1 IBIS specification does not require the presence of input thresholds on input devices. This allows data-generators to omit thresholds and still create "IBIS LEGAL" models. Input devices with no stated digital logic input thresholds would not allow for the calculation of digital pin-to-pin delays which is a very important quantity to many potential users. Requiring a low and high threshold for all input devices is therefor a reasonable requirement that adds information without creating undo restrictions. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: modify the [Model] statement to take into account different devices separate from device technology. Model_type Input Output I/O analog_load | list one only Model_technology TTL CMOS ECL GAL OTHER | list one only Model_structure Tri-state Open-Drain Open-Collector Normal | list one only Devices of type Input and I/O would give a warning if Vih and Vil are not specified and a default of .8 and 2.0 (low high respectively) would be generated. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: There are devices that are not Input or Outputs and are not handled by our current set of model types. For instance: Termination Resistor Packs Termination Diode Packs Descrete 2 port devices ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ******************************************************************************* From bob@icx.com Sat Feb 19 18:37:00 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04902; Sat, 19 Feb 94 18:37:00 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA28344 for ; Sat, 19 Feb 94 21:30:20 -0500 Date: Sat, 19 Feb 94 18:29:28 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA28130; Sat, 19 Feb 94 18:29:28 PST Message-Id: <9402200229.AA28130@icx.com> To: ibis@vhdl.org Subject: IBIS GRAMMAR To IBIS Members: In December, 1993, Chris Reid asked if anyone had done a YACC grammar for IBIS. Randy Harr responded in December with a grammar and also a proposal for grouping functions to add some rigor to IBIS. I have taken Randy's grammar and have added to it some details based on closer reading of IBIS Version 1.1 and also based on running some tests with the Golden Parser. Some of the versions of the grammar below have been sent out privately, and I had planned to add a little more rigor before I posted it. When I saw that North Carolina State University planned a yacc/lex parser for IBIS models, I sent Steve Lipa a version for information. Perhaps the NCSU version may evolve into an official version. Anyway, it may take longer than I intended to finish my version, so I am posting it as is, per the brief discussion at the last forum. I do favor having an official BNF grammar with IBIS. In addition, I have been trying to keep up with the BIRDS with a separate augmented grammar to help observe that the proposed extensions are done in a manner consistent with IBIS Version 1.1. Some comments are in parenthesis "( )" and are mostly notes to myself regarding some additional details which I have not formally captured. At the end I include a section to isolate the "units" specification. One intent is to point out the the IBIS times 1000 multiplier is a lower case "k" which actually is correct. This is one added detail that needs to be tracked since many products (and the DIE 0.9 Spec in which IBIS is referenced) use upper case "K". Bob Ross, Interconnectix, Inc. DRAFT BNF FOR IBIS VERSION 1.1 - STILL UNDER DEVELOPMENT Notation -------- Terminals of the grammar are enclosed by apostrophes. They are the actual keyword used in the IBIS file format. Keywords are not case sensitive and are put in upper case in this definition only. The vertical bar "|" separate alternatives. For example, A | B | C, represents exactly one occurrence of A or B or C. Braces "{}" indicate zero or more occurrences of the enclosed syntactic construct. For example, { A } represents the empty sequence, as well as A , and A A, A A A, and so on. Braces with plus "{}+" indicate one or more occurrences of the enclosed syntactic construct. Braces with question mark "{}?" indicate zero or one occurrences of the enclosed syntactic construct. The terminals of IBIS file format are keyWord token and item token. They are defined as entries in the semantic definition for each section. Definition ---------- $goal ::= ibisFileFormat ibisFileFormat ::= fileHeaderSection sections `[` `END' `]' fileHeaderSection ::= ibisVersion fileName FileVersion { fileHeaderItems } (ibisVersion first or after comments, others any order) fileHeaderItems ::= commentChar | date | source | notes | disclaimer ibisVersion ::= `[` `IBIS Ver' `]' string commentChar ::= `[` `comment char' `]' commentString (0 to many) commentString ::= character `_char' fileName ::= `[` `File name' `]' fileNameString fileNameString ::= string `.ibs' fileVersion ::= `[` `File Rev' `]' string date ::= `[` `date' `]' text (0 or 1) source ::= `[` `source' `]' text (0 to many) notes ::= `[` `notes' `]' text (0 or 1) disclaimer ::= `[` `disclaimer' `]' (0 to many) sections ::= section { section } section ::= componentDefinitionSection | modelDefinitionSection componentDefinitionSection ::= component manufacturer package pin (last 3 any order) component ::= `[' `component' `]' manufacturer ::= `[` `manufacturer' `]' text package ::= `[` `package' `]' package_RLC package_RLC ::= `R_pkg' typ_min_max | `L_pkg' typ_min_max | `C_pkg' typ_min_max (one of each pair in any order) typ_min_max ::= real real_na real_na real_na ::= [ real | `NA' ] pin ::= `[` `pin' `]' `signal_name' 'model_name' { `R_pin' `L_pin' `C_pin' }? { pin_entry }+ pin_entry ::= string string [model_identifier | `power' | `gnd' | `NC'] { real_na real_na real_na }? (3 or 6 columns for all entries) (R_pin, L_pin, C_pin required if 6 columns) modelDefinitionSection ::= `[` `model' `]' modelType modelEntry modelEntry ::= [ polarity | enable | vinl | vinh | c_comp | voltage_range | pulldown | pullup | gndClamp | powerClamp | ramp ] modelType :: = `model_type' [ `Input' | `Output' | `I/O' | `3- state' | `Open_drain' ] polarity ::= `[` `polarity' `]' [ `non-inverting' | `inverting' ] enable ::= `enable' [ `active-high' | `active-low' ] vinl ::= `vinl' `=' voltage_spec vinh ::= `vinh' `=' voltage_spec voltage_spec ::= real [ `V' ] c_comp ::= `c_comp' typ_min_max voltage_range ::= `[` `voltage range' `]' typ_min_max pulldown ::= `[` `pulldown' `]' viDefinitions pullup ::= `[` `pullup' `]' viDefinitions gndClamp ::= `[` `gnd_clamp' `]' viDefinitions powerClamp ::= `[` `power_clamp' `]' viDefinitions viDefinition ::= { real typ_min_max } ramp ::= `[` `ramp' `]' { dvdtR | dvdtF } dvdtR ::= `dV/dt_r' typ_min_max_rate dvdtF ::= `dV/dt_r' typ_min_max_rate typ_min_max_rate ::= rate [ rate | `NA' ] [ rate | `NA' ] rate ::= real `/' real real ::= real_number[ unit | { char } ] unit ::= [ `p' | `n' | `u' | `m' | `k' | `M' | `G' ]{ char } (etc. ...) From bob@icx.com Sun Feb 20 18:59:57 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15125; Sun, 20 Feb 94 18:59:57 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09894 for ; Sun, 20 Feb 94 21:46:51 -0500 Date: Sun, 20 Feb 94 18:44:52 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00599; Sun, 20 Feb 94 18:44:52 PST Message-Id: <9402210244.AA00599@icx.com> To: ibis@vhdl.org Subject: 3 OF 3 EXTENDED IBIS Most of the above is fairly self-explanatory. The key here is to realize that the four 'reference' keywords, in effect, create separate power supply rails that override the default [Voltage range] supply. The intention was to create a very general and flexible way to handle multiple supply devices and ECL. To illustrate with some examples: 1. An RS223 line driver has a +/- 12V output swing. One way to specify this device is shown below typ min max [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and | POWER_clamp ref [Pulldown reference] -12.0V -11.5V -12.5V | fixes pulldown ref [GND_clamp reference] -12.0V -11.5v -12.5V | fixes GND_clamp ref Optionally, the [Voltage range] keyword could be replaced with the [Pullup reference] and [POWER_clamp] reference. 2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for it's internal logic. The power clamp diodes are referenced to the 5V supply. Their are two equally valid ways this device can be specified. typ min max [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp | reference typ min max [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and | POWER_clamp reference [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage | range] specification | on the pullup 3. When specifying a device with an ECL type output structure, the pulldown curves must be referenced to the most positive supply (the same one that the pullup curves are referenced to). The easiest way to do this is define the value of the [Voltage range] as 0v. Both the pullup AND pulldown V/I curves will be referenced to 0v (remember, the pulldown defaults to 0v). typ min max [Voltage range] 0V 0V 0V | VCC supply [Pulldown reference] 0V 0V 0V | not really | required, its | specified for | completeness [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Alternately, one could specify the VEE supply and then override the default values of the pullup and pulldown references typ min max [Voltage range] -4.5V -4.0V -5.5v | VEE supply [Pullup reference] 0v 0v 0V [Pulldown reference] 0v 0v 0v [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Finally, to specify ECL logic that is used with a +5V supply (positive ECL) one can do the following: typ min max [Voltage range] 5.0V 4.5V 5.5V | VCC supply [Pulldown reference] 5.0V 4.5V 5.5V | override default The default references are used for the pullup and GND_clamp V/I curves. ******************************************************************************* NOTES ON BIRD4 (1) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. (2) The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. (3) The second proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ****************************************************************************** NOTES ON BIRD5.2 To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ..... .... .... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ..... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ..... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ..... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NC. ****************************************************************************** NOTES ON BIRD6.2 Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins which provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have differential input sensitivity specifications such as "Vpp" or "VT+" and "VT-" which define the differential threshold voltages between two input pins. The vdiff column is introduced for such specification limits (the magnitudes used for both polarities) which would trigger an output change. Two switching cycles show that the actual switching can occur at either polarity vdiff relative to one pin (A0_bar). If the actual switching completes near tmax (the threshold past the cross-over), then the first switching completes when (A0 - A0_bar) is negative and the second when (A0 - A0_bar) is positive. One application of vdiff is for timing analysis bounds. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | __ | Polarities of vdiff relative to A0 signal show both |<-- tmax -->| polarities used to bound the transition region | | |<-- tmin ->|| (output = 0) (output = 1) __________ || ____________ _____________ \ || / \ / A0 __\||/__ __\ /__ + \/ - vdiff - \/ + DIFFERENTIAL INPUT __ /\ __ __ /\ __ / \ / \ __ __________/ \____________/ \_____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The Tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. tdelay may relate to Tskew values of unloaded outputs, but are considered separate in IBIS as a launch delay of the non-inverting output relative to the inverting output. tdelay can be either polarity. Tskew can be shown per National Interface Databook, diagram on pg 1-121 along with tdelay: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ |\ Tskew/ \ / ^ D0 | Vo/2 | \|<>|/ \/ Vo/2 Vo v__ | _\ /__ __|/\|_____v DIFFERENTIAL OUTPUT | \/ / \ | | /\ /| |\ v_________|__/ \__________/ | | \_______ D0 | | | | | | >| |< Tskew Tskew = |tPLH - tPHL| | | >| |< tdelay (positive value) Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ****************************************************************************** NOTES ON BIRD7.2 Open-drain is corrected to Open_drain as a Model_type selection and is kept for backward compatibility. I/O_open_drain is added. The new types with "open_sink" and "open_source" are added to generically describe an output with either an open [Pullup] or [Pulldown] and an output that sinks or sources current. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_Open_source no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "open_sink" device. Omission of [Pulldown] could be interpreted as an "open_source" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink" or "open_drain" types. Zero valued [Pulldown] data corresponds to "open_source" types. Without the additional Model_types, the above two approaches plus the existance of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. ****************************************************************************** From bob@icx.com Sun Feb 20 19:00:04 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15159; Sun, 20 Feb 94 19:00:04 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09906 for ; Sun, 20 Feb 94 21:47:01 -0500 Date: Sun, 20 Feb 94 18:43:45 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00591; Sun, 20 Feb 94 18:43:45 PST Message-Id: <9402210243.AA00591@icx.com> To: ibis@vhdl.org Subject: 2 OF 3 EXTENDED IBIS |* are retained for backward compatibility. Model_types with |* "open_source" specify that the output has an OPEN side (the |* [Pulldown keyword is not used or I = 0mA for all voltages |* specified) AND the output SOURCES current. Model_types with |* "_ECL" specify that the model represents and ECL type logic |* which follows different conventions for the [Pulldown] keyword. |* | Note that C_comp defines the silicon die capacitance. This | | value should not include the capacitance of the package. | | | |------------------------------------------------------------------------------| [Model] model_name |* |* BIRD7.2 modification Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL | List one only |* Polarity Non-Inverting, Inverting | List one only, if any Enable Active-High, Active-Low | List one only, if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |==============================================================================| | Keyword: [Voltage range] | | Required: Yes | | Description: Used to define the power supply voltage tolerance over which | | the model is intended to operate. | | Usage Rules: Actual voltages (not percentages) are to be presented in the | | usual typ, min, max format. "NA" is allowed for the min and | | values only. | | Other Notes: [Voltage range] also describes the voltage range over which | | the various V/I curves and ramp rates were derived. | |------------------------------------------------------------------------------| | variable typ min max [Voltage range] 5.0V 4.5V 5.5V |****************************************************************************** |* BIRD3 replacement of [Voltage range] text above for VERSION 1.1X |*========================================================================== |* Keyword: [Voltage range] |* Required: Yes, if [Pullup reference], [Pulldown reference], |* [Power_clamp reference], and [GND_clamp reference] are not |* present |*Description: Used to define the power supply voltage tolerance over which |* the the model is intended to operate. It also specifies the |* default voltage rail the pullup and POWER_clamp V/I data is |* referenced to. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*--------------------------------------------------------------------------- |* variable typ min max [Voltage range] 5.0v 4.5v 5.5v |*=========================================================================== |* Keyword: [Pullup reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the pullup V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_r values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [Pulldown reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the pulldown V/I data. If this keyword |* is not present the voltage data points in the pulldown V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_f values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pulldown reference] 0V 0V 0V |* Keyword: [POWER_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the POWER_clamp V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [GND_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the GND_clamp V/I data. If this keyword |* is not present the voltage data points in the GND_clamp V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [GND_clamp reference] 0V 0V 0V |*============================================================================ |* NOTES ON SPECIFYING POWER SUPPLIES |* It is the intention that standard TTL and CMOS devices be specified |* using only the [Voltage range] keyword. However, in cases where |* the output characteristics of a device depend on more than a single |* supply and ground, or a pullup, pulldown or clamp structure is referenced |* to something other than the default supplys, the additional 'reference' |* keywords are to be used. |* If the [Voltage range] keyword is not present then all four of the |* other keywords must be present. If the [Voltage range] keyword is |* present the other keywords are optional and may or may not be used as |* required. It is legal (although redundant) for an optional keyword to |* specify the same voltage as specified by the [Voltage range] keyword. |****************************************************************************** |==============================================================================| | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | | Required: Yes, if they exist in the device | | Description: The data points under these keywords define the V/I curves of | | the pulldown and pullup structures of an output buffer and the | | V/I curves of the clamping diodes connected to the GND and the | | POWER pins, respectively. | | Usage Rules: In each of these sections the first column contains the | | voltage value, and the three remaining columns hold the | | typical, minimum, and maximum current values. The four | | entries, Voltage, I(typ), I(min), and I(max) must be placed on | | a single line and must be separated by at least one white | | space or tab character. | | All four columns are required under these keywords, however | | data is only required in the typical column. If minimum | | and/or maximum current values are not available, the reserved | | word "NA" must be used. "NA" can be used for currents in the | | typical column, but numeric values MUST be specified for the | | first and last voltage points on any V/I curve. Each V/I | | curve must have at least 2, but not more than 100, voltage | | points. | | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | | [POWER_clamp] structures are 'Vcc relative', meaning that the | | voltage values are referenced to the Vcc pin. The voltages in | | the data tables are derived from the equation: | | Vtable = Vcc - Voutput | | Therefore, for a 5V component, -5 V in the table actually | | means 5 V above Vcc, which is +10 V with respect to ground; | | and 10 V means 10 V below Vcc, which is -5 V with respect to | | ground. Vcc-relative data is necessary to model a pullup | | structure properly, since the output current of a pullup | | structure depends on the voltage between the output and Vcc | | pins and not the voltage between the output and ground pins. | | Note that the [GND_clamp] V/I curve can include quiescent | | input currents, or the currents of a 3-stated output if so | | desired. | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating data for ECL devices, the data in the pulldown table |* is measured with the output in the 'logic low' state. In other words, |* the data in the table represents the V-I characteristics of the |* output when the output is at the most negative of its two logic |* levels. Likewise, the data in the pullup table is measured with the |* output in the 'logic one' state and represents the V-I characteristics |* when the output is at the most positive logic level. Note that in BOTH |* these cases the data is referenced to the VCC supply voltage, using |* the equation Vtable = Vcc - Voutput. |****************************************************************************** |------------------------------------------------------------------------------| [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA |==============================================================================| | Keyword: [Ramp] | | Required: Yes, except for inputs | | Description: Used to define the rise and fall times of a buffer. | | Sub-Params: dV/dt_r, dV/dt_f | | Usage Rules: These parameters describe an ideal slope and can be expressed | | as a ratio of any reasonable voltage and time values as shown | | in the examples. The [Ramp] values are allowed to use "NA" | | for the min and max values only. | |------------------------------------------------------------------------------| [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n |==============================================================================| | Keyword: [End] | | Required: Yes | | Description: Used to define the end of the .ibs file. | |------------------------------------------------------------------------------| [End] |==============================================================================| | | | NOTES ON DATA DERIVATION METHOD | | | | This section explains how data values are derived. The intention here is to | | avoid over-guardbanding, enabling simulation results that are meaningful and | | useful. This is accomplished by having each silicon vendor base their data | | on typical process data, and then derate by voltage and temperature, and a | | proprietary "X%" factor. This methodology also has the nice feature that | | the data can be derived either from vendor-proprietary silicon models, or | | typical device measurement over temperature/voltage. | | | | 1) V/I curves for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "X%" | | max = hi voltage tol, 0 degrees C, typical process, plus "X%" | | | | V/I curves for bipolar devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 0 degrees C, typical process, minus "X%" | | max = hi voltage tol, 100 degrees C, typical process, plus "X%" | | | | where X% should be statistically determined by the silicon vendor | | based on numerous fab lots, test chips, process controls, ... The | | value of X need not be published in the IBIS file, and may decrease | | over time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | | | 2) Voltage Ranges: | | Points for each curve must span the voltages listed below: | | | | Curve Low Voltage High Voltage | | ----------- ----------- ------------ | | [Pulldown] GND - POWER POWER + POWER | | [Pullup] GND - POWER POWER + POWER | | [GND_clamp] GND - POWER GND + POWER | | [POWER_clamp] POWER POWER + POWER | | | | For example, a device with a 5 V power supply voltage should be | | characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; | | and a device with a 3.3 V power supply should be characterized | | between (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the | | pulldown curve. | | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating output data for ECL type devices, the voltage points |* must span the range of VCC to VCC - 2.2V. This range applies to both the |* pullup and pulldown tables. Note that this range applies ONLY when |* characterizing an ECL output. |****************************************************************************** | | | 3) Ramp Rates: | | The ramp rates (listed in AC characteristics below) should be | | derived by: | | 1. Start with silicon model, remove all packaging. | | 2. Attach 50 Ohm resistor to GND to derive rising edge ramp. | | 3. Attach 50 Ohm resistor to POWER to derive falling edge ramp. | | 4. Due to the resistor, output swings will not make a full | | transition as expected. However the pertinent data can still | | be collected as follows: | | a) determine the 20% to 80% voltages of the 50 Ohm swing | | b) measure this voltage change as "dv" | | c) measure the amount of time required to make this swing "dt" | | 5. Post the value as a ratio "dv/dt", the simulation tool vendor | | will extrapolate this value to span the required voltage swing | | range in the final model. | | 6. Typ, Min, and Max must all be posted, and are derived at the | | same extremes as the V/I curves, which are: | | | | Ramp times for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "Y%" | | max = hi voltage tol, 0 degrees C, typical process, plus "Y%" | | | | Ramp times for bipolar devices: | | To be determined by manufacturer. | | | | Note that the derate factor, "Y%", may be different than that used | | for the V/I curve data. This factor is similar to the X% factor | | described above. As in the case of V/I curves, temperatures are | | junction temperatures here also. | | | | 7. The rise time of an open-drain device must be measured into | | a 50 Ohm pullup resistor tied to the power pin. | | | |****************************************************************************** |* BIRD7.2 REPLACEMENT OF 3) FOR VERSION 1.1X |* NOTE, Items 3. and 7. above deleted, Items 4. thru 6. renumbered 3. thru 5. |* |* 3) Ramp Rates: |* The ramp rates (listed in AC characteristics below) should be derived |* as follows: |* |* 1. Start with the silicon model, remove all packaging. |* |* 2. If: The Model_type is one of the following: Output, I/O, or |* 3-state (not open or ECL types); |* Then: Attach a 50 ohm resistor to GND to derive the rising edge |* ramp. Attach a 50 ohm resistor to POWER to derive the |* falling edge ramp. |* |* If: the Model_type is Output_ECL or I/O_ECL; |* Then: Attach a 50 ohm resistor to the termination voltage |* (Vterm = VCC - 2v). Use this load to derive both the |* rising and falling edges. |* |* If: The Model_type is either an open_sink type or open_drain type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either POWER or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* If: The Model_type is an open_source type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either GND or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* 3. Due to the resistor, output swings will not make a full |* transition as expected. However the pertinent data can still |* be collected as follows: |* a) determine the 20% to 80% voltages of the 50 Ohm swing |* b) measure this voltage change as "dv" |* c) measure the amount of time required to make this swing "dt" |* 4. Post the value as a ratio "dv/dt", the simulation tool vendor |* will extrapolate this value to span the required voltage swing |* range in the final model. |* 5. Typ, Min, and Max must all be posted, and are derived at the |* same extremes as the V/I curves, which are: |* |* Ramp times for CMOS devices: |* typ = nominal voltage, 50 degrees C, typical process |* min = low voltage tol, 100 degrees C, typical process, minus "Y%" |* max = hi voltage tol, 0 degrees C, typical process, plus "Y%" |* |* Ramp times for bipolar devices: |* To be determined by manufacturer. |* |* Note that the derate factor, "Y%", may be different than that used |* for the V/I curve data. This factor is similar to the X% factor |* described above. As in the case of V/I curves, temperatures are |* junction temperatures here also. |****************************************************************************** | | It is expected that this data will be created from silicon vendor | | proprietary silicon-level models, and later correlated with actual device | | measurement. | |==============================================================================| |******************************************************************************| | ADDITIONAL NOTES FOR IBIS EXTENSIONS (BIRDS) | |******************************************************************************| ******************************************************************************* NOTES ON BIRD3 From bob@icx.com Sun Feb 20 19:00:14 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15178; Sun, 20 Feb 94 19:00:14 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09768 for ; Sun, 20 Feb 94 21:46:08 -0500 Date: Sun, 20 Feb 94 18:42:17 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00580; Sun, 20 Feb 94 18:42:17 PST Message-Id: <9402210242.AA00580@icx.com> To: ibis@vhdl.org Subject: 1 OF 3 EXTENDED IBIS To IBIS Members: The long text that follows is an UNOFFICIAL DRAFT designated IBIS Version 1.1X which uses IBIS Version 1.1 as the baseline and includes the BIRDS which have been approved to date. THIS MAIL WILL COME IN 3 SECTIONS. This document has been produced mostly through "cut and paste", with some minor corrections, but without concern about formatting and consistency details. This intent is to capture the approved changes and show WHERE they apply. This should serve as a reminder to all of us of what has been done so far, and should be useful to the newer members when they hear references to work already done. Bob Ross, Interconnectix, Inc. |****************************************************************************** |* ENHANCED VERSION OF IBIS VERSION 1.1 DESIGNATED "VERSION 1.1X" SHOWING |* APPROVED "BIRDS" (BIRD = BUFFER ISSUE RESOLUTION DOCUMENT). |* CHANGES FOR ADDITIONS AND REPLACEMENT DESIGNATED BY "|*" SECTIONS PLUS |* NOTES ON BIRDS AT END. |* BIRDS INCLUDED IN VERSION 1.1X ARE BIRD3, BIRD4, BIRD5.2, BIRD6.2, BIRD7.2. |* FEBRUARY 20, 1994. |****************************************************************************** |==============================================================================| | | | Statement of Intent: | | | | In order to enable an industry standard method to electronically transport | | IBIS Modeling Data between silicon vendors, simulation software vendors, and | | end customers, this template is proposed. The intention of this template is | | to specify a consistent format that can be parsed by software, allowing each | | simulation vendor to derive models compatible with their own product. | | | | One goal of this template is to represent the current state of IBIS data, | | while allowing a growth path to more complex models / methods (when deemed | | appropriate). This would be accomplished by a revision of the base | | template, and possibly the addition of new keywords or categories. | | | | Another goal of this template is to ensure that it is simple enough for | | silicon vendors and customers to use and modify, while ensuring that it is | | rigid enough for software simulation vendors to write reliable parsers. | | | | Finally, this template is meant to contain a complete description of the I/O | | elements on an entire component. Consequently, several models will need to | | be defined in each file, as well as a table that equates the appropriate | | buffer to the correct pin and signal name. | | | | Version 1.1 of this electronic template was finalized by an industry-wide | | group of simulation experts representing various companies and interests. | | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | | ASCII file format. It represents the minimum amount of I/O buffer | | information required to create an accurate IBIS model of common CMOS and | | bipolar I/O structures. Future revisions of the ASCII file will add items | | considered to be "enhancements" to Version 1.0 to allow accurate modeling | | of new, or other, I/O buffer structures. Consequently, all future | | revisions will be considered super sets of Version 1.0, allowing backward | | compatibility. In addition, as modeling platforms develop support for | | revisions of the IBIS ASCII template, all previous revisions of the | | template must also be supported. | | | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | | comments have been added for further clarification. | | | |==============================================================================| | | | General syntax rules and guidelines: | | | | 1) The content of the IBIS_ASCII file is case sensitive, except for file | | names, reserved words and keywords. Reserved words and keywords are not | | case sensitive, and file names must be all lower case. | | | | 2) The following words are reserved words and must not be used for | | any other purposes in the document: | | POWER - reserved model name, used with power supply pins, | | GND - reserved model name, used with ground pins, | | NC - reserved model name, used with no connect pins, | | NA - used where data not available. | | | | 3) File names used in the IBIS_ASCII file must only have lower case | | characters to enhance UNIX compatibility and must conform to DOS rules. | | (The length of a file name should not exceed eight plus three characters | | and it must not contain special characters which are illegal in DOS). | | | | 4) The IBIS_ASCII file must have no more than 80 characters per line. | | | | 5) Anything following the comment character is ignored and considered a | | comment on that line. The default "|" (pipe) character can be changed by | | the keyword [Comment char] to any other character. The [Comment char] | | keyword can be used throughout the file as desired. | | | | 6) Keywords must be enclosed in square brackets, [], and must start in | | column 1 of the line. | | | | 7) Valid scaling factors are: | | M = mega, k = kilo, m = milli, u = micro, n = nano, p = pico. | | When no scaling factors are specified, the appropriate base units are | | assumed. (These are Volts, Amperes, Ohms, Farads and Henries). The parser | | will look at only one alphabetic character after a numerical entry, | | therefore it is enough to use only the prefixes to scale the parameters. | | However, for clarity, it is allowed to use full abbreviations for the | | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | | allowed (e.g., 1.2345e-12). | | | | 8) The V/I data tables should use enough data points around sharply curved | | areas of the V/I curves to describe the curvature accurately. In linear | | regions there is no need to define unnecessary data points. | | | | 9) Currents are considered positive when their direction is into the | | component. | | | |==============================================================================| | Keyword: [IBIS Ver] | | Required: Yes | | Description: Used to specify the IBIS ASCII template version. This will be | | used to inform an electronic parser of the kinds of data types | | that will be present in the file. | | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | | normally on the first line of the file, but can be preceded | | by comment lines (that must begin with a "|"). | |------------------------------------------------------------------------------| [IBIS Ver] 1.1 | Used for template variations |==============================================================================| | Keyword: [Comment char] | | Required: Optional | | Description: Used to define a new comment character to replace the default | | "|" (pipe), if desired. | | Usage Rules: The new comment character which is to be defined must be | | followed by the underscore character and the letters "char". | | For example: "|_char" redundantly redefines the comment | | character to be the pipe character. The new comment character | | will be in effect only following the [Comment char] keyword. | | The following characters can NOT be used: A B C D E F G H I J | | K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o | | p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = | | Other Notes: The [Comment char] keyword can be used throughout the file, as | | desired. | |------------------------------------------------------------------------------| [Comment char] |_char |==============================================================================| | Keyword: [File name] | | Required: Yes | | Description: Used to specify the name of the IBIS file, "filename.ibs". | | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | | and no characters that are illegal in DOS). In addition, it | | must be all lower case, and use the extension ".ibs". | |------------------------------------------------------------------------------| [File name] ver1_1.ibs |==============================================================================| | Keyword: [File Rev] | | Required: Yes | | Description: Used to track the revision level of a particular .ibs file. | | Usage Rules: Revision level can be set at the discretion of the engineer | | defining the file. The following guidelines are recommended: | | 0.x silicon and file in development | | 1.x pre-silicon file data from silicon model only | | 2.x file correlated to actual silicon measurements | | 3.x mature product, no more changes likely | |------------------------------------------------------------------------------| [File Rev] 1.0 | Used for .ibs file variations |==============================================================================| | Keywords: [Date] [Source] [Notes] [Disclaimer] | | Required: Optional | | Description: Optionally used for further file clarifications. | | Usage Rules: The [Date] information is allowed to contain blanks, and be of | | any format up to 40 characters. | |------------------------------------------------------------------------------| [Date] 04/19/93 | Latest file revision date [Source] Put originator and source of information here. For example: From silicon level SPICE model at Intel, From lab measurement at IEI, Compiled from manufacturer's data book at Quad Design, etc... [Notes] This section can be used for any special notes related to the file. [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component |==============================================================================| | Keyword: [Component] | | Required: Yes | | Description: Used to mark the beginning of the IBIS description of the | | integrated circuit named after the keyword. | | Usage Rules: If the .ibs file contains data for more than one component, | | each section must begin with a new [Component] keyword. The | | length of the Component Name must not exceed 40 characters, | | and blank characters are allowed. | |------------------------------------------------------------------------------| [Component] Component Name |==============================================================================| | Keyword: [Manufacturer] | | Required: Yes | | Description: Used to clarify the component's manufacturer. | | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | | characters (blank characters are allowed, e.g., Texas | | Instruments). In addition, each manufacturer must use a | | consistent name in all .ibs files. | |------------------------------------------------------------------------------| [Manufacturer] Manufacturer's Name | e.g., Intel |==============================================================================| | Keyword: [Package] | | Required: Yes | | Description: Used to define a range of values for the default packaging | | resistance, inductance, and capacitance of the component pins. | | Sub-Params: R_pkg, L_pkg, C_pkg | | Usage Rules: Typical column must be specified. If data for the other | | columns are not available, they must be noted with "NA". | | Other Notes: If RLC parameters are available for individual pins, they can | | be listed in columns 4-6 under keyword [Pin]. The values | | listed in the [Pin] description section override the default | | values defined here. | |------------------------------------------------------------------------------| [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF |==============================================================================| | Keyword: [Pin] | | Required: Yes | | Description: Used to associate the component's I/O models to its various | | external pins and signal names. | | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | | Usage Rules: All pins on a component must be specified. The first column | | must contain the pin name. The second column, signal_name, | | gives the data book name for the signal on that pin. The | | third column, model_name, associates the I/O model for that | | pin. Each model_name must have a [Model] keyword below, | | unless it is a reserved model name (POWER, GND, or NC). | | | | Each line must contain either three or six columns. A pin | | line with three columns only associates the pin's signal and | | model. Six columns can be used to override the default | | package values (specified under [Package]) FOR THAT PIN ONLY. | | When using six columns, the headers R_pin, L_pin, and C_pin | | must be listed. If "NA" is in columns 4 through 6, the | | default packaging values must be used. | | | | Column length limits are: | | [Pin] 5 characters max | | model_name 20 characters max | | signal_name 20 characters max | | R_pin 9 characters max | | L_pin 9 characters max | | C_pin 9 characters max | |------------------------------------------------------------------------------| [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 VCC3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF |******************************************************************************* |* BIRD5.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Pin_Mapping] |* Required: Optional |*Description: Used to indicate which power and ground buses a given driver |* or receiver is connected. |* Sub-Params: gnd, pwr |*Usage Rules: Each power and ground bus is given a unique name which must |* not exceed 20 characters. The first column contains a pin |* number. Each pin number must match one of the pin numbers |* declared previously in the [Pin] section of the IBIS file. |* The second column, "gnd", designates the ground bus connection |* for that pin. Similarly, the third column, "pwr", designates |* the power bus connection. |* |* If the [Pin_Mapping] keyword is present, then the bus |* connections for EVERY pin listed in the [Pin] section must |* be given. |* |* If a pin has no connection, then both the "pwr" and "gnd" |* entries for it may by NC. |* |* Column length limits are: |* [Pin_Mapping] 5 characters max |* gnd 20 characters max |* pwr 20 characters max |*--------------------------------------------------------------------------- [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections ..... ..... ..... 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. ..... 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC ..... 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. ..... 41 NC PWRBUS2 | second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 |******************************************************************************* |******************************************************************************* |* BIRD6.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Diff_Pin] |* Required: Optional |*Description: Used to associate differential pins, their differential |* threshold voltages and differential timing delays. |* Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |*Usage Rules: Entries follow these rules: Only differential pin pairs |* are entered. The [Diff_pin] column contains a non-inverting |* pin number and the inv_pin column always contains the |* corresponding inverting pin number for output and I/O output. |* The vdiff column contains the specified differential threshold |* voltage between pins if the pins are Input or I/O Model_types. |* For Output only differential pins, the vdiff entry is 0V. |* The tdelay columns contain launch delays of the non-inverting |* pins relative to the inverting pins. The values can be either |* polarity. |*Other Notes: The output pin polarity specification in the table overrides |* the [Model] Polarity specification such that the pin in the |* [Diff_pin] column will be Non-Inverting and the pin in the |* inv_pin column will be Inverting. This convention allows |* one [Model] to be used for both pins. |* |* Column length limits are: |* [Diff_Pin] 5 characters max |* inv_pin 5 characters max |* vdiff 9 characters max |* tdelay_typ 9 characters max |* tdelay_min 9 characters max |* tdelay_max 9 characters max |* |* Each line must contain either four or six columns. If "NA" is |* entered in the vdiff, tdelay_typ or tdelay_min columns, its |* entry will be interpreted as 0V or 0ns. If "NA" appears in |* the tdelay_max column, its value will be interpreted as the |* tdelay_typ value. When using six columns, the headers |* tdelay_min and tdelay_max must be listed. Entries for the |* tdelay_min column are based on minimum magnitudes; and |* tdelay_max column, maximum magnitudes. One entry of vdiff |* regardless of its polarity is used for difference magnitudes. |*--------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max |* 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V |****************************************************************************** |==============================================================================| | Keyword: [Model] | | Required: Yes | | Description: Used to define a model, and its attributes. | | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | |* |* BIRD7.2 modification |* Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, |* Open_sink, I/O_open_sink, Open_source, I/O_open_source, |* Input_ECL, Output_ECL, and I/O_ECL model must |* | begin with the keyword [Model]. The model_name must match | | the one that is listed under the [Pin] keyword and must not | | contain more than 20 characters. An .ibs file must contain | | enough [Model] keywords to cover all of the model_names | | specified under the [Pin] keyword, except for those | | model_names which use reserved words (POWER, GND and NC). | | Model_names with reserved words are an exception and | | they do not have to have a corresponding [Model] keyword. | | C_comp is allowed to use "NA" for the min and max values only. | | Other Notes: A complete [Model] description normally contains the following | | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | | [POWER_clamp], and [Ramp]. However, some models may have only | | a subset these keywords. For example, an input structure | | normally only needs the [Voltage range], [GND_clamp], and | | possibly the [POWER_clamp] keywords. | |* |* BIRD7.2 addition |* Model_types with "open_sink" specify that the output has |* an OPEN side (the [Pullup] keyword is not used or I = 0mA |* for all voltages specified) AND the output SINKS current. |* Model_types with "open_drain" have the identical meaning and From mbs@eos.ncsu.edu Mon Feb 21 08:26:44 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22331; Mon, 21 Feb 94 08:26:44 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05341; Mon, 21 Feb 1994 11:24:57 -0500 From: mbs@eos.ncsu.edu Message-Id: <9402211624.AA05341@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: YACC/LEX parser Date: Mon, 21 Feb 94 11:24:57 EST IBISIANS, A follow up on recent email concerning a YACC/LEX parser. We have developed a YACC/LEX parser which we will put in the public domain soon. It is working and I am updating error messages and enforcing strong typing now. I have a baby due in 7 days and I hope to get it out before then for comments. Michael Steer North Carolina State University mbs@ncsu.edu From bob@icx.com Mon Feb 21 16:21:17 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25882; Mon, 21 Feb 94 16:21:17 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA10478 for ; Mon, 21 Feb 94 19:06:59 -0500 Date: Mon, 21 Feb 94 16:03:22 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03433; Mon, 21 Feb 94 16:03:22 PST Message-Id: <9402220003.AA03433@icx.com> To: ibis@vhdl.org Subject: BIRD9.1 TERMINATORS Hello IBIS members: Based on the brief discussion and recommendations at the 2/18/94 forum, BIRD9.1 is issued as a more robust terminator proposal with the additional capability of handling RC terminators and internal Series terminators. Packages containing resistor arrays or RC arrays are used in digital circuit design. It is reasonable to include IBIS formatting capablility so these elements can be entered into the database. Without such capability, the user must enter these components through individual, simulator-specific constructs. Forcing a mixed input format is undesireable. For many terminators, the POWER and GND pin attachments are left to the user. For example, a resistor array could be used for pullup attachments in an open_drain or as a terminator to ground. So the user is expected to provide most of the [Model]s based on the connection configuration. Bob Ross, Interconnectix, Inc. ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 9.1 ISSUE TITLE: Terminator Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 2 February 1994 DATE REVISED: 21 February 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Terminators are used in design and can exist as packaged parts. Therefore they are candidates for IBIS modeling. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The additional keywords, [Rpower] and [Rgnd], are proposed to represent resistors connected to power (VCC) and ground (GND) or to the voltages based on the voltage reference rules in BIRD3 as they apply to [POWER_clamp] and [GND_clamp]. A series terminator keyword [Rseries] is proposed. Finally, and AC terminator requiring both [Rac] and [Cac] to GND is proposed. |============================================================================== | Keywords: [Rgnd], [Rpower], [Rac], [Cac], [Rseries] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively. | Usage Rules: For each of these sections the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max) or C(typ), C(min), | and C(max) must be placed on a single line and must be | separated by at least one white space or tab character. | All three columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum values are not available, the reserved word | "NA" must be used indicating the R(typ) or C(typ) value by | default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND_clamp reference] | voltages, if defined, apply to [Rgnd]. [POWER_clamp reference] | voltages, if defined, apply to [Rpower]. | Either or both [Rgnd] and [Rpower] may be defined and may | co-exist with [GND_clamp], [POWER_clamp], [Pulldown], and | [Pullup] structures. | If an AC terminator is specified, then both [Rac] and [Cac] | are required. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) | [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | | [Rseries] 10Ohm NA NA | Series terminator | [Rac] 30Ohm NA NA | | | | variable C(typ) C(min) C(max) | AC terminator | | [Cac] 50pF NA NA | |============================================================================== The "Other Notes:" text within the [Model] Keyword description is changed to include references to the new keywords: | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | [POWER_clamp], [Rgnd], [Rpower], [Rseries], [Rac], [Cac], | and [Ramp]. However, some models may have only | a subset these keywords. For example, an input structure | normally only needs the [Voltage range], [GND_clamp], and | possibly the [POWER_clamp] keywords. | Note that C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A set of terminator components is useful to be formatted using IBIS because they are found as packaged components. All of the options can support (typ), (min) and (max) specifications. (1) Parallel Resistor Termination: The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI Passive Bus Terminator series would be modeled with these elements. At least two other techniques could be used in IBIS Version 1.1. The [POWER_clamp] or [GND_clamp] tables could be used (with as few as two data points each) to represent resistors. Another method could be to use R_pkg (or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a very low impedance. Processing tabular data for these purposes would be less efficient and less obvious than working with resistive elements directly. (2) RC (or AC) Termination: R_pkg (or R_pin) and C_comp can provide RC terminations. This proposal specifies [Rac] connected to [Cac] elements. This will allow packaged RC terminations which include built in clamping diodes to be modeled directly. (3) Internal Series Resistance Terminations: R_pkg (or R_pin) can be used to model internal series terminations. This proposal specifies an internal [Rseries] component. It is structured so that it would be added to the already existing R_pkg element. Diode terminators already can be modeled using IBIS Version 1.1: (4) Diode Termination: Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode Bus-Termination Arrays can be modeled using existing [POWER_clamp] and [GND_clamp] structures. The total context model is attached showing the proposed additons. BIRD9.1 expands BIRD9 by adding the RAC, CAC, and RSERIES elements |<------------------------OUTPUT and I/O Models--------------------------->| | |<-------------------INPUT Model------------------->| VOLTAGE RANGE or VOLTAGE RANGE or PULLUP REF POWER_CLAMP REF o o | | |----o----| POWER_ |---o---| | | CLAMP | | |--o--| |--o--| |--o--| \ | | | | | | / |-|RAMP |---| VI |--| | VI | \ RPOWER PACKAGE Keyword | | | | | | | | / Parameters | |-----| |-----| | |--o--| | |<----------------->| | dV/dt_r PULLUP | | | | | | | PIN | |--o-----o-------o-----o---/\/\/\--/\/\/\--UUUUUU---o--o | | | |GND_ | | RSERIES R_PKG L_PKG | | dV/dt_f PULLDOWN | | |CLAMP | | | | |-----| |-----| | | |--o--| | | | | | | | | | | | | \ | | |-|RAMP |---| VI |--| | | VI | /RGND | | | | | | | | | \ \ | |--o--| |--o--| | |--o--| / / RAC | | | | | | \ | |----o----| | |---o---| / | | | | | | o C_COMP --- o --- CAC C_PKG --- GND or --- GND or --- --- PULLDOWN REF | GND_CLAMP REF | | | | | |-------------------o----------------------------| | o GND |<-------------->| Proposed Terminator Keywords ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD partially addresses the issue related to BIRD2 regarding Termination Resistor Packs and Termination Diode Packs. It does not address Discrete two-port devices except through one partial solution with internal series terminators. The adoption of this BIRD would require some text changes in BIRD3 to reference the new keywords. ****************************************************************************** From ventham@quantic.mb.ca Thu Feb 24 15:44:43 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05780; Thu, 24 Feb 94 15:44:43 PST Received: by access.mbnet.mb.ca with UUCP id AA11226 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 24 Feb 1994 17:41:19 -0600 Received: from gauss by quantic.mb.ca (4.1/SMI-4.1) id AA01063; Thu, 24 Feb 94 17:32:05 CST Received: from euclid.quanticdomain by gauss (4.1/SMI-4.1) id AA16726; Thu, 24 Feb 94 17:32:05 CST From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9402242332.AA16726@gauss> Subject: Re: EGG 1.0 - When does will it hatch To: bracken@valhalla.performance.com Date: Thu, 24 Feb 94 17:32:06 CST Cc: ibis@vhdl.org In-Reply-To: <9402072238.AA16647@valhalla.performance.com>; from "bracken@valhalla.performance.com" at Feb 7, 94 5:38 pm X-Mailer: ELM [version 2.3 PL11] Eric, Any idea when EGG1.0 will hatch and become a real BIRD. This will of course requiring breaking the package !. Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ From bracken@valhalla.performance.com Thu Feb 24 18:59:56 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07135; Thu, 24 Feb 94 18:59:56 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA01803; Thu, 24 Feb 94 21:59:44 EST Message-Id: <9402250259.AA01803@valhalla.performance.com> To: ventham@quantic.mb.ca (Mike Ventham) Cc: ibis@vhdl.org Subject: Re: EGG 1.0 - When does will it hatch In-Reply-To: Your message of "Thu, 24 Feb 94 17:32:06 CST." <9402242332.AA16726@gauss> Date: Thu, 24 Feb 94 21:59:40 -0500 From: bracken@valhalla.performance.com Mike, I feel some stirrings in my nest right now... Look for the fledgling early next week. --Eric bracken@performance.com From bward@sugar.NeoSoft.COM Fri Feb 25 13:46:30 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17834; Fri, 25 Feb 94 13:46:30 PST Received: by sugar.NeoSoft.COM id AA23786 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Fri, 25 Feb 1994 15:44:05 -0600 Message-Id: <199402252144.AA23786@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Detail about ramp measurement Date: Fri, 25 Feb 94 15:43:57 CST Gentle ibis folks - In a closer reading of the version 1_1 spec I find that the 20% and 80% points at which we are to measure the times to get ramp rate are apparently 20 and 80 percent of the actual swing at the output node as opposed to 20 and 80 percent of the power rail voltage we are swinging to ( or from as may be ). Now I really don't think it would cause a GREAT error to use either the swing or the rail voltages in calculating the measurement points, but I may as well get it right as intended. Any advice as to which reading is the better ( read more correct or more nearly as intended )? Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From ccm!Derrick_Duehren@intelhf.intel.com Fri Feb 25 17:14:02 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19112; Fri, 25 Feb 94 17:14:02 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0paDZj-000MNoC; Fri, 25 Feb 94 17:12 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0paDf3-0001LRC; Fri, 25 Feb 94 17:17 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 25 Feb 94 17:17:41 PST Date: Fri, 25 Feb 94 17:17:41 PST From: Derrick Duehren Message-Id: <940225171741_89@ccm.hf.intel.com> To: Derrick_Duehren@ccm.hf.intel.com, IBIS@vhdl.org Subject: Change my email address (again) Text item: Text_1 I am still getting garbage in my IBIS reflector messages. Please change my email address again. email from others is coming in clear using the "ccm.jf" address below. Use: Derrick_Duehren@ccm.jf.intel.com Not: Derrick_Duehren@ccm2.jf.intel.com Sorry for the trouble. Thanks much, - Derrick ______________________________ Reply Separator _________________________________ Subject: Change my email address Author: Derrick Duehren at JFCCM2 Date: 2/16/94 10:18 AM Please change my IBIS email address from dduehren@ichips.intel.com to: Derrick_Duehren@ccm2.jf.intel.com Thanks, - Derrick From ccm!Derrick_Duehren@intelhf.intel.com Fri Feb 25 18:13:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19517; Fri, 25 Feb 94 18:13:10 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0paEV0-000MOwC; Fri, 25 Feb 94 18:11 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0paEaM-0000bTC; Fri, 25 Feb 94 18:16 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 25 Feb 94 18:16:54 PST Date: Fri, 25 Feb 94 18:16:54 PST From: Derrick Duehren Message-Id: <940225181654_102@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: How to generate a BIRD Text item: Text_1 BIRD filename convention: pbirdn_n.txt new/pending abirdn_n.txt approved dbirdn_n.txt dead -------------------------------------------------------------------------------- Howdy, 9/15/93 The following is your key to getting issues resolved in the IBIS Open Forum. It's called a "Buffer Issue Resolution Document" or "BIRD". Issues must be well thought out and clearly documented using this template to be placed on the agenda of a future IBIS Open Forum. Here's how the process works. Write up your issue and submit it to Will. Will's group will do a preliminary check for completeness and (potentially) send your BIRD back to you. If not, Will will post the issue to the reflector. Each issue must be out for review for two weeks before the Open Forum will vote on it. During that time, you will be expected to answer questions related to your BIRD. In each meeting announcement, Will will list those BIRDs that are ready for a vote at that meeting. A BIRD will be accepted if EVERYONE at the meeting agrees with it. Please note that Open Forum time will not be used for detailed BIRD review, but rather for confirming consensus. Detailed review MUST ensue during the two-week review cycle via emails. Dissenters should not wait until the Open Forum to express their opinions. So far the group has been exceedingly cooperative, achieving a 1.0 spec in only a couple of months. Hopefully this process will allow us to use time more efficiently, while maintaining the same flavor in the larger group setting. Regards, Don Telian NOTE: All text in French brackets is for explanation only and should be deleted. ---------------------------- cut here ----------------------------------- ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: {don't fill in, will be filled in by Will Hobbs for tracking} ISSUE TITLE: {one line description of your issue} REQUESTOR: {your name and company} DATE SUBMITTED: {date you sent to Will} DATE REVISED: {revision date} DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: {Place a short description of your issue here. People should be able tell by reading this if they care about this in less than 1 minute.} ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: {For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a future IBIS specification. If this is a change, state the old text and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give intended location in the specification.} ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: {There are many "experts" reviewing this document. Your reasons, analysis, and justifications must be precise and well documented, or your BIRD will be sent back to you. Use this section to show that you've done your homework, and answer all questions that will undoubtedly be asked. If your issue is a change instead of an enhancement, document how backward compatibility is to be addressed.} ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ******************************************************************************* From bracken@valhalla.performance.com Sun Feb 27 14:50:10 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09596; Sun, 27 Feb 94 14:50:10 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA05976; Sun, 27 Feb 94 17:50:21 EST Message-Id: <9402272250.AA05976@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: EGG1.0; specifying the .PKG file Date: Sun, 27 Feb 94 17:50:18 -0500 From: bracken@valhalla.performance.com All, As I write up this bird, I was intending to describe how one goes about specifying the .PKG file to use, in a .IBS file. This led me to wonder the following: 1) Should we force the .PKG file to be in the same directory as the .IBS file? 2) If not, should the specification include a "path" to the file? Possible problems: a) Filename + path may exceed 80 characters b) Differences in OS's. Unix uses "/" to separate levels of the file hierarchy, but that #&*(#^%(* MS-DOS uses the character "\". 3) If paths aren't specified, what are the rules for looking for the file? (Which directories do you look in?) Let's thrash this one out before I waste time writing something not- generally-agreeable into the bird. --Eric From bert@ibmoto.com Mon Feb 28 06:46:58 1994 Return-Path: Received: from apple.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17716; Mon, 28 Feb 94 06:46:58 PST Received: from [129.38.12.13] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA01945; Mon, 28 Feb 94 06:44:40 -0800 for ibis@vhdl.org Received: from lw.ibmoto.com by cerberus.ibmoto.com with SMTP id AA21521 (5.65c/IDA-1.5 for ); Mon, 28 Feb 1994 08:44:35 -0600 Received: by lw.ibmoto.com id AA20538 (5.65c/IDA-1.5 for ibis@vhdl.org); Mon, 28 Feb 1994 14:44:36 GMT Message-Id: <199402281444.AA20538@lw.ibmoto.com> To: ibis@vhdl.org Subject: Re: EGG1.0; specifying the .PKG file Date: Mon, 28 Feb 94 08:44:35 -0600 From: Lynn Warriner...bert@ibmoto.com...512.795.7234 Great point about differing operating systems! Also, I have full triangular matricies for 304 pin packages -- they run about 3/4 megabyte. A wee bit to big to embed in an otherwise readable file. The purpose for the "more complete" package file would be to account for package elements that affect high frequency performance (e.g., mutual inductance). Also, anyone that is interested in ground bounce studies will need these elements. Initially a default table with "typical-global" inductance and mutuals would be easy to handle in an .ibs file. Even this is better than a detail pin list that does not include mutuals. I would recommend that pointer be used to the large package table. One must now decide how to implement the pointer. One easy way around the operating system idosycrasies is to make the pointed-to file in the same directory as the .ibs file. for example: * [Package_pointer] big.pkg * Regards ... From canyimi@pcocd2.intel.com Mon Feb 28 10:44:59 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19258; Mon, 28 Feb 94 10:44:59 PST Received: from pcocd2.intel.com by hermes.intel.com (5.65/10.0i); Mon, 28 Feb 94 08:26:51 -0800 Received: from frx401 (frx401.intel.com) by pcocd2.intel.com with SMTP id AA25154 (5.65c/IDA-1.4.4 for ); Mon, 28 Feb 1994 08:26:21 -0800 From: Charles Anyimi - MPG Received: by frx401 (AIX 3.2/UCB 5.64/FMDT-RS6000) id AA18535; Mon, 28 Feb 1994 08:26:16 -0800 Message-Id: <9402281626.AA18535@frx401> Subject: PLD85C224 IBIS model To: ibis@vhdl.org Date: Mon, 28 Feb 94 8:26:16 PST X-Mailer: ELM [version 2.3 PL11] IBISers, Another fledgling IBIS person with yet another ridiculous albeit important [to this fledgling anyway] question regarding IBIS. I would like to create an IBIS model for the Intel 85C224 PLD and I was wondering if a] one already existed so that I did not have to re-invent the wheel and b] if not what else would I need to fill in the spreadsheet besides IV-curves & rise/fall times? Any help would be appreciated. Thanks, Charles -- Charles A Anyimi Intel Corporation (916) 356-4611 1900 Prairie City Road email: canyimi@pcocd2.intel.com OR MS: FM3-42 intel.caanyimi@inside.intel.com Folsom, CA 95630 LOTW: FAITH in oneself can only be obtained thourgh LOVE of oneself ====================================================================== From bward@sugar.NeoSoft.COM Mon Feb 28 13:37:06 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20567; Mon, 28 Feb 94 13:37:06 PST Received: by sugar.NeoSoft.COM id AA03261 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 28 Feb 1994 15:35:09 -0600 Message-Id: <199402282135.AA03261@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Clarification of my ramp measurement question Date: Mon, 28 Feb 94 15:35:07 CST The other day I posted a message asking about the more correct interpretation of the measurement spec for the ramp rate for an ibis model. I got back some traffic reaffirming the use of the 20% and 80% points, but the answers missed the point of the question. Let me try again. The spec says that we are to measure the ramp rate into a 50 ohm load. Because of the load there will be less than full voltage swing. I fact I would expect VERY little, if any overshoot under such a load as this. I would expect that the rising edge will settle to a voltage rather under the rail voltage, and the falling edge will settle to a voltage rather higher than the ground voltage. So the question is how are the 20% and 80% points determined? Are they 20 and 80 % of the reduced swing from ground to less than rail for rising edge and from rail to above ground to falling edge, or are they 20 and 80 % of the rail voltage even though the actual output doesn't swing that far? I suspect that there would be relatively little difference in the value of dV/dt no matter which was used, but why not get it right? Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O From speters@ichips.intel.com Mon Feb 28 14:13:51 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20825; Mon, 28 Feb 94 14:13:51 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 28 Feb 94 14:11:57 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 28 Feb 94 14:11:38 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 28 Feb 94 14:11:46 PST Message-Id: <9402282211.AA19304@xtg801.intel.com> To: ibis@vhdl.org Subject: Ramp measurment question Date: Mon, 28 Feb 1994 14:11:45 -0800 From: Stephen Peters Hello Bob -- My understanding is that you measure the 20% and 80% voltage points on the *actual* waveform, i.e. the waveform produced by the specified 50ohm load. As you pointed out, the output voltage swing is reduced by the relativly heavy load and I bet there are drivers where the output, under a 50ohm load, never even makes it to the 20% or 80% points of the no-load swing. Best Regards, Stephen Peters Intel Corp. From huq@lightning.nsc.com Mon Feb 28 14:26:57 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20920; Mon, 28 Feb 94 14:26:57 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20933 for ibis@vhdl.org; Mon, 28 Feb 94 14:25:07 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22049 for ibis@vhdl.org; Mon, 28 Feb 94 14:25:06 -0800 Received: from kural by lightning.nsc.com (4.1/SMI-4.1) id AA24845; Mon, 28 Feb 94 14:29:14 PST Date: Mon, 28 Feb 94 14:29:14 PST From: huq@lightning.nsc.com (Syed Huq) Message-Id: <9402282229.AA24845@lightning.nsc.com> To: ibis@vhdl.org Subject: Clarification of my ramp measurement question Bob, The 20 - 80% point should of the output swing levels and not the rails. Regards, Syed National Semiconductor Corp. ----- Begin Included Message ----- From bward@sugar.NeoSoft.COM Mon Feb 28 13:55:41 1994 From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Clarification of my ramp measurement question Date: Mon, 28 Feb 94 15:35:07 CST Content-Length: 1553 The other day I posted a message asking about the more correct interpretation of the measurement spec for the ramp rate for an ibis model. I got back some traffic reaffirming the use of the 20% and 80% points, but the answers missed the point of the question. Let me try again. The spec says that we are to measure the ramp rate into a 50 ohm load. Because of the load there will be less than full voltage swing. I fact I would expect VERY little, if any overshoot under such a load as this. I would expect that the rising edge will settle to a voltage rather under the rail voltage, and the falling edge will settle to a voltage rather higher than the ground voltage. So the question is how are the 20% and 80% points determined? Are they 20 and 80 % of the reduced swing from ground to less than rail for rising edge and from rail to above ground to falling edge, or are they 20 and 80 % of the rail voltage even though the actual output doesn't swing that far? I suspect that there would be relatively little difference in the value of dV/dt no matter which was used, but why not get it right? Thanks, ______________________________________________ ____________________ | | Seeking to return to | / __________________O | Bob Ward | the North Country, MN, | / /|________________ | bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O | 713.568.4122 | considering Mtn. West. | /_____________________ |___________________|_________________________| |_____________________O ----- End Included Message ----- From ccm!Derrick_Duehren@intelhf.intel.com Mon Feb 28 19:08:02 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23192; Mon, 28 Feb 94 19:08:02 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pbKmi-000MONC; Mon, 28 Feb 94 19:06 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pbKsS-0000SMC; Mon, 28 Feb 94 19:12 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 28 Feb 94 19:12:07 PST Date: Mon, 28 Feb 94 19:12:07 PST From: Derrick Duehren Message-Id: <940228191207_4@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Randy_L_Wilhelm@ccm.hf.intel.com, Jerry_Budelman@ccm.hf.intel.com Subject: IBIS Open Forum 2/18/94 Meeting Min. Text item: Text_1 Date: February 28, 1994 From: Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager (Will Hobb's IBIS Assistant) Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Will Hobbs (503) 696-4369, fax (503) 696-4210 Intel Modeling Manager Subject: Minutes from IBIS Open Forum 2/18/94 To: Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran, Mike Venthon Digital Equipment Corp. Barry Katz* High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* IBM Jay Diepenbrock* IBM-Motorola alliance Lynn Warriner*, Hoa Quoc*, John Burnett* Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong, Mei-Ling Wei MicroSim Arthur Wong*, Jerry Brown, Graham Bell National Semiconductor Syed Huq* North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell Quantic Labs Mike Ventham, Zhen Mu Racal-Redac John Berrie* Siemens Nixdorf Werner Rissiek, Olaf Rethmeier* Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the 2/18/94 meeting are indicated by * Upcoming Meetings: Date: Bridge: Res: 3/11/94 (415) 904-8944 661901 4/1/94 (415) 904-8944 661905 All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. Please note: If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org) send e-mail to ibis-request@vhdl.org. ------------------------------------------------------------------------------ 2/18/94 Meeting Agenda ---------------------- 8:00 Check-in 8:05 Intros of new IBIS participants Hobbs 8:10 Review of 1/28 minutes Hobbs Miscellany/Announcements Hobbs BIRDs Roster posted Please use CRLFs (Duehren) Opens for new issues All Treasurer's Report Hobbs 8:20 Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 (ratification at DAC?, process?) Hobbs IBIS Cookbook Hobbs Dues (shelved till DAC?) Hobbs Standard driver? Muranyi, Powell Quality of support, validation Hobbs 8:40 BIRD 6, Differential Pin Spec. Ross BIRD 7, Open Specification Completion Ross BIRD 8, Specification of V/I data monotonicity Crisafulli Egg 1, mutual pin coupling Bracken BIRD 9, Other model types Ross Ramp measurement Reid, Ross, et. al. Spice to IBIS Converter Lipa (NCSU) 9:25 Canright paper Ward Formal BNF notation (BIRD?) Reed, Harr BIRD 2, VIH, VIL Thresholds for Inputs Powell 9:35 High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs Minutes ------- 1. Intros of new IBIS participants New participant: Racal-Redac: Wants in-house tools support for IBIS (high- speed and DRC tools) There were no corrections made to last month's minutes other than the addition of the following new open forum participants from last month: Digital Equipment Corp. IBM-Motorola Alliance National Semiconductor 2. Miscellany/Announcements The current BIRDs are posted on vhdl.org. Apparently they were not posted as individual files. AR Derrick: to reorganize the BIRD files. He expects to have this done by 3/4/94. Note: Derrick now has sysop rights into vhdl.org (in addition to Randy Harr of LMC). The roster of IBIS Open Forum participants has been posted to vhdl.org. Will Hobbs and Derrick Duehren have new email addresses. The previous addresses work, but the messages come through cleaner using the following new addresses: Will_Hobbs@ccm2.jf.intel.com Derrick_Duehren@ccm.jf.intel.com 3. Opens for new issues We need help for new people developing models (see #8, below). 4. Treasurer's Report We now have a $2,600 balance. Another golden parser was sold (to Anacad). 5. Press updates EE Times of UK called Will Hobbs. So far, they have only played telephone tag. An EDA group (Open Model Forum) being formed to establish a universal interface for logical models (EDA/Semi vendors getting together) met for the first time this month and referenced IBIS as a model for how to establish standards! 6. Progress toward enlisting new IC vendors Will Hobbs is actively working with a new ASIC vendor (in a proprietary relationship, so Intel can't say who, yet). 7. IBIS 2.0 (ratification at DAC?, process?) We are trying to identify a good day at DAC to ratify IBIS 2.0. The DAC schedule is not out yet. Will suggested that a steering committee meet face-to-face before the DAC convention for a roll-up of the BIRDs into 2.0. This roll-up could then be distributed to the IBIS participants for review before the DAC conference. It was suggested that we hold the IBIS meetings in the evenings at DAC as "Birds of a feather" sessions. 8. IBIS Cookbook Lynn Warriner: We need an introductory toolkit (cookbook). Access to Kellee's package was helpful. The Intel version is nearly done. Some of the text, such as "how to do measurements and extract the IBIS info" and "how to correlate against SPICE", is generic and can be extracted. A sanitized version as a starting place for an open IBIS cookbook should be ready in about a month. Kellee volunteered to help newcomers as well as help extract the open version of the cookbook from Intel's proprietary version. National, DEC, IBM, and Motorola all asked for the cookbook. IBM needs it now. They have an internal commitment to have the IBIS models out by 2/28/94. 9. Dues None for now. We will reevaluate them if the need arises. Later in the meeting, Kellee proposed limiting "official voting" rights to those who have paid for the Golden Parser (GP). Those that don't really need it. Silicon vendors, for example, could consider it a one-time dues payment. In other words, dues can be the GP fee, and you get the GP free. Official votes would come into play in case of dissension. AR Will: post list of current GP license holders. Also post info on the GP itself. What it is, how to get it. We will close on this issue in the next open forum meeting. 10. Standard driver, quality of support, validation Two topics we originally intended to treat separately are so intertwined that the discussion continually bounced back and forth. The basic questions are: 1. Is there a standard circuit that all simulators use? 2. If not, how can we trust the results of the simulations after we release the models? Related to this, if there is no standard model and no standard simulator, how do silicon vendors know if the V/I tables they put in IBIS models are correct? How can the models be verified? Arpad prefers to not have his driver referred to as the "standard". Kellee: Arpad's original model is not the standard, but a good starting point. It needs tweaks, as others have done. Lynn: If you use VCCS (Volt Control Current Source) instead of resistors, you end up with exponential response instead of linear. It feels like we need a mutually agreed upon simulation engine to verify integrity. This would help validate that the numbers that are extracted are correct. Maah: I don't think we (the Forum) are ready for selecting one simulator as a standard, as we are all competitors. Who's tool is chosen as the standard? Every vendor has responsibility to ensure the accuracy of their own tool. Lynn: HyperLynx created a derivative of Arpad's model, Quad tuned theirs for IBIS, other simulators will probably do it different ways. Kumar: There are many ways to implement the standard model. We may want to solve different problems, too, which affects how you implement the model. Lynn: "We need a standard way of verifying V/I tables. I probably surfaced this mess last time. I can generate V/I tables off simulation and need a way to validate them." Will: "The topologies shown in the Overview document are what Intel uses: a couple of simple ones and a complex one to "break the model". Within Intel, we use several different simulators and cross-check the results." Will is aware of at least 5 vendors' simulators used at various Intel sites. Kellee: We need a suite of simulations and models to validate simulators and verify IBIS compliance among simulators. We need to publish the test suite, publish the expected results, and state that companies can self- certify, such as "Output results correlate closely with the expected data." Leave it to simulator vendors to determine what "closely" means. Q: Is there a test suite? A: Intel published one, although only for one type of model. IBIS model suppliers can publish the tests and results. The results should "closely follow," with interpretation left to individual users. Customers can see for themselves how closely the tool meets the IBIS form. AR Will: See if Intel/Don Telian can release waveforms for the simulations in the Overview doc. The data should end up in Postscript format so the curves can be universally accessed. John Burnett: We need to specify which level of IBIS each company is certified to. Can we publish a list of vendors that have self-certified, passed test suites? AR Everyone: If, and when you self-certify (run the test suite), send email to Derrick_Duehren@ccm.jf.intel.com so Derrick can add the information to the Participants Roster document. Include what IBIS version level you support. Lynn: I want to push IBIS back into our entire product line, 100's of parts. I can feel comfortable in near term using a specific simulator, but long-term, I need a standard simulator. A prime element in standardizing IBIS is a method for proving compliance. 11. Other Questions: Q: Regarding simulation at specific temperatures (0C, 50C, and 100C), are we obligated to use these temperatures, or can we use whatever we specify our parts at (-20, 50, 120, or whatever)? Is there a standard? A: No - use your own min/max temperatures. Kellee, Stephen: Use whatever temperatures give you the desired min and max results. We need a BIRD to clear up this set of questions. AR Lynn: Create a new BIRD. Clarify that temperature used should reflect the mix/ max of the component. AR Derrick: Send BIRD.TXT to Lynn (Done). Q: What about dual voltage parts? A: Stephen: Intel uses two separate models. 12. BIRD 6, Differential Pin Spec. Bob Ross summarized the changes from 6.1, as documented in BIRD 6.2. We may want to expand this BIRD later. Vdiff specifies difference of output values, pdelay now has polarity associated with it. If positive, the positive output is delayed with regard to negative output. Pin package delays can be speced separately from buffer delay differences. Kellee: Simulators need to know when to launch the ramp to achieve the correct delay. Bob: That's why we changed to tdelay instead of tskew; this actually refers to launch delay rather than output delay. Vote taken: BIRD 6.2 was unanimously approved. 13. BIRD 7, Open Specification Completion Bob Ross summarized BIRD 7.2. We discussed the differences in methodology between BIRDs 7.2 and 2.1. Are they two ways to do the same thing? Worst case, there will be some overlap. Jon Powell was not present to comment on BIRD 2.1. Vote taken: BIRD 7.2 was unanimously approved. 14. BIRD 8, Specification of V/I data monotonicity Kellee summarized, discussed what we should require to be monotonic in the I/V tables: BIRD 8 proposes that user's choose voltage or current. Feedback from the forum leaned in favor of requiring the voltage axis to be monotonic. Arpad has recently seen a case where the current was non- monotonic; i.e., a single voltage has two different current values. AR Kellee: Repropose monotonic voltage and reopen discussion via email. 15. Egg 1, mutual pin coupling No discussion. 16. BIRD 9, Other model types Bob Ross briefly discussed the intent of Bird 9, not looking for assent yet. By adding resistors as model types, we can eliminate unnecessary processing of curves when a resistor would do. As yet, the BIRD does not address series (two-port) resistors. AR Bob Ross: Add series resisters to BIRD 9. (Done) 17. Ramp measurement No discussion. 18. Spice to IBIS Converter No discussion. Steve Lipa was not present to comment. From Steve's email messages, good progress has been made. Steve plans to release his converter to public domain. Ramp is not yet incorporated. Steve is looking for SPICE models for testing the converter. 19. Canright paper No discussion. 20. Formal BNF notation (BIRD?) Bob Ross did some work on the BNF parser. Would like others to pick up on it. Update: Steve Lipa is also working on the parser. Bob posted his first attempt to the reflector. 21. BIRD 2, VIH, VIL Thresholds for Inputs No discussion. 22. High freq. and EMI No discussion. 23. Phased turn-on/off of multiple devices No discussion. 24. Wrap-up, Next Meeting Plans The next meeting is 3/11/94.