From owner-ibis Mon Jun 1 10:01:21 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA07514 for ; Mon, 1 Jun 1998 10:01:20 -0700 (PDT) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail11.digital.com (8.8.8/8.8.8/WV1.0e) with ESMTP id MAA12471 for ; Mon, 1 Jun 1998 12:57:57 -0400 (EDT) Received: by SBUAMAZKO2AE with Internet Mail Service (5.0.1458.49) id ; Mon, 1 Jun 1998 12:58:12 -0400 Message-ID: <71EEA9EA5129D1118EA30000F840EBF1537A53@sbuamapko3bc.eng.pko.dec.com> From: Greg Edlund To: "Breda, Kathy" , "Chang, Vincent" , "Edlund, Greg" , "Engelmann, Fawn" , "Fitzgerald, Greg" , "Haller, Robert" , "Heilbrunn, Bruce" , "LaFlamme, Peter" , "Ross, Bob" , "Sayre, Ed" , "Stiegler, Harvey" Cc: "'ibis@vhdl.org'" Subject: IBIS Accuracy Subcommittee Minutes 5/21/98 Date: Mon, 1 Jun 1998 12:56:45 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id KAA07515 IBIS Accuracy Subcommittee Minutes Thursday, May 21, 1998 Held at Digital Equipment's PKO3 building, 129 Parker St., Maynard, MA. Attendees Greg Edlund, Digital Equipment (chair) Fawn Engelmann, EMC Bob Haller, Digital Equipment Bruce Heilbrunn, Stratus Computer Peter LaFlamme, Fairchild Semiconductor Harvey Stiegler, Texas Instruments (by phone) Next meeting is Thursday, June 18, 1998 from 3:00 to 5:00 pm at Stratus Computer in Marlboro, MA. MILESTONES The test board milestone has slipped again. July, 1998: Post the IBIS Model Test Board to the web September 18, 1998: Distribute the first draft of the IBIS Accuracy Specification October 1998: PCB West Conference, IBIS Summit, and first IBIS Class February 1999: Present the IBIS Accuracy Specification at DesignCon99 EDITING 1. Scope The subcommittee reviewed the pre-rough draft document that Bob Haller is writing. Bob has compiled the material generated by the subcommittee placed it in a Word document as a means of recording and benchmarking our progress. It is the consensus of the subcommittee that the Scope section of the specification is in good enough shape for us to focus on the following sections. We agreed to add to the Introduction some language that addresses the general topic of "uncertainties." Differences between simulators has been a long-standing source of concern. While we will not directly address this topic in this version of the specification, we feel we need to make the reader aware that it exists. Another source of concern is that most sample parts that may be used to verify model accuracy are really "random samples," i.e. little or nothing is known about the semiconductor processing conditions in their lot of origin. Footnote related to [Waveform] keywords: Discussion with Bob Ross following the subcommittee meeting revealed an important fact that we had not previously understood. We were under the impression that the [Rising Waveform] and [Falling Waveform] keywords were added to IBIS to cover more advanced driver types such as GTL, which can employ a feedback circuit for edge rate control. For this reason, we wanted to steer away from the [Waveform] keywords because we felt they would add too much complexity for us to handle in revision 1.0 Bob stated that the two primary purposes of these keywords are as follows: 1) to allow a simulator to adjust its internal ramp stimulus to better fit actual waveforms under a specified load and 2) to more accurately represent the phase relationship between gate waveforms for the pull-up and pull-down devices in a push-pull driver. With this understanding, it is necessary to review the [Waveform] keywords for possible inclusion into the scope of the IBIS Accuracy Specification 1.0. 2. Required Measurements Peter La Flamme identified a component which we can use as an example open drain component for verifying our test loads. This component is Fairchild's GTLP8T306, an 8-bit LVTTL to GTL bus transceiver. The output buffer does not employ a feedback circuit and would be well-suited for use in the IBIS Accuracy Specification 1.0. SPICE models are available. There are three essential sub-sections under Required Measurements: test loads for transient waveforms, capacitance, and IV curves. We discussed test loads thoroughly during the last meeting; this topic seems to be well under control for now. The goal of this meeting was to decide on what measurements to require for capacitance and IV curves. We discussed two possible approaches to capacitance measurements. One would be to choose the pins which the modeling engineer expects to yield the minimum and maximum capacitance and measure these only. The other would be to measure the capacitance of every pin in a die-less package; obviously this method isn't of much use with high pin-count-packages. The ideal situation would involve predictions made by a 3-D field solver, although HOW the modeling engineer gets the capacitance data is not really relevant to the specification as it is defined today. The important point is that the modeling engineer measures capacitance and documents the measurements. A more general topic arose related to coverage of each unique I/O cell design. Do we require a complete set of transient waveform, capacitance, and IV curve measurements for each unique I/O cell design present in an IC? This is quite feasible for a simple part such as a 244 buffer, but it is totally unrealistic for an ASIC that may have a hundred or more I/O cells in its library. We did not close on the topic of Required Measurements during this meeting. We will attempt to carry on the discussion electronically so we can continue to make progress toward our milestones. Bruce Heilbrunn requested that we table the topic of requiring 10 Ohm and 100 Ohm test loads until a later date. He is looking for an IBIS level 1.1 driver that exhibits a good fit between simulations and lab measurements at 50 Ohms but a poor fit at extreme impedances. 3. Measurement Techniques We did not discuss measurement techniques at this meeting. The June and July meetings will be dedicated to this topic. 4. Metrics We did not discuss comparison metrics at this meeting. The August meeting will be dedicated to this topic. RELATED ACTIVITIES IBIS Accuracy Test Board - The test board is in routing at EMC. When routing is complete, we will circulate 1:1 layer plots for review prior to going for etch. IBIS Developers Tool Kit - No progress to report. IBIS Cookbook - No progress to report. HOMEWORK All - Continue and close the discussion of Required Measurements via email. Greg Edlund - Finish routing of the IBIS Accuracy Test Board. Fawn Engelmann - Finish routing of the IBIS Accuracy Test Board. Bob Haller - Finish Required Measurements section. ---------- Greg Edlund, Principal Engineer Server Product Development Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (978) 493-4157 voice (978) 493-0941 FAX greg.edlund@digital.com From owner-ibis Tue Jun 2 07:18:01 1998 Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA28186 for ; Tue, 2 Jun 1998 07:18:01 -0700 (PDT) Received: from ixstar.ih.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id JAA05902; Tue, 2 Jun 1998 09:38:49 -0500 Received: by ixstar.ih.lucent.com (SMI-8.6/EMS-1.4 sol2) id JAA02940; Tue, 2 Jun 1998 09:14:25 -0500 From: ushman@lucent.com Received: from ixstar2.ih.lucent.com by ixstar.ih.lucent.com (SMI-8.6/EMS-1.4 sol2) id JAA02937; Tue, 2 Jun 1998 09:14:24 -0500 Received: by ixstar2.ih.lucent.com (SMI-8.6/EMS-L sol2) id JAA09005; Tue, 2 Jun 1998 09:14:24 -0500 Date: Tue, 2 Jun 1998 09:14:24 -0500 Message-Id: <199806021414.JAA09005@ixstar2.ih.lucent.com> Original-From: rcu2@ixstar.ih.lucent.com To: ibis@vhdl.org Subject: unsubscribe Content-Type: text Unsubscribe From owner-ibis Tue Jun 2 09:46:43 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA01007 for ; Tue, 2 Jun 1998 09:46:43 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id JAA06711; Tue, 2 Jun 1998 09:42:51 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id JAA06188; Tue, 2 Jun 1998 09:42:49 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA05430; Tue, 2 Jun 98 09:42:48 PDT Date: Tue, 2 Jun 98 09:42:48 PDT Message-Id: <9806021642.AA05430@bob> To: ibis@eda.org Subject: BIRD52 - [Driver Schedule] Clarifications To IBIS Group: BIRD52 is issued to clarify some [Driver Schedule] details for IBIS Version 3.1. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 52 ISSUE TITLE: [Driver Schedule] Clarifications REQUESTER: Arpad Muranyi, Intel DATE SUBMITTED: 6/1/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There are a few editorial items under the [Driver Schedule] keyword section of the IBIS specification which need to be changed for clarity and correctness. 1) The current IBIS 3.0 specification does not specify where the [Driver Schedule] keyword must be placed in an IBIS model. 2) The current IBIS 3.0 specification only allows one number for each of the Rise_on_dly, Rise_off_dly, Fall_on_dly, Fall_off_dly parameters under the [Driver Schedule] keyword. It is not obvious how minimum and maximum values can be handled for these parameters. 3) The wording of the second sentence under the usage rules section is awkward and misleading. 4) The last example, the "bus-hold stage" is redundant in the presence of BIRD 49. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) Under the [Driver Schedule] keyword, add a new paragraph to the Usage Rules section (indicated by asterisks "*") to clarify the correct location of the [Driver schedule] keyword. |*Usage Rules: The [Driver schedule] keyword establishes a hierarchical order |* between models and should be placed under the [Model] which |* acts as the top level model. The scheduled models are then |* referenced from the top level [Model] by the [Driver Schedule] |* keyword. 2) Under the "Other Notes" section of the [Driver Schedule] keyword, add a new paragraph (indicated by asterisks "*") to explain how this can be done using the waveform tables. |* Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, |* Fall_off_dly parameters are single value parameters, so typical |* minimum and maximum conditions cannot be described with them |* directly. In order to account for those effects, one can |* refer to the fastest waveform table with the delay number and |* then insert an appropriate amount of horizontal lead in |* section in those waveforms which need more delay. 3) The wording of the second sentence under the usage rules section should be changed to the wording shown in this BIRD (indicated by asterisks "*"). | The [Driver Schedule] table consists of five columns. The |* first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe 4) Delete the last example. Therefore the entire [Driver Schedule] section should be as follows: |============================================================================= | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. |*Usage Rules: The [Driver schedule] keyword establishes a hierarchical order |* between models and should be placed under the [Model] which |* acts as the top level model. The scheduled models are then |* referenced from the top level [Model] by the [Driver Schedule] |* keyword. | | The [Driver Schedule] table consists of five columns. The |* first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and | Falling_off_dly. All values are referenced to 0 seconds for | the start of the rising transition and 0 seconds for the start | of the falling transition. All delays must be equal to or | greater than 0. | | The Rise_on_dly entry gives the beginning of the low-to-high | transition. The Rise_off_dly entry may be given to end the | low-to-high transition and initiate a high-to-low transition | during the rising cycle. Similarly, the Fall_on_dly gives | the beginning of the high-to-low transition. The Fall_off_dly | may be given to end the high-to-low transition and initiate a | low-to-high transition. | | Use 'NA' when no transition is applicable. For each model, | the transition sequence must be complete, i.e., it must start | and end at the same state. | | Only the [Pulldown] and [Pullup] tables and transition data | [Ramp] or [Rising Waveform] and [Falling Waveform] data are | used from each model that is referenced. The [Model] keyword | provides the specification information, [GND Clamp] and [POWER | Clamp], and C_comp, regardless of information contained in | the referenced models. | | It is recommended that a "golden waveform" for the device | consisting of a [Rising Waveform] table and a [Falling | Waveform] table be supplied under the [Model] keyword to | serve as a reference for validation. | | No [Driver Schedule] may reference a model which itself has | within it a [Driver Schedule] table keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. | |* Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, |* Fall_off_dly parameters are single value parameters, so typical |* minimum and maximum conditions cannot be described with them |* directly. In order to account for those effects, one can |* refer to the fastest waveform table with the delay number and |* then insert an appropriate amount of horizontal lead in |* section in those waveforms which need more delay. |----------------------------------------------------------------------------- [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: 1) In the process of making a model with the [Driver Schedule] keyword I began to study the IBIS 3.0 specification for details. I found out that the location of the keyword was not specified in the specification and left room for various interpretations. Based on conversations with Bob Ross I found out that it was intended to be placed inside a [Model] section which acts as a top level model in terms of the model hierarchy. 2) In the same process, I also found that the Rise_on_dly, Rise_off_dly, Fall_on_dly, Fall_off_dly parameters are single value parameters which cannot describe the varying amounts of delays of the typical, minimum, and maximum conditions. Suspecting a possible oversight I discussed this matter with Bob Ross and I found out that the members of the IBIS Open Forum did have discussions on this subject when the [Driver Schedule] keyword was developed. The format of these parameters were deliberately chosen to be the way they are. The meeting minutes outline the solution described in this BIRD, but for some reason the suggested solution did not make it into the specification. 3) During our conversations Bob Ross pointed out to me that the wording of the second sentence of the usage rules was awkward and should be fixed since this work is already being written. 4) Bob Ross also asked me to request the removal of the last example in this BIRD since BIRD 49 is in progress and covers the bus-hold features much more accurately. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: None ****************************************************************************** From owner-ibis Tue Jun 2 10:12:14 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA01430 for ; Tue, 2 Jun 1998 10:12:13 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA09112; Tue, 2 Jun 1998 10:08:21 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id KAA06466; Tue, 2 Jun 1998 10:08:19 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA05511; Tue, 2 Jun 98 10:08:18 PDT Date: Tue, 2 Jun 98 10:08:18 PDT Message-Id: <9806021708.AA05511@bob> To: ibis@eda.org Subject: REVISED BIRD52 - [Driver Schedule] Clarifications To IBIS Group: (PLEASE DELETE PREVIOUS BIRD52. This is being resent to change a reference from BIRD49 to BIRD50) BIRD52 is issued to clarify some [Driver Schedule] details for IBIS Version 3.1. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 52 ISSUE TITLE: [Driver Schedule] Clarifications REQUESTER: Arpad Muranyi, Intel DATE SUBMITTED: 6/1/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There are a few editorial items under the [Driver Schedule] keyword section of the IBIS specification which need to be changed for clarity and correctness. 1) The current IBIS 3.0 specification does not specify where the [Driver Schedule] keyword must be placed in an IBIS model. 2) The current IBIS 3.0 specification only allows one number for each of the Rise_on_dly, Rise_off_dly, Fall_on_dly, Fall_off_dly parameters under the [Driver Schedule] keyword. It is not obvious how minimum and maximum values can be handled for these parameters. 3) The wording of the second sentence under the usage rules section is awkward and misleading. 4) The last example, the "bus-hold stage" is redundant in the presence of BIRD 50. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) Under the [Driver Schedule] keyword, add a new paragraph to the Usage Rules section (indicated by asterisks "*") to clarify the correct location of the [Driver schedule] keyword. |*Usage Rules: The [Driver schedule] keyword establishes a hierarchical order |* between models and should be placed under the [Model] which |* acts as the top level model. The scheduled models are then |* referenced from the top level [Model] by the [Driver Schedule] |* keyword. 2) Under the "Other Notes" section of the [Driver Schedule] keyword, add a new paragraph (indicated by asterisks "*") to explain how this can be done using the waveform tables. |* Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, |* Fall_off_dly parameters are single value parameters, so typical |* minimum and maximum conditions cannot be described with them |* directly. In order to account for those effects, one can |* refer to the fastest waveform table with the delay number and |* then insert an appropriate amount of horizontal lead in |* section in those waveforms which need more delay. 3) The wording of the second sentence under the usage rules section should be changed to the wording shown in this BIRD (indicated by asterisks "*"). | The [Driver Schedule] table consists of five columns. The |* first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe 4) Delete the last example. Therefore the entire [Driver Schedule] section should be as follows: |============================================================================= | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. |*Usage Rules: The [Driver schedule] keyword establishes a hierarchical order |* between models and should be placed under the [Model] which |* acts as the top level model. The scheduled models are then |* referenced from the top level [Model] by the [Driver Schedule] |* keyword. | | The [Driver Schedule] table consists of five columns. The |* first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and | Falling_off_dly. All values are referenced to 0 seconds for | the start of the rising transition and 0 seconds for the start | of the falling transition. All delays must be equal to or | greater than 0. | | The Rise_on_dly entry gives the beginning of the low-to-high | transition. The Rise_off_dly entry may be given to end the | low-to-high transition and initiate a high-to-low transition | during the rising cycle. Similarly, the Fall_on_dly gives | the beginning of the high-to-low transition. The Fall_off_dly | may be given to end the high-to-low transition and initiate a | low-to-high transition. | | Use 'NA' when no transition is applicable. For each model, | the transition sequence must be complete, i.e., it must start | and end at the same state. | | Only the [Pulldown] and [Pullup] tables and transition data | [Ramp] or [Rising Waveform] and [Falling Waveform] data are | used from each model that is referenced. The [Model] keyword | provides the specification information, [GND Clamp] and [POWER | Clamp], and C_comp, regardless of information contained in | the referenced models. | | It is recommended that a "golden waveform" for the device | consisting of a [Rising Waveform] table and a [Falling | Waveform] table be supplied under the [Model] keyword to | serve as a reference for validation. | | No [Driver Schedule] may reference a model which itself has | within it a [Driver Schedule] table keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. | |* Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, |* Fall_off_dly parameters are single value parameters, so typical |* minimum and maximum conditions cannot be described with them |* directly. In order to account for those effects, one can |* refer to the fastest waveform table with the delay number and |* then insert an appropriate amount of horizontal lead in |* section in those waveforms which need more delay. |----------------------------------------------------------------------------- [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: 1) In the process of making a model with the [Driver Schedule] keyword I began to study the IBIS 3.0 specification for details. I found out that the location of the keyword was not specified in the specification and left room for various interpretations. Based on conversations with Bob Ross I found out that it was intended to be placed inside a [Model] section which acts as a top level model in terms of the model hierarchy. 2) In the same process, I also found that the Rise_on_dly, Rise_off_dly, Fall_on_dly, Fall_off_dly parameters are single value parameters which cannot describe the varying amounts of delays of the typical, minimum, and maximum conditions. Suspecting a possible oversight I discussed this matter with Bob Ross and I found out that the members of the IBIS Open Forum did have discussions on this subject when the [Driver Schedule] keyword was developed. The format of these parameters were deliberately chosen to be the way they are. The meeting minutes outline the solution described in this BIRD, but for some reason the suggested solution did not make it into the specification. 3) During our conversations Bob Ross pointed out to me that the wording of the second sentence of the usage rules was awkward and should be fixed since this work is already being written. 4) Bob Ross also asked me to request the removal of the last example in this BIRD since BIRD 50 is in progress and covers the bus-hold features much more accurately. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: None ****************************************************************************** From owner-ibis Wed Jun 3 15:43:11 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA02443 for ; Wed, 3 Jun 1998 15:43:10 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA00866; Wed, 3 Jun 1998 15:39:18 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA19714; Wed, 3 Jun 1998 15:39:16 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA06584; Wed, 3 Jun 98 15:39:14 PDT Date: Wed, 3 Jun 98 15:39:14 PDT Message-Id: <9806032239.AA06584@bob> To: ibis@eda.org Subject: BIRD46.1 - Relaxation of File Name Restriction To IBIS Committee: BIRD46.1 changes the file name length limit from 8 characters to 20 characters for IBIS Version 3.1. Bob Ross Interconnectix/Mentor Graphics ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 46.1 ISSUE TITLE: Relaxation of some IBIS model file name restrictions. REQUESTOR: Matthew Flora and Kellee Crisafulli, HyperLynx DATE SUBMITTED: 4 Dec 1997, 2 June 1998 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The file names of IBIS models are currently limited to 8 characters in length (not counting the mandatory .ibs extension) and "must conform to DOS rules". We propose that the length limit be expanded to 20 characters. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Item 3 in Section 3 of the IBIS 3.0 specification, General Syntax Rules and Guidelines, currently states: 3) File names used in the 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 that are illegal in DOS). We propose that this item be changed to state: 3) File names used in the IBIS file must only have lower case characters to enhance UNIX compatibility. File names should have a basename of no more than twenty characters followed by a period, followed by a file name extension of no more than three characters. File names must not contain characters which are illegal in DOS. The [File Name] keyword in section 4 of the IBIS 3.0 specification, File Header Information, currently states: |============================================================================= | Keyword: [File Name] | Required: Yes | Description: Specifies 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". |----------------------------------------------------------------------------- We propose that this keyword be changed to state: |============================================================================= | Keyword: [File Name] | Required: Yes | Description: Specifies the name of the IBIS file. | Usage Rules: | The file name must not be longer than 24 characters (including | the extension). The file name must not use characters that | are illegal in DOS. In addition, the file name must be all | lower case, and use the extension ".ibs". | The file name must be the actual name of the file. |----------------------------------------------------------------------------- The [Package Model] keyword in section 5 of the IBIS 3.0 specification, Component Description, currently states: |============================================================================= | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. Spaces | are allowed in the name. The name should include the company | name or initials to help ensure uniqueness. The simulator | will search for a matching package model name as an argument | to a [Define Package Model] keyword in the current IBIS file | first. If a match is not found, the simulator will look for a | match in an external .pkg file. If the package model is in a | separate .pkg file, it must be kept in the same directory as | the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that | component. The specification permits .ibs files to contain | [Define Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models that | have the same name. |----------------------------------------------------------------------------- We propose that this keyword be changed to state: |============================================================================= | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model to be used for the | component | Usage Rules: The package model name is limited to 40 characters. Spaces | are allowed in the name. The name should include the company | name or initials to help ensure uniqueness. The simulator | will search for a matching package model name as an argument | to a [Define Package Model] keyword in the current IBIS file | first. If a match is not found, the simulator will next look | for a match in an external .pkg file. If the matching package | model is in an external .pkg file, it must be located in the | same directory as the .ibs file. The file names of .pkg files | must follow the rules for file names given in section 3, | General Syntax Rules and Guidelines. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that | component. The specification permits .ibs files to contain | [Define Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models that | have the same name. |----------------------------------------------------------------------------- ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We believe that engineers have moved beyond DOS as an engineering platform. Therefore, we would like to lift some of the restrictions that were imposed by DOS. We already encounter IBIS model files which violate the 8.3 length rule. Extending the allowed length of file names gives model creators the opportunity to use more descriptive file names. The choice of 64 characters was arbitrary, however names longer than that may not display well in applications. The limit should not be increased to more than 255, since that would be illegal under Windows NT, Windows 95, and some versions of UNIX. Allowing the use of periods throughout file names is common in the majority of file systems and is another means of making file names more descriptive. Since some operating systems (Windows NT 4.0 for one) still ignore the case of characters in file names, file names should still be required to be all lower-case. As far as we are aware, DOS has the largest set of characters which are not allowed in file names. Continuing to disallow all of those characters (bar one - the period) should ensure that IBIS model file names are still valid on all common platforms. BIRD 46.1 modifications: The suggested new file name length limit was reduced to 20 characters (down from 64) and the suggestion of allowing periods in file names was dropped. Also, the BIRD was expanded to include any filename related to an IBIS model. The IBIS Open Forum found that allowing file names to be 64 characters long could cause certain lines in an IBIS file to violate the 80 character line length limit. Reducing the file name length to 20 characters is meant to avoid this problem. The IBIS Open Forum felt that allowing file names to contain periods would complicate the rule unnecessarily. So that provision was dropped. The committee felt that for consistency, the wording of the BIRD needed to be expanded to cover every file name related to IBIS models. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From owner-ibis Thu Jun 4 14:33:43 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA26275 for ; Thu, 4 Jun 1998 14:33:42 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id OAA25223; Thu, 4 Jun 1998 14:30:18 -0700 (PDT) Message-Id: <3.0.5.32.19980604143012.008f13a0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 14:30:12 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Bird 52 comment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS, We read through Bird 52 and thought it looked reasonable with a one major exception. This bird needs an example. It is complex enough that without an example it will be very difficult to insure future model builders and simulators all do the same thing. HyperLynx Staff, Kellee Steve Matt ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 14:46:25 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA26637 for ; Thu, 4 Jun 1998 14:46:25 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id OAA00517; Thu, 4 Jun 1998 14:43:01 -0700 (PDT) Message-Id: <3.0.5.32.19980604144259.009464d0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 14:42:59 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Bird 48 comments from HyperLynx Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS, We had a meeting and discussed bird 48 with our engineering team with the following feedback: 1) The re-use of the MODEL keyword confuses usage of this bird to the point that we will vote NO unless a new keyword like SUB_MODEL is used. We found no one in the office could understand how to use the add model concept without a group discussion of what it meant. The biggest confusion is that sometimes a MODEL is a real model and sometimes it is a sub-model that isn't a real model. I understand it was easier to write this way but it is very confusing. To fix it just use a new keyword SUB_MODEL. The add model then is ADD SUB_MODEL which is much clearer about what is happening. 2) If the above keyword change is made then we should re-use "model spec" and not add the new "sub-model spec" syntax. This is consistent with the re-use of VI tables etc. 3) It is essential that the SUB_MODEL keyword explicitly define which keywords can be used. The present documentation requires considerable reading to determine what is allowed. This should be in more bullet like form that is easy to speed read. We feel this is a minor change and will fully support this bird with the above changes. We will oppose this bird without this change on the basis that it is too difficult to understand. Kellee Matt Steve ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 14:55:05 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA26660 for ; Thu, 4 Jun 1998 14:55:05 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id OAA04146; Thu, 4 Jun 1998 14:51:41 -0700 (PDT) Message-Id: <3.0.5.32.19980604145142.008eea90@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 14:51:42 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Bird 49 comments from HyperLynx Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS, We did an engineering review of Bird 49 with the following comments: 1) We will vote YES only if BIRD 48 is change to use SUB_MODEL since this bird requires BIRD 48 syntax. 2) While static and triggered forms of this BIRD seem well defined and straight forward the clocked mode looks very poorly defined and we will VOTE NO unless the clocked mode is removed or the documentation is improved to define how the clock relates to the pulse table. We were not able to determine how the clock timing relates to the pulse table. 3) There was a large amount of confusion when reading the "Analysis path that led to spec" section. It looks like some information critical to understanding this bird is embedded in this section and mixed with some obsolete syntax. The bird cannot be used without filter some information out of this section and putting it in the main syntax for the bird e.g. the usage rules for I=f(v-v_pulse(t)) is not shown in the actual bird. We feel this bird is a no go until the usage wording is added to the specification section. Best wishes: Kellee Matt Steve ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 15:28:00 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA27331 for ; Thu, 4 Jun 1998 15:27:58 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id OAA24201; Thu, 4 Jun 1998 14:53:05 -0700 (PDT) Received: from mastt.cadence.com(192.203.57.5) by mailgate.cadence.com via smap (mjr-v1.2) id xma896997183.024192; Thu, 4 Jun 98 14:53:03 -0700 Received: from pc-venu (d1922035835 [192.203.58.35]) by mastt.cadence.com (8.8.5/8.7.3) with SMTP id OAA11488; Thu, 4 Jun 1998 14:53:15 -0700 (PDT) Message-Id: <3.0.32.19980604145007.00916b10@mastt.cadence.com> X-Sender: venu@mastt.cadence.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 04 Jun 1998 14:50:16 -0700 To: Anders.Ekholm@al.etx.ericsson.se (Anders Ekholm) From: Venugopal Pattabhiramaiyengar Subject: Re: Can't do T-LINE? Cc: ibis@eda.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Anders Ekholm wrote: > Excuse me, but wouldn't that mean that you only will > be able to use one T-line segment as a package > modell ? > > That would imply that the package is uniform, and > I would suppose that most packages are not. To get > an accurate model you need multiple T-line segment > models. Is that not possible in IBIS 3.0 ? Multiple T-line segments are possible in the package description of IBIS 3.0. They are also available in the electrical board description. Regards, Stephen Peters Intel Corp. > > Best Regards /Anders Ekholm > Ericsson Telecom > > > > > From owner-ibis@server.vhdl.org Wed May 20 04:46 MET 1998 > > From: bobr@emicx.mentorg.com (Bob Ross) > > Date: Tue, 19 May 98 19:03:38 PDT > > To: crokusek@viewlogic.com, ibis@eda.org > > Subject: Re: Can't do T-LINE? > > Cc: bobr@emicx.mentorg.com > > Mime-Version: 1.0 > > X-Status: $$$$ > > X-UID: 0000001041 > > > > Chris: > > > > The L, C, and R parameters are given as CORRESPONDING per unit length values. > > These are multiplied by Len to produce the total distributed values for the > > exact length of T-line that you want. > > > > Whenever Len is not equal to zero, the section is interpreted as > > a distributed section (not a lumped section). > > > > The T-line relationships still hold: > > > > Zo = sqrt(L/C) > > TD = Len * sqrt(LC) > > > > So the electrical information is available for a T-line of whatever length > > you want. > > > > Best Regards, > > Bob Ross > > Interconnectix/Mentor Graphics > > > > > > > Sender: crokusek@qdt.com > > > Date: Tue, 19 May 1998 17:56:15 -0700 > > > From: Chris Rokusek > > > To: ibis@eda.org > > > Subject: Can't do T-LINE? > > > > > ( I am reposting this question in hopes of a more helpful response ) > > > > > Hi All, > > > > > Concerning [Path Description] section in Ver 3.x of .ibs... > > > > > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not > > > meters) such that a distributed T-LINE model cannot be built with the > > > proper physical length. > > > > > ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL > > > ** > > > > > Is this an oversight or am I not understanding the parameters? > > > > > Best Regards, > > > > > Chris Rokusek > > > Viewlogic Systems > > > > > > > > > > > |=========================================================================== == > > > | Keyword: [Path Description] > > > | Required: Yes > > > | Description: This keyword allows the user to describe the connection > > > | between the user accessible pins of a part and the pins > > > of the > > > | ICs mounted on that part. Each pin to node connection > > > is > > > | divided into one or more cascaded "sections", where each > > > | section is described in terms of it's L/R/C per unit > > > length. > > > | The Fork and Endfork subparameters allow the path to > > > branch to > > > | multiple nodes, or another pin. A path description is > > > | required for each pin whose signal name is not "GND", > > > "POWER" > > > | or "NC". > > > | > > > | Board Description and IC Boundaries: > > > | > > > | In any system, each part interfaces with another part at > > > some > > > | boundary. Every part model must contain the components > > > | necessary to represent the behavior of the part being > > > modeled > > > | within its boundaries. The boundary definition depends > > > upon > > > | the parts being represented by the model. > > > | > > > | For CARD EDGE CONNECTIONS such as a SIMM or a PC > > > Daughter > > > | Card plugged into a SIMM Socket or Edge Connector, the > > > | boundary should be at the end of the board card edge > > > pads as > > > | they emerge from the connector. > > > | > > > | For any THROUGH-HOLE MOUNTED PART, the boundary will be > > > at the > > > | surface of the board on which the part is mounted. > > > | > > > | SURFACE MOUNTED PART models end at the outboard end of > > > their > > > | recommended surface mount pads. > > > | > > > | If the board level component contains an UNMATED > > > CONNECTOR, > > > | the unmated connector will be described in a separate > > > file, > > > | with its boundaries being as described above for the > > > | through-hole or surface mounted part. > > > | > > > | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node > > > | Usage Rules: Each individual connection path (user pin to node(s)) > > > | description begins with the [Path Description] keyword > > > and a > > > | path name, followed by the subparameters used to > > > describe the > > > | path topology and the electrical characteristics of each > > > | section of the path. The path name must not exceed 40 > > > | characters, blanks are not allowed, and each occurrence > > > of the > > > | [Path Description] keyword must be followed by a unique > > > path > > > | name. Every signal pin (pins other than POWER, GND or > > > NC) > > > | must appear in one and only one path description per > > > [Begin > > > | Board Description]/[End Board Description] pair. Pin > > > names do > > > | not have to appear in the same order as listed in the > > > [Pin > > > | List] table. The individual subparameters are broken up > > > into > > > | those that describe the electrical properties of a > > > section, > > > | and those that describe the topology of a path. > > > | > > > | Section Description Subparameters: > > > | > > > | The Len, L, R, and C subparameters specify the length, > > > the > > > | series inductance and resistance and the capacitance to > > > ground > > > | of each section in a path description. > > > | > > > | Len The physical length of a section. Lengths are > > > given > > > | in terms of arbitrary 'units'. Any non-zero > > > length > > > | requires that the parameters that follow must be > > > | interpreted as distributed elements by the > > > simulator. > > > | L The series inductance of a section, in terms of > > > | 'inductance/unit length'. For example, if the > > > total > > > | inductance of a section is 3.0 nH and the length > > > of > > > | the section is 2 'units', the inductance would > > > be > > > | listed as L = 1.5 nH (i.e. 3.0 / 2). > > > | C The capacitance to ground of a section, in terms > > > of > > > | capacitance per unit length. > > > | R The series DC (ohmic) resistance of a section, > > > in > > > | terms of ohms per unit length. > > > | > > > | Topology Description Subparameters: > > > | > > > | The Fork and Endfork subparameters denote branches from > > > the > > > | main pin-to-node or pin-to-pin connection path. The > > > Node > > > | subparameter is used to reference the pin of a component > > > or > > > | board as defined in a .ibs or .ebd file. The Pin > > > subparameter > > > | is used to indicate the point at which a path connects > > > to a > > > | user visible pin. > > > | > > > | Fork This subparameter indicates that the sections > > > | following (up to the Endfork subparameter) are > > > part > > > | of a branch off of the main connection path. > > > This > > > | subparameter has no arguments. > > > | Endfork This subparameter indicates the end point of a > > > branch. > > > | For every Fork subparameter there must be a > > > | corresponding Endfork subparameter. As with the > > > Fork > > > | subparameter, the Endfork subparameter has no > > > | arguments. > > > | Node reference_designator.pin > > > | This subparameter is used when the connection > > > path > > > | connects to a pin of another, externally defined > > > part. > > > | The arguments of the Node subparameter indicate > > > the > > > | pin and reference designator of the external > > > | component. The pin and reference designator > > > portions > > > | of the argument are separated by a period > > > ("."). The > > > | reference designator is mapped to an external > > > | component description (another .ebd file or .ibs > > > file) > > > | by the [Reference Designator Map] Keyword. Note > > > that > > > | a Node MUST reference a model of a passive or > > > active > > > | component. A Node is not an arbitrary > > > connection > > > | point between two elements or paths. > > > | Pin This subparameter is used to mark the point at > > > which > > > | a path description connects to a user accessible > > > pin. > > > | Every path description must contain at least one > > > | occurrence of the Pin subparameter. It may also > > > | contain the reserved word NC. The value of the > > > Pin > > > | subparameter must be one of the pin names listed > > > in > > > | the [Pin List] section. > > > | > > > | Using The Subparameters to Describe Paths: > > > | > > > | A section description begins with the Len subparameter > > > and > > > | ends with the slash (/) character. The value of the > > > Len, L, > > > | R, and C subparameters and the subparameter itself are > > > | separated by an equals sign (=); whitespace around the > > > equals > > > | sign is optional. The Fork, Endfork, Node and Pin > > > | subparameters are placed between section descriptions > > > (i.e., > > > | between the concluding slash of one section and the > > > 'Len' > > > | parameters that starts another). The arguments of the > > > Pin and > > > | Node subparameter are separated by white space. > > > | > > > | Specifying a Len or L/R/C value of zero is allowed. If > > > | Len = 0 is specified, then the L/R/C values are the > > > total for > > > | that section. If a non-zero length is specified, then > > > the > > > | total L/R/C for a section is calculated by multiplying > > > the > > > | value of the Len subparameter by the value of the L, R, > > > or C > > > | subparameter. However, as noted below, if a non-zero > > > length > > > | is specified, that section MUST be interpreted as > > > distributed > > > | elements. > > > | > > > | Legal Subparameter Combinations for Section > > > Descriptions: > > > | > > > | A) Len, and one or more of the L, R and C > > > subparameters. If > > > | the Len subparameter is given as zero, then the L/R/C > > > | subparameters represent lumped elements. If the Len > > > | subparameter is non-zero, then the L/R/C subparameters > > > | represent distributed elements and both L and C must be > > > | specified, R is optional. > > > | > > > | B) The first subparameter following the [Path > > > Description] > > > | keyword must be 'Pin', followed by one or more section > > > | descriptions. The path description can terminate in a > > > Node, > > > | another pin or the reserved word, NC. > > > | > > > | Dealing With Series Elements: > > > | > > > | A discrete series R or L component can be included in a > > > path > > > | description by defining a section with L=0 and the > > > proper R or > > > | L value. A discrete series component can also be > > > included in > > > | a path description by writing two back to back node > > > statements > > > | that reference the same component (see the example > > > below). > > > | Note that both ends of a discrete, two terminal > > > component MUST > > > | be contained in a single [Path Description]. Connecting > > > two > > > | separate [Path Description] with a series component is > > > not > > > | allowed. > > > |--------------------------------------------------------------------------- -- > > > | > > > | An Example Path For a SIMM Module: > > > | > > > [Path Description] CAS_2 > > > Pin J25 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u21.15 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u22.15 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u23.15 > > > | > > > | A Description Using The Fork and Endfork Subparameters: > > > | > > > [Path Description] PassThru1 > > > Pin B5 > > > Len = 0 L=2.0n / > > > Len = 2.1 L=6.0n C=2.0p / > > > Fork > > > Len = 1.0 L = 1.0n C= 2.0p / > > > Node u23.15 > > > Endfork > > > Len = 1.0 L = 6.0n C=2.0p / > > > Pin A5 > > > | > > > | A Description Including a Discrete Series Element: > > > | > > > [Path Description] sig1 > > > Pin B27 > > > Len = 0 L=1.6n / > > > Len = 1.5 L=6.0n C=2.0p / > > > Node R2.1 > > > Node R2.2 > > > Len = 0.25 L=6.0n C=2.0p / > > > Node U25.6 > > > | > > > |============================================================================= > > > > > > From owner-ibis Thu Jun 4 15:37:04 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA27525 for ; Thu, 4 Jun 1998 15:37:03 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id PAA22072; Thu, 4 Jun 1998 15:33:39 -0700 (PDT) Message-Id: <3.0.5.32.19980604153340.00940380@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 15:33:40 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Bird 50 (Bus hold) comments from HyperLynx Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS, Results of our engineering meeting on Bird 50: 1) Must be changed to use SUB_MODEL concept (Bird 48). 2) First paragraph incorrectly mentions the dynamic clamp which is another bird. 3) The section describing how it is used is incomplete. There should be something that shows how the SUB_MODEL is defined. (i.e. add model). 4) There should be a full example model. HyperLynx staff Kellee Steve Matt Side note: I have mentioned this several times before: WE MUST HAVE EXAMPLE MODELS. The fact that Bird 52 is needed is a clear example of why example models should be required for any bird. i.e. Where driver schedule was to be used is not defined. I would like to see an archive on the IBIS site for each bird that has an associated example if appropriate for that bird. If it is important enough to be added to the specification it deserves an example. (Kellee) ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 16:06:14 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA27903 for ; Thu, 4 Jun 1998 16:06:14 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id QAA21272; Thu, 4 Jun 1998 16:02:20 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id QAA01672; Thu, 4 Jun 1998 16:02:19 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA07612; Thu, 4 Jun 98 16:02:18 PDT Date: Thu, 4 Jun 98 16:02:18 PDT Message-Id: <9806042302.AA07612@bob> To: ibis@eda.org Subject: Forwarded: Re: Bird 48 comments from HyperLynx Forgot to copy send to the reflector. Bob Date: Thu, 4 Jun 98 16:00:35 PDT Message-Id: <9806042300.AA07603@bob> To: kellee@hyperlynx.com Subject: Re: Bird 48 comments from HyperLynx Kelly and All: Thank you for your comments. As an author trying to deal with the functionality as it has been evolving, I am somewhat blind to the clarity of the presentation. You have some very good points. A [Sub Model] keyword has some similarities with a subroutine or a .SUBCKT that is called or invoked from the mainline program. That is the primary concept. So I tend to agree with your comments. I had been thinking similar thoughts. We can discuss this further at the meeting along with other comments and concerns. I welcome comments from others as well. Bob Ross Interconnectix/Mentor Graphics > Date: Thu, 04 Jun 1998 14:42:59 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Bird 48 comments from HyperLynx > Hi IBIS, > We had a meeting and discussed bird 48 with our > engineering team with the following feedback: > 1) The re-use of the MODEL keyword confuses usage of this > bird to the point that we will vote NO unless a new keyword > like SUB_MODEL is used. We found no one in the office > could understand how to use the add model concept without > a group discussion of what it meant. The biggest confusion > is that sometimes a MODEL is a real model and sometimes > it is a sub-model that isn't a real model. I understand > it was easier to write this way but it is very confusing. > To fix it just use a new keyword SUB_MODEL. > The add model then is ADD SUB_MODEL which is much clearer about > what is happening. > 2) If the above keyword change is made then we should re-use > "model spec" and not add the new "sub-model spec" syntax. > This is consistent with the re-use of VI tables etc. > 3) It is essential that the SUB_MODEL keyword explicitly define > which keywords can be used. The present documentation requires > considerable reading to determine what is allowed. This should > be in more bullet like form that is easy to speed read. > We feel this is a minor change and will fully support this bird with > the above changes. We will oppose this bird without this change on > the basis that it is too difficult to understand. > Kellee > Matt > Steve > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- -------- End of Forwarded Message From owner-ibis Thu Jun 4 16:09:06 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA28065 for ; Thu, 4 Jun 1998 16:09:05 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id QAA21476; Thu, 4 Jun 1998 16:05:11 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id QAA01709; Thu, 4 Jun 1998 16:05:11 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA07615; Thu, 4 Jun 98 16:05:10 PDT Date: Thu, 4 Jun 98 16:05:10 PDT Message-Id: <9806042305.AA07615@bob> To: ibis@eda.org, kellee@hyperlynx.com Subject: Re: Bird 49 comments from HyperLynx Kellee and All: Thank you for your comments. Arpad and I have also been recently struggling with the Clocked mode. So we may have to come up with a different proposal. Thanks, Bob Ross Interconnectix/Mentor Graphics > Date: Thu, 04 Jun 1998 14:51:42 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Bird 49 comments from HyperLynx > Hi IBIS, > We did an engineering review of Bird 49 with the > following comments: > 1) We will vote YES only if BIRD 48 is change to use SUB_MODEL > since this bird requires BIRD 48 syntax. > 2) While static and triggered forms of this BIRD seem well defined > and straight forward the clocked mode looks very poorly defined > and we will VOTE NO unless the clocked mode is removed or the > documentation is improved to define how the clock relates to > the pulse table. We were not able to determine how the clock > timing relates to the pulse table. > 3) There was a large amount of confusion when reading the "Analysis > path that led to spec" section. It looks like some information > critical to understanding this bird is embedded in this section and > mixed with some obsolete syntax. The bird cannot be used without > filter some information out of this section and putting it in the > main syntax for the bird e.g. the usage rules for I=f(v-v_pulse(t)) > is not shown in the actual bird. > We feel this bird is a no go until the usage wording is > added to the specification section. > Best wishes: > Kellee > Matt > Steve > > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 16:14:08 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA28074 for ; Thu, 4 Jun 1998 16:14:08 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id QAA21753; Thu, 4 Jun 1998 16:10:14 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id QAA01813; Thu, 4 Jun 1998 16:10:13 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA07621; Thu, 4 Jun 98 16:10:12 PDT Date: Thu, 4 Jun 98 16:10:12 PDT Message-Id: <9806042310.AA07621@bob> To: ibis@eda.org, kellee@hyperlynx.com Subject: Re: Bird 50 (Bus hold) comments from HyperLynx To All: Again, thank you for your comments and corrections and suggestions for example a FULL example with each BIRD. We will be discussing these at the next meetings. Bob Ross Interconnectix/Mentor Graphics > Date: Thu, 04 Jun 1998 15:33:40 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Bird 50 (Bus hold) comments from HyperLynx > Hi IBIS, > Results of our engineering meeting on Bird 50: > 1) Must be changed to use SUB_MODEL concept (Bird 48). > 2) First paragraph incorrectly mentions the dynamic clamp which is another bird. > 3) The section describing how it is used is incomplete. There should be > something that shows how the SUB_MODEL is defined. (i.e. add model). > 4) There should be a full example model. > HyperLynx staff > Kellee > Steve > Matt > Side note: > I have mentioned this several times before: > WE MUST HAVE EXAMPLE MODELS. The fact that Bird 52 is needed is a clear > example of why example models should be required for any bird. > i.e. Where driver schedule was to be used is not defined. > I would like to see an archive on the IBIS site for each bird > that has an associated example if appropriate for that bird. > If it is important enough to be added to the specification it deserves > an example. > (Kellee) > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- From owner-ibis Thu Jun 4 17:56:31 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA29810 for ; Thu, 4 Jun 1998 17:56:31 -0700 (PDT) Received: (from kellee@localhost) by mail.nwlink.com (8.8.8/8.8.8) id RAA15777; Thu, 4 Jun 1998 17:53:07 -0700 (PDT) Message-Id: <3.0.5.32.19980604175308.008f13a0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Jun 1998 17:53:08 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Bird 42 review by HyperLynx Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS, We also reviewed the current-waveform bird 42 and found the following: 1) After several revisions this is a well described bird (kudos to Kumar). 2) It seems to address the crowbar currents related to single pin not the die operating currents since it ties all the currents to an output pin. This would work for a buffer chip but would not address current spikes in the core of something like a video controller or CPU since they are not related to an output pin switching. It also doesn't deal with currents that result from PLL's on chip. (I hope we correctly interpreted the specification but we didn't see anything but output pin related currents). 3) DC Sessions has indicated that crow-bar current is for the most part not a critical problem with today's CMOS. (If I am paraphrasing correctly). Granted there is some overlap between an output changing and core logic but this bird seems to tie all the current changes to a pin change. 4) Crow-bar current is also handled to with the wave-tables. If the assumption that today's CMOS doesn't present significant crow-bar current is valid we recommend this bird be killed or modified to handle core logic currents and ignore crow-bar currents. The concept seems like it could be applied to core logic currents perhaps with multiple tables that can be used to indicate the clock frequency internally for which they apply. e.g. Table 1 applies if the PLL is set to 200Mhz, table 2 applies for 300Mhz, Table 3 applies at 400Mhz etc. Kumar: I know you have worked very hard on this bird. I would very much like to see this bird reformed slightly into a core logic current specification. What do you think? Best wishes Kellee ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Fri Jun 5 06:25:05 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA13527 for ; Fri, 5 Jun 1998 06:25:04 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id GAA18010 for ; Fri, 5 Jun 1998 06:21:40 -0700 (PDT) Received: from gda.cadence.com(158.140.106.10) by mailgate.cadence.com via smap (mjr-v1.2) id xma897052899.017992; Fri, 5 Jun 98 06:21:39 -0700 Received: from pc-bobv.cadence.com (d15814010553 [158.140.105.53]) by gda.Cadence.COM (8.8.8/8.8.5) with SMTP id JAA13294 for ; Fri, 5 Jun 1998 09:21:34 -0400 (EDT) Message-Id: <3.0.5.32.19980605091429.007dbbe0@gda.cadence.com> X-Sender: bobv@gda.cadence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 Jun 1998 09:14:29 -0400 To: ibis@eda.org From: Bob Votapka Subject: Unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" unsubscribe Bob Votapka VP Consulting Services Service Development 978-262-6445 bobv@cadence.com From owner-ibis Fri Jun 5 08:45:59 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA15825; Fri, 5 Jun 1998 08:45:58 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA13576; Fri, 5 Jun 1998 15:42:34 GMT Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA26330; Fri, 5 Jun 1998 08:42:33 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id IAA12113; Fri, 5 Jun 1998 08:42:33 -0700 (PDT) Message-Id: <199806051542.IAA12113@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: EIA/Summit Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jun 1998 08:42:32 -0700 From: Stephen Peters D A C I B I S S U M M I T M E E T I N G DATE: Thursday, June 18, 1998 TIME: 9 AM - Afternoon LOCATION: San Francisco Marriott Hotel, next to Moscone Center where the Design Automation Conference (DAC) is being held ROOM: Pacific 4-1 LUNCH: Refreshments and Lunch will be provided. AGENDA: The main focus is to continue face-to-face technical discussions on IBIS Version 3.1 ratification issues. We may ratify IBIS Version 3.1 at this time. Also, we will be electing EIA IBIS Open Forum Officers for 1997-1998. The formal agenda will be developed and published before the meeting. CALL FOR PRESENTATIONS: We are open for presentations on any subject and may solicit a few presentations. We are also open to technical presentations related to the recent BIRDs and IBIS Version 3.0 features. Contact Stephen Peters regarding your presentation: Presenter: Title: Estimated Time: We would like you to provide handouts for the meeting (about 25) and also have an electronic copy. CALL FOR ATTENDEES: Please let Stephen Peters know if you are planning to attend so we have an estimate on food requirements. CONTACT: Stephen Peters sjpeters@ichips.intel.com - ------- End of Forwarded Message ------- End of Forwarded Message From owner-ibis Tue Jun 9 17:55:20 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA04387 for ; Tue, 9 Jun 1998 17:55:19 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id AAA28428 for ; Wed, 10 Jun 1998 00:51:53 GMT Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id RAA02064 for ; Tue, 9 Jun 1998 17:51:53 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id RAA02093; Tue, 9 Jun 1998 17:51:52 -0700 (PDT) Message-Id: <199806100051.RAA02093@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org Subject: EIA/IBIS Open Forum Minutes 6/5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jun 1998 17:51:48 -0700 From: Stephen Peters DATE: 6/09/98 SUBJECT: 6/05/98 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1998 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Norio Matsui, Raj Raghuram Cadence Design (& UniCAD) C. Kumar, Don Telian, Patrick Riffault, Craig Lewis, Greg Fitzgerald, Paul Galloway, Patrick Dos Santos, Catherine Weiss, Alain Tribaudot, Geoffrey Ellis Cypress (Bruce Wenniger) Digital Equipment Corp. Jeff Chu, Greg Edlund*, Bob Haller Hewlett Packard (EEsof, etc.) Karl Kachigan, Henry Wu, Paul Gregory High Design Technology Razvan Ene HyperLynx Kellee Crisafulli*, Matthew Flora* Incases Olaf Rethmeier*, Scott Jacobson, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Will Hobbs, Prakash Radhakrishnan, Mohammed Hawana Columbia, SC (formerly NCR) Dave Moxley Mentor Graphics (Zeelan, Bob Ross*, George Opsahl, Mark Noneman, Interconnectix, etc.) Tom Dagostino, Karine Loudet, Jean Oudinot, Manuel De Almeida, Stephane Rousseau, Neven Orhanovic Mitsubishi Hoang Nguyen, Tam Cao Motorola (Ron Werner) National Semiconductor Syed Huq*, Cheng-Yang Kao, John Goldie, Ikchang Song North East Systems Associates Edward Sayre, Kathy Breda (NESA) NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Symbios Logic Larry Barnes* Texas Instruments Thomas Fisher, Harvey Stiegler, Vincent Chang, Jean-Claude Perrin, Peter Forstner Thomson-CSF Jean-Marc Claveau, Laurent Duzaic, Saverio Lerose, Benoit Meyniel, Jean Lefebvre Viewlogic Jon Powell, Chris Rokusek*, Guy de Burgh, Gary Mandel VeriBest Ian Dodd, David Weins, Ian Gabbitas VLSI Technology D.C. Sessions* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1998: Actel Eric Tardif, Emmonvelle Gaudin Aerospatiale Lionel Dreux, Claude Huet Alcatel (Bell, Espace, etc.) John Fitzpatrick, W. Temmerman, Laure Bessettes, Jean-Claude Pourtau, Daniel Peron ALS Design Yves Mouquet Ansoft Eric Bogatin Apple Fred Floresca, Danny Itani Apteq Design Systems Dan FitzPatrick Avanti Nik Bannov CERN Olivier Clere, Jean-Michel Sainson, Rudi Zurbroken Compaq Shariq Rahma Crucial Technology Rathna Reddy EIA Patti Rusher EMC Fawn Engelmann, Fabrizio Zanella* ENST, Paris Jean-Jacques Charlot European CAD Standardization Adam Morawiec Intitiative (ECSI) Fairchild Semiconductor Peter LaFlamme H.A.S Electronics Haruny Said Intracon Design Ltd. Derek Laidlaw Philips Semiconductor Todd Andersen Scottish Electronics Robert Easson Manufacturing Center (SEMC) Seagate Vanessa Howard SGS-Thomson Philippe Lefevre Siemens Gerald Bannert, Bernhard Unger, Christian Marot, Miguel Hernandez, Gil Russell Symmetry Andy Hughes Tektronix Nassrin Ghahyasi Ultratest International Chris O'Connor Xilinx Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode June 18, 1998 IBIS Summit Meeting - No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Larry Barnes of Symbios Logic indicated that his company is joining the EIA IBIS Open Forum and he will be the representative. Larry is involved in high speed system modeling for SCSI controllers and fiber channel. He is interested in accurate and robust IBIS models for high speed systems. Fabrizio Zanella is a Signal Integrity Engineer with EMC, but has been with Teradyne in the past. He has been active in the IBIS Users Group and is heading a group to propose a connector model specification. Fabrizio discussed what has happened to date. (This is reported under IBIS EAST USERS GROUP ACTIVITIES below.) MEMBERSHIP UPDATE AND TREASURER'S REPORT Based on recent information from Patti Rusher, three payments for parsers and two membership payments have not been recorded at EIA. REVIEW OF MINUTES AND AR'S No corrections were noted. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Syed Huq reported that the Digital entry in the a membership roster has been updated. Bob Ross noted that a few incidental references to IBIS appeared in several articles while discussing other issues. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross noted that a generic Accelerated Graphics Port AGP4X IBIS Model for Intel is located at http://www.agpforum.org and embedded PowerPC IBIS models from IBM at http://www.chips.ibm.com/products/embedded/library/techlib.html OPENS FOR NEW ISSUES None. (Bob Ross on BIRD52) INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross indicated no further report. He still expects formal ratification at the IEC meeting in September, 1998. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuit (IMIC) - Bob Ross stated that the deadline for comments is June 10, 1998. Version 1.1 of the standard found under the "Outline of I/O Interface Project Group at: http://tsc.eiaj.or.jp - IEC 93/67/NP IBIS and EMC Simulation - Bob Ross got a note from Jean Claude Perrin that work is progressing. Jean Claude plans another Experts meeting prior to the September 1998 IEC meeting. - JC-16.2 Subcommittee: Modeling and Test - D.C. Sessions noted that the group number has been changed from JC-16B to JC-16.2. He had just had a meeting with a JEDEC memories group (JC -42) regarding the memory road map. Simulation models are needed for DRAMS, and the semiconductor vendors need EDA tools for signal integrity analysis. Bob Ross mentioned that the IBIS Summit meeting is planned in December, 1998 and co-located with the JEDEC meeting to promote interaction. IBIS (EAST) USERS GROUP MEETINGS Greg Edlund reported that the IBIS Users Group meeting held May 28. 1998 at Stratus Computer discussed three topics: (1) Fabrizio Zanella has formed a small group to create a connector model BIRD. Fabrizio reported that the team consists of Fabrizio (EMC), John Ellis (Berg), Mark Gailus (Teradyne), Gus Panella (Molex), Eric Bogatin (Ansoft), and Kellee Chrisafulli (Hyperlynx). The group is just beginning its discussions and is considering starting with the rejected BIRD31.3. Discussions also include 2D versus 3D mdoels, Tee, Pi or T-line sections, return paths, and accuracy issues. Simulator vendor solutions were also also discussed. Bob Ross indicated that the committee needs to approach this from a more generic, vendor neutral point of view. The group itself is holding teleconference meetings. (2) The Model Accuracy subcommittee gave its report to date that has already been sent to the IBIS reflector. Bob Haller introduced the text at the meeting. (3) For the education activities to take place, Ed Sayre needs more help. Ed will assist, but he cannot create the class by himself. Bob Ross stated that an IBIS Summit meeting is still planned (on Thursday, October 15, 1998) in Massachusetts at the same time as the PCB Conference East. Fabrizio suggested that Stratus Computer has facilities on site that would be suitable for this meeting and located about five miles from the PCB Conference East site. DESIGN AUTOMATION CONFERENCE (DAC) IBIS SUMMIT MEETING & EIA BOOTH Bob Ross reported that the will be held on Thursday, June 18, 1998 at the Marriott Hotel next to Moscone Hall in San Francisco, California where DAC is being held. Stephen Peters reported several sign-ups and two presentations. Arpad Muranyi will discuss future simulation tool needs for emerging technologies for about 45 minutes. Syed Huq will discuss IBIS Model Validation using s2ibis on a Linux system for about 15 minutes. Bob stated that election of offices will occur for the positions at the end of these minutes. Also Bob will spend about 20 minutes on a general IBIS Committee Review. The remainder of the program will be of a technical orientation on the recent set of BIRDs that either need to be approved or rejected. However, only BIRDs that have been mailed out two weeks in advance will be candidates for a final vote. We should reach general agreement on the others to issue the final BIRDs in preparation for a vote. Bob noted that we could proceed to closing Version 3.1 without the pending BIRDs (but with the ibischk3 parser completion). D.C. Sessions expressed the need to get Version 3.1 approved. Bob noted that EDA tool vendors are already working on Version 3.1 features. The alternative is to delay everything until all of the new approved BIRDs have been written in IBIS Version 3.1 and the ibischk3 parser includes these new features. This could delay adoption further. The sense was to proceed as fast as possible to get a Version 3.1 release out, with a Version 3.2 release following. Concern was expressed that this would create confusion, but Bob noted that since IBIS has always supported upward compatibility, this should not be a problem for any model developer. We are just considering some new features. Bob stated that a number of new BIRDs will need to be issued just to close IBIS Version 3.1 based on answers to questions raised during the ibischk3 and ebdchk3 parser development. Bob gave some examples including setting the the maximum pin name lengths for component pins to five or eight, setting the reference designator length, and others. Bob will work on the Agenda pending the rest of the meeting and issue it next week for the IBIS Summit Meeting. Stephen Peters issued a meeting reminder. Several more people indicated that they are attending. AR - Bob Ross send out Agenda for the IBIS Summit Meeting. Per the AR of last meeting, Stephen Peters wrote a one page handout on the EIA IBIS Open Forum with some general contacts. He sent it out to the officers and got some comments. Stephen will finish it and sent the Word document to Patti Rusher. AR - Stephen Peters sent EIA IBIS Open Forum Fact Sheet to Patti Rusher. Kellee Chrisafulli suggested that IBIS T-shirts sold at the EIA booth might be popular. Bob did not have time to pursue this, nor did he know if EIA could or would do this. Kellee indicated that he will pursue this idea directly with Patti. EDITING COMMITTEE Bob Ross got some additional editorial corrections from Matthew Flora. Bob will include them in the UNOFFICIAL IBIS ver3_1d.ibs document along with any other approved BIRD information. The BNF AR remains. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 (an IBIS Version 3.0 ratification AR). BIRD44 - INTERPRETATION OF MIN/MAX/WEAK/STRONG DATA Bob Ross indicated no progress. AR - Andy Ingraham to issue BIRD44.1 with the changes and extensions noted in the March 13, 1998 IBIS Open Forum meeting minutes. IBISCHK2+ (VER 2.1.15) PROGRESS Chris Rokusek reported no progress since last meeting. VERSION 3.1 PARSER DEVELOPMENT Bob Ross sent in some more problems from an EBD file. Bob stated that the ibischk3 Version 3.0.1 parser is in excellent shape and near completion. the ebdchk3 Version 3.0.1 parser needs more work, but is very useful even in its current state. We may learn more from actual .ebd files. Larry Barnes stated that he may be able to supply some BGA package information. Stephen Peters asked, and Bob responded that the general criteria for completion is when the reported bugs have been fixed. Bob will want to pay Atul Agarwal at that time. Atul also will work on BIRDs not included in the original agreement and receive payment in chunks as more parser license sales occur. On the next revision, Bob requested BUG27 and BUG28 be addressed. Bob suggested only one executable, ibischk3, with an -ebd option for .ebd checking. Matthew Flora suggested that the type of check could be detected automatically based on the extension (.ibs or .ebd). Bob noted that Atul suggested and plans to include a test for .pkg only files. Currently, a .ibs file is needed with a reference to the package model in the .pkg file to do ,pkg testing. Bob expects another release, but has no specific date. COOKBOOK No report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora indicated no more activity since last meeting. He has privately commented on some models. Bob Ross repeated the general information, and Matthew will still issue a writeup. For general information, the contact person is: Matthew Flora, HyperLynx mbflora@hyperlynx.com AR - Matthew Flora issue to the IBIS reflector a short writeup on the IBIS IBIS Model Review committee. BIRD42.3 - MODELING CURRENT WAVEFORMS Based on the suggestion, the specific discussion was deferred to the IBIS Summit Meeting on June 18, 1998. D.C. Sessions asked for a specific design/test case that the current spec is unable to handle before the group proccedes with more discussion of this bird. BIRD48.3 - ADD MODEL BIRD49.2 - ADD MODEL DYNAMIC CLAMPS BIRD50.2 - ADD MODEL BUS HOLD Kellee Chrisafulli stated that the his company reviewed these BIRDs and were confused with the presentation. They suggested that a new model keyword named [Sub Model] and used for the special purpose added models would clarify the usage. The specific keywords and subparameters under [Sub Model] would be listed. In the top-level model, the [Add Model] keyword would be changed to [Add Sub Model]. The impact of this change would apply to all three BIRDs. Bob Ross supported these suggestions. Regarding BIRD49.2, Kellee commented that he thought the triggered and static modes were clear. However, he did not understand the clocked mode or its application. Arpad Muranyi commented on the clocked mode. It was intended to support a dynamic clamp being turned off by a clock pulse. D.C. Sessions questioned whether full timing simulation information is needed in IBIS, since this has already been outside the scope of IBIS. Bob Ross indicated that more work needs to be done on clocked mode to address the concerns and also questioned whether it was necessary for the standard. Regarding BIRD50.2, Kellee's main comment was that a full example is needed. This comment applies to other BIRDs as well. Bob asked whether the other EDA tool vendors generally could support the extensions proposed in these BIRDs. The response was positive. Bob commented that more discussions will occur at the IBIS Summit Meeting. We cannot officially vote on them at the meeting since they will not have been out for two weeks. But we should reach agreement on what to include in IBIS that we can go forward with parser development and with the preparation of the final BIRDs for voting. Bob will issue revised BIRDs in preparation for the IBIS Summit Meeting discussions. AR - Bob Ross issue BIRD48.4, BIRD49.3, and BIRD50.3 capturing some of the comments to date. BIRD46.1 - RELAXATION OF SOME IBIS FILE NAME RESTRICTIONS Bob Ross summarized BIRD46.1 changing the maximum number of characters in a file name from 8 to 20 characters for .ibs, .pkg, and .ebd file names. This is accomplished by changing paragraph 3) in the General Syntax Rules and Guidelines section and also be providing a reference back to this section in the [Package Model] keyword regarding .pkg files. Bob confirmed with Matthew Flora that such a reference already existed for .ebd files, so no change was needed for that section of the IBIS Specification. Everyone generally supported this change. BIRD46.1 will be voted on at the IBIS Summit meeting. BIRD51 - 3-STATE ECL Kellee Chrisafulli called for a vote, since his group supported it and there were no discussion. BIRD51 was approved unanimously. Bob plans to include this in IBIS Version 3.1. BIRD52 - [Driver Schedule] CLARIFICATIONS As time was running out, Bob Ross mentioned the recently issued BIRD52 by Arpad Muranyi as a set of clarifications. The main intent was to clarify that [Driver Schedule] is under the [Model] keyword. Kellee Chrisafulli needed a full example so that implementors know how the exact format. BIRD42 was left as a discussion topic for the IBIS Summit Meeting. NEXT MEETING: The next meeting will be a face-to-face meeting on Thursday, June 18, 1998 from 8:30 AM to 5:00 PM at the Marriott Hotel, in San Francisco, CA. BIRD46.1 is scheduled for a vote. Other BIRDs will be discussed. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentorg.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 SECRETARY: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Thu Jun 11 15:13:22 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA22234 for ; Thu, 11 Jun 1998 15:13:22 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA02333; Thu, 11 Jun 1998 15:09:25 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA06178; Thu, 11 Jun 1998 15:09:24 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA13915; Thu, 11 Jun 98 15:09:24 PDT Date: Thu, 11 Jun 98 15:09:24 PDT Message-Id: <9806112209.AA13915@bob> To: ibis@eda.org Subject: IBIS SUMMIT AGENDA 6/18/98 A G E N D A D A C I B I S S U M M I T M E E T I N G Thursday, June 18, 1998 San Francisco Marriott Hotel San Francisco, California 8:30 AM - 9:00 AM REFRESHMENTS 9:00 AM - 9:50 AM BUSINESS - Introductions & Meeting Overview - IBIS 97-98 Overview - Bob Ross - Officer Elections for 1998-1999 - Opens & Other Business 9:50 AM - 10:10 AM IBIS MODEL VALIDATION ON LINUX - Syed Huq 10:10 AM - 10:25 AM BREAK 10:25 AM - 11:10 AM SIMULATION TOOL ENHANCEMENTS - Arpad Muranyi 11:10 AM -11:15 AM BIRD46.1 RELAXTION OF IBIS FILE NAME RESTRICTION - Vote 11:15 AM - 12:15 PM BIRDS 48-50 - ADD SUBMODEL DISCUSSION 12:15 PM - 1:00 PM LUNCH (PROVIDED) 1:00 PM - 2:00 PM BIRD42.3 - MODELING CURRENT WAVEFORMS 2:00PM - 3:00 PM DISCUSSION OF BIRDS NEEDED FOR TECHICAL COMPLETION OF IBIS VERSION 3.1 - Parser Development Technical List - BIRD52 - [Driver Schedule] CLARIFICATIONS 3:00 PM - 3:15 PM BREAK 3:15 PM - 4:15 PM FINISHING THE DOCUMENT - Editing Committee - BIRD44 - Interpretation of Min/Max/Weak/Strong Data 4:15 PM - 5:00 PM ANY OTHER ISSUES - Next Meeting From owner-ibis Thu Jun 11 17:54:23 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA24988 for ; Thu, 11 Jun 1998 17:54:23 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA14260; Thu, 11 Jun 1998 17:50:27 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id RAA07739; Thu, 11 Jun 1998 17:50:24 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA14093; Thu, 11 Jun 98 17:50:25 PDT Date: Thu, 11 Jun 98 17:50:25 PDT Message-Id: <9806120050.AA14093@bob> To: ibis@eda.org Subject: New unofficial IBIS document To All: A new, unofficial version of IBIS: ver3_1d.ibs has been uploaded on eda.org under /pub/ibis/wip. It contains BIRD51 and some editorial corrections. Bob Ross Interconnectix/Mentor Graphics From owner-ibis Fri Jun 12 00:57:49 1998 Received: from redac.co.uk (mail.redac.co.uk [195.99.246.2]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id AAA02026 for ; Fri, 12 Jun 1998 00:57:47 -0700 (PDT) Received: from redpo by redac.co.uk (5.0/SMI-SVR4) id AA29984; Fri, 12 Jun 1998 08:53:22 +0000 Received: from ACOL.redac.co.uk by redpo (SMI-8.6/Redac-Interior-Gateway-V1.1) id IAA29532; Fri, 12 Jun 1998 08:54:55 +0100 Message-Id: <1.5.4.32.19980612080437.006da398@redpo> X-Sender: johnb@redpo X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Jun 1998 09:04:37 +0100 To: ibis@eda.org From: John Berrie Subject: On Vacation unsubscribe John Berrie Application Engineering Consultant Dynamic Solutions Zuken-Redac Tewkesbury U.K. From owner-ibis Fri Jun 12 00:59:11 1998 Received: from redac.co.uk (mail.redac.co.uk [195.99.246.2]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id AAA02040 for ; Fri, 12 Jun 1998 00:59:09 -0700 (PDT) Received: from redpo by redac.co.uk (5.0/SMI-SVR4) id AA00017; Fri, 12 Jun 1998 08:54:44 +0000 Received: from ACOL.redac.co.uk by redpo (SMI-8.6/Redac-Interior-Gateway-V1.1) id IAA29573; Fri, 12 Jun 1998 08:56:17 +0100 Message-Id: <1.5.4.32.19980612080559.006c5280@redpo> X-Sender: johnb@redpo X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Jun 1998 09:05:59 +0100 To: ibis@eda.org From: John Berrie Subject: unsubscribe John Berrie Application Engineering Consultant Dynamic Solutions Zuken-Redac Tewkesbury U.K. From owner-ibis Fri Jun 12 07:29:06 1998 Received: from morrison.matrox.com (morrison.matrox.com [204.50.136.19]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA09175 for ; Fri, 12 Jun 1998 07:29:04 -0700 (PDT) Received: (from mtxmail@localhost) by morrison.matrox.com (8.8.8/8.8.8) id KAA13196 for ; Fri, 12 Jun 1998 10:25:33 -0400 (EDT) Received: from venus.matrox.com(138.11.0.5) by morrison-250 via smap (V2.0) id xma013150; Fri, 12 Jun 98 10:25:02 -0400 Received: from imagine.matrox.com (imagine.matrox.com [192.168.51.4]) by venus.matrox.com (8.8.7/8.8.7) with ESMTP id KAA08369 for ; Fri, 12 Jun 1998 10:25:01 -0400 (EDT) Received: from elnk317.matrox.com (elnk317.matrox.com [192.168.49.53]) by imagine.matrox.com (8.7.5/8.7.3) with SMTP id KAA23749 for ; Fri, 12 Jun 1998 10:24:57 -0400 (EDT) Received: by elnk317.matrox.com with Microsoft Mail id <01BD95EC.3FB63C50@elnk317.matrox.com>; Fri, 12 Jun 1998 10:24:14 -0400 Message-ID: <01BD95EC.3FB63C50@elnk317.matrox.com> From: Alain Marchand To: "'ibis@eda.org'" Subject: Crossbar switch Date: Fri, 12 Jun 1998 10:24:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Is it possible to generate a valid ibis model for a crossbar switch. I have a crossbar switch on my data path and I would like to simulate the influence on the integrity of my signal. A good way, I presume, would be to substitute the device by a resistance model, but I don't think we can create ibis model for passive devices, can we? Alain Marchand Hardware Design Engineer Matrox Electronic Systems amarchan@matrox.com From owner-ibis Fri Jun 12 11:58:10 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA14047 for ; Fri, 12 Jun 1998 11:58:09 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA00777; Fri, 12 Jun 1998 11:54:10 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id LAA13988; Fri, 12 Jun 1998 11:54:08 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA14634; Fri, 12 Jun 98 11:54:08 PDT Date: Fri, 12 Jun 98 11:54:08 PDT Message-Id: <9806121854.AA14634@bob> To: Alain.Marchand@matrox.com, ibis@eda.org Subject: Re: Crossbar switch Alain: IBIS Version 3.0 supports the functionality of a crossbar switch. A sample of the CBT3383 switch exists on eda.org under /pub/ibis/samples/ver3.0/cbt.ibs. This sample passes the preliminary ibischk3 parser. Best Regards, Bob Ross Interconnectix/Mentor Graphics > From: Alain Marchand > To: "'ibis@eda.org'" > Subject: Crossbar switch > Date: Fri, 12 Jun 1998 10:24:13 -0400 > Hi, > Is it possible to generate a valid ibis model > for a crossbar switch. I have a crossbar switch > on my data path and I would like to simulate the influence > on the integrity of my signal. A good way, I presume, > would be to substitute the device by a resistance model, > but I don't think we can create ibis model for > passive devices, can we? > Alain Marchand > Hardware Design Engineer > Matrox Electronic Systems > amarchan@matrox.com From owner-ibis Fri Jun 12 13:28:14 1998 Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA15732 for ; Fri, 12 Jun 1998 13:28:14 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA18757 for ; Fri, 12 Jun 1998 13:24:46 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id ; Fri, 12 Jun 1998 13:24:35 -0700 Message-ID: From: "Woo, William" To: "'ibis@eda.org'" Date: Fri, 12 Jun 1998 13:24:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain subscribe From owner-ibis Wed Jun 17 16:18:01 1998 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA21243 for ; Wed, 17 Jun 1998 16:18:01 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id QAA02557 for ; Wed, 17 Jun 1998 16:14:31 -0700 (PDT) Received: from milliways.cadence.com(158.140.142.7) by mailgate.cadence.com via smap (mjr-v1.2) id xma898125271.002554; Wed, 17 Jun 98 16:14:31 -0700 Received: (from geoff@localhost) by milliways.Cadence.COM (8.7.3/8.7.3) id QAA28402; Wed, 17 Jun 1998 16:13:41 -0700 (PDT) Date: Wed, 17 Jun 1998 16:13:41 -0700 (PDT) From: Geoffrey Ellis Message-Id: <199806172313.QAA28402@milliways.Cadence.COM> To: ibis@vhdl.org Subject: IBIS Model Selectors Can you have both input models and output models under the same Model Selector keyword? If so, what does it mean? It could mean: 1) The pin can be programmed either as an input or as an output. or 2) It's a bi-directional pin. The IBIS 3 spec seems to suggest the first interpretation where it explains the purpose of the descriptions. However, I have heard suggestions that the second interpretation is possible. Comments appreciated. *********************************************************************** * Geoffrey Ellis * * Cadence Design Systems phone: 408-685-6559 * * 9057 Soquel Drive fax: 408-685-6556 * * Aptos, CA 95003 E-mail: geoff@cadence.com * *********************************************************************** From owner-ibis Fri Jun 19 18:34:02 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA13829 for ; Fri, 19 Jun 1998 18:34:02 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA19651; Fri, 19 Jun 1998 18:30:01 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA12259; Fri, 19 Jun 1998 18:30:00 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA19298; Fri, 19 Jun 98 18:29:58 PDT Date: Fri, 19 Jun 98 18:29:58 PDT Message-Id: <9806200129.AA19298@bob> To: ibis@eda.org Subject: IBIS BIRD48.4 - Add Submodel IBIS Folks: In response to the comments from Kellee Chrisafulli and staff and to comments at the June 5, 1998 IBIS meeting and comments at the IBIS Summit Meeting on June 18, 1998, BIRD48.4 is issued (along with BIRD49.3 and BIRD50.3). The changes are substantial and sections have been rewritten. Some changes are: - The Title is changed from Add Model to Add Submodel - The changes to the [Model] keyword are removed. The Model_type Subparameters in [Model] for Dynamic_clamp and Bus_hold are removed. - The [Add Model] keyword name is changed to [Add Submodel] - A new keyword [Submodel] is introduced to replace the functionality that was added to the [Model] keyword for the old added model. It has a new subparameter Submodel_type. Model_type is not recognized. - [Add Model Spec] is changed to [Submodel Spec]. Kellee requested reusing the [Model Spec] keyword, but I think it will work better with its own specification keyword for internal details. - The text is changed substantially, so changes are not noted. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 48.4 ISSUE TITLE: Add Submodel REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/1/98, 5/21/98, 5/29/98, 6/19/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: A method is needed to add model feature details to an existing IBIS [Model] for unanticipated technical expansion requirements. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following the [Model Spec] keyword will be this new keyword: |============================================================================== | Keywords: [Add Submodel] | Required: No | Description: References a submodel to be added to an existing model. | Usage Rules: The [Add Submodel] keyword is invoked within a model to | add the functionality that is contained in the submodel or | list of submodels in each line that follows. The first | column contains the submodel name. The second column | contains a submodel mode under which the submodel is used. | | If the top-level model type is one of the I/O or 3-state | models, the submodel mode may be Driving, Non-Driving, or | All. For example, if the submodel mode is Non-Driving, | then the submodel is used only in the high-Z state of a | 3-state model. Set the submodel mode to All if the | submodel is to be used for all modes of operation. | | The submodel mode cannot conflict with the top-level model | type. For example, if the top-level model type is an | Open or Output type, the submodel mode cannot be set to | Non-Driving. Similarily, if the top-level model type | type is Input, the submodel mode cannot be set to Driving. | | The [Add Submodel] keyword is not defined for Series or, | Series_switch model types. | | Refer to the Add Submodel Description section in this | document for the descriptions of available submodels. | |------------------------------------------------------------------------------ [Add Submodel] | Submodel_name Mode Bus_Hold_1 Non-Driving | Adds the electrical characteristics of | [Submodel] Bus_Hold_1 for receiver or | high-Z mode only Dynamic_clamp_1 All | Adds the Dynmanic_clamp_1 model for | all modes of operation | |============================================================================== |============================================================================= |============================================================================= | | Section 6a | | A D D S U B M O D E L D E S C R I P T I O N | |============================================================================= |============================================================================= | | The [Add Submodel] keyword can be used under a top-level [Model] keyword to | to add special-purpose functionality to the existing top-level model. This | section describes the structure of the top-level model and the submodel. | | TOP-LEVEL MODEL: | | When special-purpose functional detail is needed, the top-level model can | call one or more submodels. The [Add Submodel] keyword is positioned | after the initial set of required and optional subparameters of the [Model] | keyword and among the keywords under [Model]. | | The [Add Submodel] keyword lists of name of each submodel and the permitted | mode (Driving, Non-Driving or All) under which each added submodel is used. | | SUBMODEL: | | A submodel is defined using the [Submodel] keyword. It contains a subset | of keywords and subparameters used for the [Model] keyword along with other | keywords and subparameters that are needed for the added functionality. | | The [Submodel] and [Submodel Spec] keywords are defined first since they | are used for all submodels | | The only required subparameter in [Submodel] is Submodel_type to define the | list of submodel types. The other subparameters under [Model] are not | permitted under the [Submodel] keyword. | | The following set of keywords that are defined under the [Model] keyword are | support by the [Submodel] keyword: | | [Pulldown] | [Pullup] | [GND Clamp] | [POWER Clamp] | [Ramp] | [Rising Waveform] | [Falling Waveform] | | The [Voltage Range], [Pullup Reference], [Pulldown Reference], [GND Clamp | Reference], and [POWER Clamp Reference] keywords are not permitted. The | voltage settings are inherited from the top-level model. | | These additional keywords are used only for the [Submodel] are documented | in this section: | | [Submodel Spec] | [GND Pulse Table] | [POWER Pulse Table] | | The application of these keywords depends upon the Submodel_type entries | listed below: | | Dynamic_clamp | Bus_hold | | Permitted keywords that are not defined for any of these submodel types are | ignored. | |============================================================================= | Keyword: [Submodel] | Required: No | Description: Used to define a submodel, and its attributes. | Sub-Param: Submodel_type | Usage Rules: Each submodel must begin with the keyword [Submodel]. The | submodel name must match the one that is listed under the | [Add Submodel] keyword and must not contain more than 20 | characters. A .ibs file must contain enough [Submodel] | keywords to cover all of the model names specified under the | [Add Submodel] keyword. | | Submodel_type subparameter is required and must be one of the | following: | | Dynamic_clamp, Bus_hold | | The C_comp subparameter is not permitted under the [Submodel] | keyword. The total effective die capacitance including the | submodel contributions are provided in the top-level model. | | Other Notes: The following list of keywords that are defined under the | [Model] keyword can be used under [Submodel]: [Pulldown], | [Pullup], [GND Clamp], [POWER Clamp], [Ramp], [Rising | Waveform], and [Falling Waveform]. | | The following list of additional keywords can be used: | [Submodel Spec], [GND Pulse Table], and [POWER Pulse Table]. |----------------------------------------------------------------------------- [Submodel] Dynamic_clamp1 Model_type Dynamic_clamp | variable typ min max C_comp 1.0pF 0.5pF 1.5pF | |============================================================================= |============================================================================= | Keyword: [Submodel Spec] | Required: No | Description: The [Submodel Spec] keyword defines four columns under which | specification and information subparameters are defined for | submodels. | Sub-Params: V_trigger_r, V_trigger_f | | Usage Rules: The [Submodel Spec] is to be used only with submodels | | The following subparameters are used: | V_trigger_r Rising edge trigger voltage | V_trigger_f Falling edge trigger voltage | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab or tab character. All four columns are required | under the [Submodel Spec] keyword. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used to | indicate the typical value by default. | | The values in the minimum and maximum columns usually | correspond to the values in the same colums for the inherited | top-level voltage range or reference voltages in the top-level | model. | | Unless noted, each [Submodel Spec] subparameter is independent | of any other subparameter. | | V_trigger_r, V_trigger_f rules: | | The voltage trigger values for the rising and falling edges | provide the starting time when an action is initiated. | |----------------------------------------------------------------------------- | Dynamic Clamp Example: | [Submodel Spec] | Subparameter typ min max | V_trigger_h 3.6 2.9 4.3 | Starts power pulse table V_trigger_f 1.4 1.2 1.6 | Starts gnd pulse table | | Bus Hold Example: | [Submodel Spec] | Subparameter typ min max V_trigger_h 3.1 2.4 3.7 | Starts low to high | bus hold transition V_trigger_f 1.8 1.6 2.0 | Starts high to low | bus hold transition | |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: *** The discussion below is in terms of the older, evolving terminology *** After considering the Dynamic Clamp and then seeing the need for a more general mechanism for also adding "latching" in the model - to be added to the existing Model, a new keyword is proposed for adding special purpose models. New Model_types will be defined for the special purposes. The [Model Spec] keyword will be used to add additional control or information subparameters. Additional keywords may be proposed that apply only to the specific model type. However, this model call method also allows using the existing keywords to construct the added functionality. One motivation for this alternative construction is based on BIRD45.1 for Dynamic Clamps. BIRD45.1defines some new clamping tables. However, with a special purpose model defined in BIRD49, the existing [GND Clamp] and [POWER Clamp] keywords can be used along with others to add a clamp that has a controlled reference shift over time. A similar motivation is BIRD50 for a new Bus_hold mechanism. The terminology is still up for discussion. This mechanism can be used to add to the Input or I/O model a Bus-Hold Circuit similar to how they are being currently implemented - via a weak output stage that switches according to thresholds. This mechanism also models the functionally of some proprietary structures that also produce a latching effect via some weak output stages. An alternative that was intially considered was to lump several "related" extensions into its own Model_type (the Model_types could even be called Extension_1, Extension_2, etc.) However after considering this for the Dynamic Clamp and Bus Hold functionality, this was rejected. The interaction of several Model_type specific rules would be combersome and confusing to document. BIRD48 also defines a consistent and understandable mechanism [Add Model] to add electrical and informational functionality of new feature that have not been defined. Using just [Model Spec] for some additional specification subparameters was considered. However, the [Model Spec] keyword should really be used for real, external specification subparameters. So the internal [Add Model Spec] as added in a parallel manner to deal with internally specified parameters that are needed for the additional model, but may not appear in data sheets or data books. BIRD48.1 adds the Add_model_mode subparameter to the [Model] that is being added. Its arguments are Output and Non_Output. "Non-Output" is used rather than "Input" because this could also be used for the high-Z mode of a 3-state model. BIRD48.1 also expands the [Model] keyword to capture the addtional Model_type subparameters - Dynamic_clamp and Bus_hold. Also, the subparameter Add_model_mode is added to the [Model] keyword description. BIRD48.2 changes the subparameters of Add_model_mode to Driving and Non-Driving to be more representative of the actual modes of operation of top-level 3-state and I/O_* buffers. After some reconsideration, BIRD48.3 removes the Add_model_mode subparameter introduced in BIRD48.1. The syntax of [Add Model] is changed to a syntax similar to [Driver Schedule] where a list of models are given under the [Add Model] keyword. The second column is used to list the more restrictive mode of operation for I/O and 3-state models where each added model is used either for Driving or Non-Driving. Putting this list of model names and associated modes of operation in the top-level model makes it much clear what is added and under what model of operation. Consistent with other keyword operation, the second column is required. If no mode restriction is applicable, then the reserved word 'NA' is required. Furthermore, it is an error if the mode restriction conflicts with the top-level mode. So, Driving is not permitted for an Input* model, and Non-Driving is not permitted for any of the Output* or Open* models. *** The terminology below has changed to reflect the [Add Submodel] change *** BIRD48.4 has the similar functionality as above, but in terms of a syntax change. A [Submodel] keyword is introduced. This avoids confusing the added model functions with the [Model] keyword. As a result, the Model_type subparameter is not used, It is changed to Submodel_type with arguments Dynamic_clamp, Bus_hold. Per a comment by Kellee Chrisafulli, the list of keywords (both from [Model] and specific for [Submodel] are listed. At the June 18, 1998 meeting, the group discussed several issues and made these recommendations: (1) Top-level Terminator model types should be supported since the submodel mechanizm can be used for active terminations such as those for SCSI. (2) The Voltages and Temperatures of the top-level model should be inherited by the submodel. This would eliminate the need to add the corresponding [Voltage Range] and reference voltages in the submodel. The concern is that these can be different that what is used in the top-level model. While this difference can lead to more generality for internal structures, it could also lead to incompatibility with other keywords such as [Pin Mapping]. (3) C_comp is not permitted in submodels. The problem was whether submodel cacitance should be ignored, always added to provide a total C_comp or just added based on the [Add Submodel] mode column. Since C_comp is already an effective capacitance for actual non-linear behavior, this detail seemed unnecessary. The total effective capacitance positioned in one location was the clearest solution to the problem. (4) The allowable keywords are listed. However, the exact usage is governed by the Submodel_type subparameter value. Consistent with the [Model] keyword, keywords which are meaningless for a particular model type are ignored. For example, the dynamic clamp could have the [Pullup] keyword and data, but it would not be used within a dynamic clamp submodel. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD48 is an evolution in thinking starting with BIRD45 for dynamic clamps. The need to consider some output models withing the clamping structure, but the proposals were becoming extremely complex with many new keywords, and with possible augmentation to the already complex [Driver Schedule] keyword. Several meetings were held on this subject. The last meeting on March 11, 1998 with Chris Reid, Bob Ross, and Arpad Muranyi was held to consider these complicated additions. The outcome was essentially a proposal that new Model_types can be defined for specific additions, the models themselves would could contain very well-defined information including new keywords that were allowed only with [Model]s of that type, and that the models would be called by an [Add Model] mechanism within another model. This seemed to fit implementation architectures where the new model information is well modularized (and in some cases just uses the same structures), and provided electrical information that is additive (or subtractive) to the existing models. The proposal here is an extension of what was discussed at the March 11, 1998 meeting based on some further reflections to associate any new functionality with its own Model_type. BIRD48 is evolving based on subsequent IBIS meetings and reflector input. The latest changes are based on inputs at the June 5, 1998 and June 18, 1998 IBIS meetings. ****************************************************************************** From owner-ibis Fri Jun 19 18:34:35 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA13834 for ; Fri, 19 Jun 1998 18:34:35 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA19670; Fri, 19 Jun 1998 18:30:34 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA12265; Fri, 19 Jun 1998 18:30:33 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA19301; Fri, 19 Jun 98 18:30:32 PDT Date: Fri, 19 Jun 98 18:30:32 PDT Message-Id: <9806200130.AA19301@bob> To: ibis@eda.org Subject: IBIS BIRD49.3 - Add Submodel Dynamic Clamps From owner-ibis Fri Jun 19 18:36:34 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA13841 for ; Fri, 19 Jun 1998 18:36:34 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA19764; Fri, 19 Jun 1998 18:32:34 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA12280; Fri, 19 Jun 1998 18:32:32 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA19304; Fri, 19 Jun 98 18:32:31 PDT Date: Fri, 19 Jun 98 18:32:31 PDT Message-Id: <9806200132.AA19304@bob> To: ibis@eda.org Subject: IBIS BIRD49.3 - Add Submodel Dynamic Clamps (IGNORE PREVIOUS EMAIL - HIT SEND BEFORE INSERTING THE FILE) IBIS Folks: BIRD49.3 is issued to reflect changes in BIRD48.4 associated with introducing submodels: - The Title is changed from Add Model Dynamic Clamps to Add Submodel Dynamic Clamps - The text is rewritten to reflect the changes in BIRD48.4. - The Clocked Mode was controversial. We decided not to include it in BIRD49.3 at the June 19, 1998 IBIS Summit meeting since we could work around its problems using the Triggered mode. The primary concern is that the real specification of the clocked mode requires IBIS to handle timing information. Thus the following modes still exist depending upon whether there exist optional [Submodel Spec] and the [GND Pulse Table] and [POWER Pulse Table] entries: [Submodel Spec] Pulse Table Yes Yes Triggered Yes or No No Static - A complete example is provided. - Some confusing, historical discussion in the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION that related to the superceded BIRD45.2 was deleted. A large portion of the BIRD49.3 text has been rewritten, so changes are not noted. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 49.3 ISSUE TITLE: Add Submodel Dynamic Clamps REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/1/98, 5/21/98, 6/19/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: A novel type of termination technique is used in today's integrated circuits. The termination consists of a pair of built in dynamic clamps whose V-I curves change with time. The clamp is switched "on" when needed and switched "off" otherwise (to conserve power). When the clamp is switched "on" its V-I curve provides more clamping than a regular static clamp and when it is turned "off" it behaves like a normal clamp. The "on" switching of the dynamic clamps can be triggered by an input signal crossing a triggering threshold or by some external clock. The "off" switching can be triggered by a built in timer or an external clock. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The dynamic clamp functionality is added in the new Section 6a discussion: | Dynamic Clamp: | | When the Submodel_type subparameter under the [Submodel] keyword is set to | Dynamic_clamp, the submodel describes the dynamic clamp functionality. | | The [GND Pulse Table] and [POWER Pulse Table] keywords are defined. An | example for a complete dynamic clamp model is provided. | |============================================================================= | Keyword: [GND Pulse Table], [POWER Pulse Table] | Required: No | Description: Used to specify the offset voltage versus time of [GND Clamp] | and [POWER Clamp] tables within submodels. | Usage Rules: Each [GND Pulse Table] and [POWER Pulse Table] keyword | introduces a table of time versus vs. points that describe | the shape of an offset voltage from the [GND Clamp Reference] | voltage (or default ground) or the [POWER Clamp Reference] | voltage (or default [Voltage Range] voltage). Note, these | voltage values are inherited from the top-level model. | | The table itself consists of one column of time points, then | three columns of voltage points in the standard typ, min, and | max format. The four entries 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. However, data is | only required in the typical column. If minimum or maximum | data is not available, use the reserved word "NA". Time | values must increase as one parses down the table. The | waveform table can contain of maximum of 100 data points. | | Each table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | The voltage entries in both the [Gnd Pulse Table] and [POWER | Pulse Table] tables are directly measured offsets. At each | instance, the [Gnd Pulse Table] voltage is ADDED to the [GND | Clamp] table voltages to provide the shifted table voltages. | At each instance, the [POWER Pulse Table] voltage is | SUBTRACTED (because of polarity conventions) from the [POWER | Clamp] table voltages to provide the shifted table voltages. | | Only one [GND Pulse Table] and one [POWER Pulse Table] are | allowed per model. | | The [GND Pulse Table] and [POWER Pulse Table] interact with | [Submodel Spec] subparameters V_trigger_f and V_trigger_r. | Several modes of operation exist based on whether a pulse | table and its corresponding trigger subparameter are given. | These modes are classified as triggered, clocked, and static. | | Triggered Mode: | | For triggered mode a pulse table must exist and include the | entire waveform; i.e., the first entry (or entries) in a | voltage column must be equal to the last entry. | | Also, a corresponding [Submodel Spec] V_trigger_* subparameter | must exist. The triggered interaction is described: | | The V_trigger_f subparameter under [Submodel Spec] is used | to detect when the falling edge waveform at the die passes | the trigger voltage. At that time the [Gnd Pulse Table] | operation starts. Similarily, the V_trigger_r subparameter is | used to detect when the rising edge waveform at the die passes | the trigger voltage. At that time [POWER Pulse Table] | operation starts. The [GND Pulse Table] dependency is shown | below: | | | Waveform at Die | | o o o o | o | o | o ------- | |o ^ | | o | V_trigger_f | | o v time | | o o--------------------> | | | | | | [GND Pulse Table] | | | | o o o o | | o o | | o o | | o o | | o o | | o o time | o o o o o o o o --------> | | ^ | |_ [GND Pulse Table] operation starts at this time | | The V_trigger_r and [POWER Pulse Table] operate in a similar manner. When | the V_trigger_r voltage value is reached on the rising edge, the [POWER | Pulse Table] is started. Normally the offset voltage entries in the [POWER | Pulse Table] are negative. | | Static Mode: | | When the [GND Pulse Table] keyword does not exist, but the added model | [GND Clamp] table does exist, the added model [GND Clamp] is used directly. | Similarly, when the [POWER Pulse Table] keyword does not exist, but the | added model [POWER Clamp] table does exist, the added model [POWER Clamp] | is used directly. | | This mode provides additional fixed clamping to an I/O_* buffer or a | 3-state buffer when it is used as a driver. |------------------------------------------------------------------------------ | | Example of Dynamic_clamp Model with both dynamic GND and POWER clamps: | [Submodel] Dynamic_Clamp_1 Submodel_type Dynamic_clamp | [Submodel Spec] | Subparameter typ min max | V_trigger_f 1.4 1.2 1.6 | Falling edge trigger V_trigger_r 3.6 2.9 4.3 | Rising edge trigger | | typ min max | [Voltage Range] 5.0 4.5 5.5 | Note, the actual voltage range and reference voltages are inherited from | the top-level model. | [GND Pulse Table] | GND Clamp offset table | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 0.9 0.8 1.0 | 10e-9 0.9 0.8 1.0 | 11e-9 0 0 0 | [GND Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | [POWER Pulse Table] | POWER Clamp offset table | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 -0.9 -1.0 -0.8 | 10e-9 -0.9 -1.0 -0.8 | 11e-9 0 0 0 | [POWER Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: *** Comments Below are in terms of terminology that has been changing **** The proposal is designed to retain as much of the existing IBIS clamp syntax as possible. The dynamic clamp V-I curve tables follow all of the conventions of the existing V-I tables. The overall modeling approach is to decompose the dynamic clamp into its static and dynamic portions. The static part can be modeled by a regular clamp. The dynamic part is connected to the same rail voltage as its static part and modeled by a V-I curve that is shifted along the voltage axis by the offset voltage pulse. BIRD49 replaces the BIRD45.1 proposal of some new keywords shown below, but preserves the intended functionality. It also reponses to the comment that some of the V_trigger subparameters should be expressed in a typ-min-max format. The [Model Spec] keyword structure is proposed to do this. The replaced structure is below. *** Note Refer to Rejected BIRD45.1 for some Original Discussion on the Dynamic Clamp Functionality. The Discussion here is deleted since the older terminology and details introduced confusion *** BIRD49.1 adds the rules for when the time is negative and when the V_trigger_l and V_trigger_h thresholds are not used and can be omitted. The intent is to support having the dynamic clamps controlled by an external control so that they can be preset before the signal arrives at the device. A method was chosen that is based on the activation pulse that the simulator uses to initiate the driver transition. Most simulators do not have an independent pulse control to preset some other parameter. This method can be user configurable to deal with simulator differences in time relationships for driver activation on the net and possible phase differences of this component on a net. The time values may have to be readjusted for a particular part. However, the approach taken here should work for most practical cases. BIRD49.2 simplifies extends and simplifies the rules. Several modes of operation are defined based on the existance of non-existency of the [Add Model Spec] trigger subparameters (or keyword itself) and also for when the pulse table itself is missing. The dependency on an artificial negative time for one of the modes of operation in BIRD49.1 was not appealing. *** BIRD49.3 discussion with the revised Submodel terminology of BIRD48.4 **** BIRD49.3 is modified to use the submodel terminology and keywords of BIRD48.4. Also, the clocked mode is deleted because its operation interacted to much with timing simulator operation - outside the realm of IBIS. It was not clear that we could do describe the intended effects correctly (or even by approximation) independently. This could be a candidate for further research. We could adapt the triggered mode, even on a component-by- component basis to approximate the effect, as a work around. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Based on a conversation with Arpad Muranyi on 11/14/97. Modified per a discussion with Bob Ross, Chris Reid and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Fri Jun 19 18:37:44 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA13846 for ; Fri, 19 Jun 1998 18:37:43 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA19813; Fri, 19 Jun 1998 18:33:43 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA12289; Fri, 19 Jun 1998 18:33:42 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA19307; Fri, 19 Jun 98 18:33:40 PDT Date: Fri, 19 Jun 98 18:33:40 PDT Message-Id: <9806200133.AA19307@bob> To: ibis@eda.org Subject: IBIS BIRD50.3 - Add Submodel Bus Hold Dear IBIS Folks: BIRD50.3 is issued to reflect changes in BIRD48.4 associated with introducing submodels: - The Title is changed from Add Model Bus Hold to Add Submodel Bus Hold. - The text is rewritten to reflect the changes in BIRD48.4. - A complete example is provided. A large portion of the BIRD50.3 text has been rewritten, so changes are not noted. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 50.3 ISSUE TITLE: Add Submodel Bus Hold REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/21/98, 5/29/98, 6/19/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: New devices incorporate bus hold or other latching mechanisms to hold the input at a particular state using some active pullup and pulldown components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The Bus Hold functionality is added in the new Section 6a: | Bus Hold: | | When the Submodel_type subparameter under the [Submodel] keyword is set to | Bus_hold, the added model describes the bus hold functionality. However, | while described in terms of bus hold functionality, active terminators | can also be modeled. | | Existing keywords and subparameters are used to describe bus hold models. | The [Pullup] and [Pulldown] tables both are used to define an internal | buffer that is triggered switch to its opposite state. This switching | transition is specified by a [Ramp] keyword or by the [Rising Waveform] | and [Falling Waveform] keywords. The usage rules for these keywords are the | same as under the [Model] keyword. In particular, at least either the | [Pullup] or [Pulldown] keyword is required. Also, the [Ramp] keyword is | required, even if the [Rising Waveform] and [Falling Waveform] tables exist. | However, the voltage ranges and reference voltages are inherited from the | top-level model. | | For bus hold submodels, the [Submodel Spec] keyword and the V_trigger_r and | V_trigger_f subparameters are required. | | The transition is triggered by action at the die using the [Submodel Spec] | V_trigger_r and V_trigger_f subparameters as follows: | | If the starting voltage is below V_trigger_f, then the bus_hold model is | set to the low state causing additional pulldown current. If the starting | voltage is above V_trigger_r, the bus hold model is set to the high | state for additional pullup current. When the input passes though | V_trigger_f during a high-to-low transition at the die, the bus hold output | switches to the low state. Similarly, when the input passes though | V_trigger_r during a low-to_high transition at the die, the bus hold output | switches to the high state. | | No additional keywords are needed for this functionality. |------------------------------------------------------------------------------ | | Complete Bus_hold Model Example: | [Submodel] Bus_hold_1 Submodel_type Bus_hold | [Submodel Spec] | Subparameter typ min max | V_trigger_f 1.3 1.2 1.4 | Falling edge trigger V_trigger_r 3.1 2.6 4.6 | Rising edge trigger | | typ min max | [Voltage Range] 5.0 4.5 5.5 | Note, the actual voltage range and reference voltages are inherited from | the top-level model. | [Pulldown] | -5V -100uA -80uA -120uA -1V -30uA -25uA -40uA 0V 0 0 0 1V 30uA 25uA 40uA 3V 50uA 45uA 50uA 5V 100uA 80uA 120uA 10v 120uA 90uA 150uA | [Pullup] | -5V 100uA 80uA 120uA -1V 30uA 25uA 40uA 0V 0 0 0 1V -30uA -25uA -40uA 3V -50uA -45uA -50uA 5V -100uA -80uA -120uA 10v -120uA -90uA -150uA | |**************************************************************************** | [Ramp] | typ min max dV/dt_r 2.0/0.50n 2.0/0.75n 2.0/0.35n dV/dt_f 2.0/0.50n 2.0/0.75n 2.0/0.35n R_load = 500 | |**************************************************************************** |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: *** Note, these comments are in tems of the prior "Add Model" Syntax *** A weak driver can be added using the [Add Model] keyword. BIRD50.1 adds the statement that [Add Model Spec] and its V_trigger_r and V_trigger_f subparameters are required. This is because [Add Model Spec] may not be required for other added models. BIRD50.2 deletes the Add_model_mode subparameter in the example since BIRD48.3 deletes this subparameter. *** These coments are in terms of the new "Add Submodel" Syntax in BIRD48.4 ** BIRD50.3 is just an update with respect to the revised syntax. C_comp is removed from the example since it appears only at the top level. The voltages range and reference values are inherited from the top-level model. Required keywords are described for clarity. One of [Pulldown] or [Pullup] keyword is required. Also, the [Ramp] keyword is not required. Also note, that the [Ramp] keyword presumes a totum pole output stage. There is no "Model_type" subparameter in case the hold is just for a single direction (e.g., Open Source). A [Rising Waveform] and [Falling Waveform] table would be a proper way to specify such a case. As under the [Model] keyword, the [Ramp] keyword is required. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on a conversation with Bob Ross, Chris Reid, and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Mon Jun 22 10:20:56 1998 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA17507 for ; Mon, 22 Jun 1998 10:20:55 -0700 (PDT) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with ESMTP id NAA07176 for ; Mon, 22 Jun 1998 13:16:34 -0400 (EDT) Received: by SBUAMAZKO2AE with Internet Mail Service (5.0.1458.49) id ; Mon, 22 Jun 1998 13:12:57 -0400 Message-ID: <71EEA9EA5129D1118EA30000F840EBF16CE5FB@sbuamapko3bc.eng.pko.dec.com> From: Greg Edlund To: "'ibis@vhdl.org'" Subject: IBIS Accuracy Subcommittee Minutes 6/18/98 Date: Mon, 22 Jun 1998 13:11:45 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain IBIS Accuracy Subcommittee Minutes Thursday, June 18, 1998 Held at Stratus Computer, Marlborough, MA Thanks to Bruce Heilbrunn and Stratus for providing a place to meet. Attendees Greg Edlund, Digital Equipment (chair) Fawn Engelmann, EMC Bob Haller, Digital Equipment Bruce Heilbrunn, Stratus Computer Peter LaFlamme, Fairchild Semiconductor Harvey Stiegler, Texas Instruments (by phone) Next meeting is Friday, August 28, 1998 from 3:00 to 5:00 pm, location to be determined. MILESTONES The test board is awaiting clean-up routing and final review. Work priorities have halted work on the test board for the past six weeks. When the board has been debugged, we will post the Gerber files to the web. ?? 1998: Post the IBIS Accuracy Test Board to the web September 18, 1998: Distribute the first draft of the IBIS Accuracy Specification October 1998: PCB West Conference, IBIS Summit, and first IBIS Class February 1999: Present the IBIS Accuracy Specification at DesignCon99 EDITING 1. Scope - no activity this meeting. 2. Required Measurements The subcommittee decided that it does not make sense to specify which unique I/O buffer designs must be measured and compared to simulations. In cases where there is a large number of I/O buffer designs on a chip, the task of deciding which to measure involves engineering judgment, which is not something that we can specify. A perfect example of this is a gate array which has over 100 cells in its I/O buffer library. However, the modeling engineer must document which I/O buffer designs he measured and which he did not. 3. Measurement Techniques There are three types of measurements involved in the IBIS Accuracy Specification: IV curves, transient waveforms, and capacitance. We covered IV curves in this meeting. The two main topics of discussion were 1) specifying voltage and current ranges and 2) when to worry about line drop. For parts with clamp diodes, the modeling engineer should sweep voltage from -1 V to Vdd + 1 V to make sure the clamps turn on fully. The overcurrent protection limit should be set at the absolute maximum I/O current specification from the component datasheet. We did not discuss whether parts without clamp diodes should have different requirements. One could make a strong argument that they should. Perhaps a good place to start would be to sweep the voltage from -5 V to Vdd + 5 V, as specified by IBIS, with overcurrent protection set to the absolute maximum I/O current specification. In many cases, parts without clamps would certainly go into overcurrent protection somewhere over this range. We discussed the need for four-point probing. When line resistance from the DUT to the instrument is high and current is high, the IR drop in the line can introduce a significant error to the measurement. The modeling engineer must compute this IR drop and use a four-point probe when IR drop reaches a certain threshold whose value has not yet been determined. 4. Metrics - no activity this meeting. ---------- Greg Edlund, Principal Engineer Server Product Development Compaq Computer Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (978) 493-4157 voice (978) 493-0941 FAX greg.edlund@digital.com From owner-ibis Tue Jun 23 15:15:09 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA16104 for ; Tue, 23 Jun 1998 15:15:08 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA14817; Tue, 23 Jun 1998 15:11:07 -0700 (PDT) Received: from kappa2.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA01006; Tue, 23 Jun 1998 15:11:06 -0700 (PDT) Received: by localhost with Microsoft MAPI; Tue, 23 Jun 1998 15:08:53 -0700 Message-ID: <01BD9EB8.D5F4C040.tom_dagostino@mentorg.com> From: tomda To: "'Greg Edlund'" , "'ibis@vhdl.org'" Cc: "'Ted Creedon'" Subject: RE: IBIS Accuracy Subcommittee Minutes 6/18/98 Date: Tue, 23 Jun 1998 15:08:52 -0700 Organization: Mentor Graphics X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We at Zeelan have measured many thousand IC's and have some insight into the measurement problems on VI curves. Going to -1 V below Vss and to Vdd + 1 may or may not be sufficient to characterize the device. Many times you will not get far enough to see the "linear" part of the "diode's" VI characteristics. Just as many times the part will not allow you to get to -1 V below Vss. There are all kinds of behaviors that can and do occur in real parts below Vss. Limiting the current to the absolute max rating in the datasheet will also not allow a full characterization of the "diode". But on the other hand, there are parts that will latch up very easily. A few unfortunate times that I accidentally pushed a part to more than -2 V below Vss with current limits on they were sand again with epoxy impurities in microseconds. Sweeping parts from -5 to Vdd +5 will only show you the current limit characteristics of your system for over half of the sweep. And if the current times voltage (power) gets too high or the breakdown characteristics are exceeded, etc. you too will have made dirty sand. I don't recommend doing this at all. I question the need for 4 point current measurements. I've never had to design a fixture where the IR drops in the test system were anywhere near significant. The most current I've had to sink or source out of a driver is on the order of an amp. With even 50mOhms of trace resistance the IR drop will not affect the model in any meaningful way. Tom Dagostino Zeelan Model Libraries Mentor Graphics 503-685-1613 tom_dagostino@mentorg.com -----Original Message----- From: Greg Edlund [SMTP:Greg.Edlund@digital.com] Sent: Monday, June 22, 1998 10:12 AM To: 'ibis@vhdl.org' Subject: IBIS Accuracy Subcommittee Minutes 6/18/98 IBIS Accuracy Subcommittee Minutes Thursday, June 18, 1998 Held at Stratus Computer, Marlborough, MA Thanks to Bruce Heilbrunn and Stratus for providing a place to meet. Attendees Greg Edlund, Digital Equipment (chair) Fawn Engelmann, EMC Bob Haller, Digital Equipment Bruce Heilbrunn, Stratus Computer Peter LaFlamme, Fairchild Semiconductor Harvey Stiegler, Texas Instruments (by phone) Next meeting is Friday, August 28, 1998 from 3:00 to 5:00 pm, location to be determined. MILESTONES The test board is awaiting clean-up routing and final review. Work priorities have halted work on the test board for the past six weeks. When the board has been debugged, we will post the Gerber files to the web. ?? 1998: Post the IBIS Accuracy Test Board to the web September 18, 1998: Distribute the first draft of the IBIS Accuracy Specification October 1998: PCB West Conference, IBIS Summit, and first IBIS Class February 1999: Present the IBIS Accuracy Specification at DesignCon99 EDITING 1. Scope - no activity this meeting. 2. Required Measurements The subcommittee decided that it does not make sense to specify which unique I/O buffer designs must be measured and compared to simulations. In cases where there is a large number of I/O buffer designs on a chip, the task of deciding which to measure involves engineering judgment, which is not something that we can specify. A perfect example of this is a gate array which has over 100 cells in its I/O buffer library. However, the modeling engineer must document which I/O buffer designs he measured and which he did not. 3. Measurement Techniques There are three types of measurements involved in the IBIS Accuracy Specification: IV curves, transient waveforms, and capacitance. We covered IV curves in this meeting. The two main topics of discussion were 1) specifying voltage and current ranges and 2) when to worry about line drop. For parts with clamp diodes, the modeling engineer should sweep voltage from -1 V to Vdd + 1 V to make sure the clamps turn on fully. The overcurrent protection limit should be set at the absolute maximum I/O current specification from the component datasheet. We did not discuss whether parts without clamp diodes should have different requirements. One could make a strong argument that they should. Perhaps a good place to start would be to sweep the voltage from -5 V to Vdd + 5 V, as specified by IBIS, with overcurrent protection set to the absolute maximum I/O current specification. In many cases, parts without clamps would certainly go into overcurrent protection somewhere over this range. We discussed the need for four-point probing. When line resistance from the DUT to the instrument is high and current is high, the IR drop in the line can introduce a significant error to the measurement. The modeling engineer must compute this IR drop and use a four-point probe when IR drop reaches a certain threshold whose value has not yet been determined. 4. Metrics - no activity this meeting. ---------- Greg Edlund, Principal Engineer Server Product Development Compaq Computer Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (978) 493-4157 voice (978) 493-0941 FAX greg.edlund@digital.com From owner-ibis Thu Jun 25 11:42:17 1998 Received: from gatekeeper2.nsc.com (natsemi3-bh.nsc.com [205.227.60.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA28418 for ; Thu, 25 Jun 1998 11:42:17 -0700 (PDT) Received: (from uucp@localhost) by gatekeeper2.nsc.com (8.6.12/8.6.11) id LAA23308 for ; Thu, 25 Jun 1998 11:38:44 -0700 Received: from nsc.nsc.com by natsemi3-bh.nsc.com via smap (3.2) id xma023177; Thu, 25 Jun 98 11:38:27 -0700 Received: from rockie.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA10271 for ibis@vhdl.org; Thu, 25 Jun 98 11:38:26 -0700 Received: from kural by rockie (SMI-8.6/SMI-SVR4) id LAA17922; Thu, 25 Jun 1998 11:40:51 -0700 Date: Thu, 25 Jun 1998 11:40:51 -0700 From: huq@rockie.nsc.com (Syed Huq) Message-Id: <199806251840.LAA17922@rockie> To: ibis@vhdl.org Subject: Linux executable for IBIS parser(v2.1) IBISfans: A Linux executable of the IBIS parser 2.1.15 has been placed in the vhdl.org anonymous ftp site under: /pub/ibis/ibschk2+/linux/ This is a ELF binary and will run on a PC running Linux OS. Other IBIS utilties on Linux will be made available shortly. Regards, Syed. National Semiconductor Corp. From owner-ibis Thu Jun 25 18:17:45 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA04209 for ; Thu, 25 Jun 1998 18:17:44 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA03821; Thu, 25 Jun 1998 18:13:41 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA06042; Thu, 25 Jun 1998 18:13:40 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA25179; Thu, 25 Jun 98 18:13:39 PDT Date: Thu, 25 Jun 98 18:13:39 PDT Message-Id: <9806260113.AA25179@bob> To: ibis@eda.org Subject: IBIS UPLOADS ON eda.org To IBIS List: A number of items have been uploaded on eda.org. More items will be uploaded next week. Some of the uploads consist of: IBIS Summit Meeting Presentations for June 18, 1998: /pub/ibis/summits/dac98/ Example files for BIRD48.4, BIRD49.3, BIRD50.3 (Pending Version 3.2) /pub/ibis/samples/ver3.2/ Unofficial Version 3.1e with IBIS Summit Meeting Changes: /pub/ibis/wip/ver3_1e.ibs Version 2.1.15 ibischk2+ Linux executable (noted by Syed Huq) /pub/ibis/ibschk2+/linux Note, We are scheduling a vote on Version 3.1 of IBIS at the July 17, 1998 IBIS Meeting. The unofficial IBIS ver3_1e.ibs contains the contents we are considering, consistent with the ibischk3 parser development. More additions are scheduled with a Version 3.2 release as BIRDs are approved and the ibischk3 parser adds the approved features. So please review the ver3_1e.ibs document. (A cleaned version will be available next week.) Also note that eda.org may be down on Saturday, June 27, 1998 since the host is being relocated to Stanford University. See note below. Bob Ross Interconnectix Business Unit, Mentor Graphics Date: Wed, 24 Jun 1998 18:38:29 -0700 To: all-accounts@eda.org From: "Randolph E. (Randy) Harr" Subject: Move/Rename of {vhdl,eda,dasc,hdlcon,darpalum}.org As was indicated a few months ago, there will be a down time this Saturday, 27 June. We are planning to move the physical machine known as vhdl.org to Stanford University. We hope the move will improve reliability, provide greater accessibility for the volunteer sysops, and reduce our vulnerability to network attacks. We greatly appreciate the 5 years of service and support that Synopsys has provided since we initiated service. The server will be unavailable for probably most of the day on Saturday. It may not be available to you electronically for up to 12 hours as the router caches flush out over the truly international Internet network. If all goes well, the only indication that anything occurred will be that outgoing email appears to come from "server.eda.org" instead of "server.vhdl.org". This is because we will rename the SPARC eda.org and make vhdl.org a virtual host on it. vhdl.org and all the other domain names will continue to work as they have in the past. The SPARC itself will also have a new primary IP; going from 198.31.14.3 to 36.223.0.101; but this should not be visible to you. From owner-ibis Sun Jun 28 11:07:16 1998 Received: from muir.tanner.com (muir.tanner.com [206.117.185.3]) by server.eda.org (8.8.5/8.8.3) with SMTP id LAA02159 for ; Sun, 28 Jun 1998 11:07:15 -0700 (PDT) Received: from suntan1.tanner.com (unverified [192.100.143.1]) by muir.tanner.com (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 28 Jun 1998 11:09:19 -0700 Received: from wedgepc.tanner.com by suntan1.tanner.com (8.8.7/GPM/970211) with SMTP id LAA01290; Sun, 28 Jun 1998 11:04:19 -0700 Received: by localhost with Microsoft MAPI; Sun, 28 Jun 1998 11:02:22 -0700 Message-ID: <01BDA284.39FFF360.Scott.Wedge@tanner.com> From: Scott Wedge To: "ibis@vhdl.org" Subject: unsubscribe Date: Sun, 28 Jun 1998 11:02:21 -0700 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Mon Jun 29 03:49:55 1998 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id DAA03040 for ; Mon, 29 Jun 1998 03:49:54 -0700 (PDT) Received: from king.india.ti.com ([134.183.160.185]) by tower.ti.com (8.8.8) with ESMTP id FAA14127 for ; Mon, 29 Jun 1998 05:45:48 -0500 (CDT) Received: from asmhp4.india.ti.com (asmhp4 [134.183.193.4]) by king.india.ti.com (8.8.5/8.6.10) with ESMTP id QAA02319 for ; Mon, 29 Jun 1998 16:15:40 +0530 (IST) From: Arindam Raychaudhuri Received: (from scorpion@localhost) by asmhp4.india.ti.com (8.7.1/8.6.10) id FAA03770 for ibis@vhdl.org; Mon, 29 Jun 1998 05:45:37 -0500 (CDT) Date: Mon, 29 Jun 1998 05:45:37 -0500 (CDT) Message-Id: <199806291045.FAA03770@asmhp4.india.ti.com> To: ibis@vhdl.org Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-MD5: hdeBTR4qbJ4p96fDbDRqhQ== unsubscribe From owner-ibis Mon Jun 29 10:35:04 1998 Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA13672 for ; Mon, 29 Jun 1998 10:35:03 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id KAA24379 for ; Mon, 29 Jun 1998 10:37:48 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id KAA28255 for ; Mon, 29 Jun 1998 10:31:31 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id KAA27914; Mon, 29 Jun 1998 10:31:30 -0700 (PDT) Message-Id: <199806291731.KAA27914@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org Subject: IBIS Open Forum Face-to-Face Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 10:31:29 -0700 From: Stephen Peters DATE: 6/23/98 SUBJECT: 6/18/98 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1998 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Norio Matsui*, Raj Raghuram* Cadence Design (& UniCAD) C. Kumar, Don Telian, Patrick Riffault, Craig Lewis, Greg Fitzgerald, Paul Galloway, Patrick Dos Santos, Catherine Weiss, Alain Tribaudot, Geoffrey Ellis Cypress Bruce Wenniger* Digital Equipment Corp. Jeff Chu, Greg Edlund, Bob Haller Hewlett Packard (EEsof, etc.) Karl Kachigan, Henry Wu*, Paul Gregory High Design Technology Razvan Ene HyperLynx Kellee Crisafulli*, Matthew Flora* Incases Olaf Rethmeier, Scott Jacobson, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Will Hobbs*, Prakash Radhakrishnan, Mohammed Hawana*, Martin Chang* Columbia, SC (formerly NCR) Dave Moxley Mentor Graphics (Zeelan, Bob Ross*, George Opsahl, Mark Noneman, Interconnectix, etc.) Tom Dagostino, Karine Loudet, Jean Oudinot, Manuel De Almeida, Stephane Rousseau, Neven Orhanovic*, Mohamed Mahmoud* Mitsubishi Hoang Nguyen, Tam Cao Motorola (Ron Werner) National Semiconductor Syed Huq*, Cheng-Yang Kao, John Goldie, Ikchang Song North East Systems Associates Edward Sayre, Kathy Breda (NESA) NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Symbios Larry Barnes* Texas Instruments Thomas Fisher, Harvey Stiegler, Vincent Chang, Jean-Claude Perrin, Peter Forstner Thomson-CSF Jean-Marc Claveau, Laurent Duzaic, Saverio Lerose, Benoit Meyniel, Jean Lefebvre Viewlogic Jon Powell, Chris Rokusek*, Guy de Burgh, Gary Mandel VeriBest Ian Dodd*, David Weins, Ian Gabbitas VLSI Technology D.C. Sessions* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1998: Actel Eric Tardif, Emmonvelle Gaudin Aerospatiale Lionel Dreux, Claude Huet Alcatel (Bell, Espace, etc.) John Fitzpatrick, W. Temmerman, Laure Bessettes, Jean-Claude Pourtau, Daniel Peron ALS Design Yves Mouquet Ansoft Eric Bogatin Apple Fred Floresca, Danny Itani Apteq Design Systems Dan FitzPatrick Atmel Ali Baktashian* Avanti Nik Bannov* CERN Olivier Clere, Jean-Michel Sainson, Rudi Zurbroken Compaq Shariq Rahma Crucial Technology Rathna Reddy EIA Patti Rusher* EMC Fawn Engelmann, Fabrizio Zanella ENST, Paris Jean-Jacques Charlot European CAD Standardization Adam Morawiec Intitiative (ECSI) Fairchild Semiconductor Peter LaFlamme H.A.S Electronics Haruny Said IBM Richard Steinle*, Kevin Jackson* Intracon Design Ltd. Derek Laidlaw Philips Semiconductor Todd Andersen Scottish Electronics Robert Easson Manufacturing Center (SEMC) Seagate Vanessa Howard SGS-Thomson Philippe Lefevre Siemens Gerald Bannert, Bernhard Unger, Christian Marot, Miguel Hernandez, Gil Russell Sun Microsystems Lam Dong*, Kevin Ko* Symmetry Andy Hughes Tektronix Nassrin Ghahyasi Ultratest International Chris O'Connor Xilinx Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode July 17, 1998 (916) 356-9200 6-57211 5683488 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM The meeting was held all day at the Marriott Hotel, San Francisco, California. Bob Ross opened the meeting and everyone introduced themselves. The meeting attracted 26 people from 14 organizations with a good representation from semiconductor vendors, EDA tool vendors and users. Atmel, Cypress, Sun, and IBM had new attendees for 1998. Note that several presentations were given, and some of these will be uploaded to eda.org under /pub/ibis/summits/june98. Bob noted that the meeting would start with business and then continue with presentations and technical discussions. A number of BIRDs would be discussed in order to achieve general consensus so they could be voted on at the next meeting. IBIS 1997-1998 REVIEW - Bob Ross (Mentor Graphics) Bob Ross gave a summary of the activities for the year from June 1997 to the present. The interest in IBIS has become widespread with many IBIS models supplied by semiconductor and commercial vendors. Bob showed some participation numbers and linkages with IBIS from other organizations. Bob concluded that the main work continues toward Version 3.1 closure and ibischk3 completion. (This presentation will be uploaded to eda.org.) ELECTION OF OFFICERS (1998-1999) Bob Ross called for nominations. After several nominations and discussions of positions, D.C, Sessions moved that the following slate be elected by acclimation. This was seconded and the following slate was approved. Chair: Bob Ross, Interconnectix B.U., Mentor Graphics Vice-Chair: Stephen Peters, Intel Corporation Secretary: Matthew Flora, HyperLynx, Inc. Librarian: Jon Powell, Viewlogic Patti Rusher presented recognition plaques with the new IBIS logos to last years officers: Jon Powell, Librarian, Stephen Peters, Secretary, Syed Huq, Vice-Chair, and Bob Ross, Chair. Syed plans to continuing managing the EIA/IBIS Web Site. (Added Note: Bob thanks Syed for his outstanding service as Vice-Chair to the EIA IBIS Open Forum and for promoting IBIS internally at National. Also, Bob thanks Stephen for supplying the EIA IBIS Open Forum Fact Sheet for the EIA booth at the Design Automation Conference (DAC). Finally, Bob thanks Patti for developing the large IBIS poster for the EIA booth (with a high resolution per IBIS logo) and for handling the EIA IBIS Open Forum meeting arrangements including the outstanding lunch.) OPENS FOR NEW ISSUES (Some during the meeting) Will Hobbs on IBIS Evolution and Adoption (presentation) Will Hobbs on actual processes, parser, timeline Will Hobbs on Version 4.0 needs Will Hobbs on EDA Tool Support for Version 3.1 Chris Rokusek on ibischk2+ Version 2.1.16 executables Kellee Chrisafulli on Connector Model Status D.C. Sessions on SSO Considerations - (ad hoc presentation) IBIS MODEL VALIDATION ON LINUX - Syed Huq (National Semiconductor) Syed Huq shared his experiences using the Linux operating system on personal computers. This operating system is attractive because it -- along with various support utilities -- are free. As part of IBIS model validation, Syed listed these steps: Visual Inspection, s2iplt, Parser Inspection, and Simulation. IBIS tools can be made available on Linux. Syed will make available the ibischk2+ Version 2.1.15, and s2ibis2 utilities. s2iplt can be installed by simply changing the perl path to /usr/bin/perl. Simulators need to be compiled on Linux to complete the task. (This presentation will be uploaded to eda.org.) AR - Syed Huq provide Linux executables for uploading to eda.org [DONE] SIMULATION TOOL ENHANCEMENTS - Arpad Muranyi (Intel) Arpad Muranyi noted that new problems arise from fast buses. Interconnect delays are a major part of the bus clock cycle time. Reflections, cross talk, SSO noise, ring back, ring, etc. can significantly alter interconnect delays. Arpad noted that RAMBUS and AGP architectures are source- synchronous, making skews the most relevant factor. Source-synchronous architecture (where the clock and signal are initiated from the same chip) require only that the delays be matched and the skews be minimized. A large number of simulations are required to deal with length variations, cross talk effects and load mismatch, and these simulations need to be automated. Arpad advocates flexible simulator architectures that supports batch mode operation and can be controlled by its own programming language. Arpad also supports better graphical display for parameter interaction and statistical plotting of Monte Carlo data. A number of examples including a 3-D presentations illustrated this. Arpad also presented some flight time measurement considerations. The test load for which Tco is based is different than the actual load - a source of uncertainty. The tester slope method of specification at the receiver (usually 1 V/ns) is used to refine the limits. Slower waveforms at the receiver can create setup violations or conservative flight times. measurement enhancements. Arpad suggested a method to measure flight time using the slope specification. (This presentation may be uploaded to eda.org.) A short discussion followed this presentation, in which Larry Barnes mentioned a presentation from the uWave symposium on doing simulation in the frequency domain. This is supposed to yield faster results. D.C. Sessions also commented that if source synchronous clocking is to become the norm, the industry needed a better/more realistic way to spec input thresholds. IBIS EVOLUTION AND ADOPTION (New Presentation) - Will Hobbs (Intel) Will Hobbs also supported the notion that models and simulators must keep up with technological advances. Models need to be comprehensive and include some subtle effects. Finally, Will advocates releasing IBIS Version 3.1 along with its parser as soon as possible. The development has already taken too long. The committee needs to clarify that EIA supports semiconductor vendors releasing Version 3.1 level IBIS models. Will showed a case study of real problem where a glitch was due to a combination of effects. These effects included SSO interactions for specific patterns, coincident reflections, and noise margin erosion associated with termination plane noise, routing topology, package routing, Vcc bypassing, connector inductance, and sub-optimal ground return path. Will questioned whether behavioral simulation has reached its limits. If not, then the IBIS needs to push its limits to address emerging needs and concerns. EDA TOOL SUPPORT FOR VERSION 3.1 (New Item) Bob asked the EDA Tool vendors to state what there support plans were for Version 3.1 of IBIS. The responses ranged from future commitment to support the features of IBIS Version 3.1 to actual support being phased in. A discussion followed on the 'chicken and egg' problem of new models and simulators. Mohammed Hawana (Intel) stated that the simulation tools are needed before models are released. Stephen Peters (Intel) and Kellee Crisafulli (Hyperlynx) both countered that for technical and business reasons models must be made available before tools vendors will commit to supporting new IBIS features. BIRD46.1 - RELAXATION OF SOME IBIS FILE NAME RESTRICTIONS Bob Ross summarized BIRD46.1 changing the maximum number of characters in a file name from 8 to 20 characters for .ibs, .pkg, and .ebd file names. This had been discussed at the previous meeting and everyone had supported this change. Bob called for a vote. BIRD46.1 was approved without objections. BIRD48.3 - ADD SUBMODEL BIRD49.2 - ADD SUBMODEL DYNAMIC CLAMPS BIRD50.2 - ADD SUBMODEL BUS HOLD Bob Ross started the discussion by indicating that he prepared a draft of these BIRDs, but did not send them out on the reflector since many IBIS individuals would out that week at DAC. Instead, Bob presented some examples of how the BIRDs would be implemented. The first example showed the new syntax using the [Add Submodel] keyword under the [Model]. The second column showed submodes 'Non-Driving' and 'All' (in place of the reserved word 'NA'). The functionality of the referenced submodels would be added to the top-level models from which the submodels were called. The submodel for dynamic clamp operation was illustrated for the Triggered, Static, and Clocked modes. The added submodel adds additional power or ground clamps using the [POWER Clamp] and [GND Clamp] keywords. The Triggered mode showed both the appropriate trigger subparameters and the pulse tables. The static mode showed the exclusion of the pulse table. The clocked mode showed the pulse table, but no trigger subparameters. All examples showed a [Voltage Range] keyword. Bob noted that the Clocked mode was controversial. It could only be modeled properly by introducing timing details with the IBIS format - a direction beyond the scope of IBIS. The actual clocked delays would have to be made relative to a separate clock during simulation, and the delays controlled individually for each instance of the model in a net. Arpad Muranyi noted that this was a real operation. However, it could be approximated using the Triggered mode with some hard work. In order to move forward, Bob proposed that the Clocked mode would not be included in the dynamic clamp proposal. The mode or a better solution, if found could be added later. Bob then illustrated the bus hold operation with [Pullup] and [Pulldown] keywords and a [Ramp]. Bob elaborated that while the bus hold structure was described, the syntax was also appropriate for other stronger termination schemes that were being developed. D.C. Sessions noted that this was an active latching scheme. In practice a variation with two trigger voltages was possible on a single transition. For a rising transition, the first trigger would turn off the pulldown transistor to put the submodel in a 3-state mode, and then the second trigger would turn on the pullup transistor. However, D.C. stated that the trigger levels (often spread on a 1/3 Vcc and 2/3 Vcc levels) were not significant and one approximation level was adequate. Arpad Muranyi noted that the functionality could be used for active termination. However, the group supported that the 'bus hold' name was still appropriate since it was a recognized feature in digital devices. In the discussion that followed, Bob listed some Add Submodel issues. These were discussed and the following changes were made: (1) [Add Submodel] could be called from Terminator models. D.C. noted that dynamic terminators were a reality. (2) The submodel mode entry changed from 'NA' to 'All'. (3) The [Voltage Range], [Temperature Range] and reference voltage entries are inherited from the top-level model. These keywords are not allowed in a submodel. This avoids the confusion of which entry takes precedence. (The keywords could be entered in as comments to document the voltage references that are assumed within the submodel). This reduces the allowed keywords for a submodel to be [GND Clamp], [POWER Clamp], [Pullup], [Pulldown], [Ramp], [Rising Waveform], [Falling Waveform], and the new keywords for submodel. (4) C_comp is not defined for a submodel. This avoids the problem of deciding whether (scattered) submodel entry values are added to the top-level C_comp (and if the mode of operation is a concern). (5) Keywords that are not meaningful for the particular application (for example, the [Pullup] and [Pulldown] keywords for Dynamic_clamp submodel type) would be ignored - similar to how keywords under [Model] are handled. This was mentioned, but not fully described at the meeting. (6) Clocked mode would not be included for dynamic clamps. AR - Bob Ross generate revised BIRD48.4, BIRD49.3, and BIRD50.3 with the above changes included [Done]. AR - Bob Ross upload example files for the above BIRDs. BIRD42.3 - MODELING CURRENT WAVEFORMS Bob Ross introduced BIRD42.3. Several people still questioned whether the additional current tables provided enough valuable information to justify their inclusion. D.C. Sessions is still requesting a real test case showing that BIRD42.3 gives useful information beyond the existing two voltage method. Since we need to decide on this functionality soon, Bob is putting BIRD42.3 for a vote at the next meeting. ACTIVITIES OF EIAJ IMIC STANDARD - Norio Matsui (Applied Simulation Technology) Norio Matsui provided a comprehensive update on the progress of the Electronic Industries Association of Japan (EIAJ) activity on behalf of the I/O Interface Model Project Group and the Electrical Characterization of Semiconductor Packages Project Group. Norio illustrated the need and basic ideas under the Interface Model for Integrated Circuit (IMIC) document. The need is to deal with signal integrity (SI), power integrity (PI) and electromagnetic interference (EMI) issues. The IMIC approach is to consider power and ground plane modeling using a network description, and a table description for devices extended from Berkeley Spice. This approach allows flexible equivalent circuitry for all types of devices without revealing proprietary information. Spice to IMIC converters are under development. Also IMIC to IBIS conversion is planned. Norio listed the participants in Project and Package Groups and noted that Version 1.1 of IMIC has been released. The home pages are listed: http://tsc.eiaj.or.jp http://www.eiaj.or.jp Norio showed good correlation with HSpice analysis and IMIC analysis for a 48 pin transceiver model with coupled package model pins. Based on existing density trends, Norio sees packages complexity increasing with the number of pins approaching 10,000 around year 2000. New activities for 1998 include continued evaluation (IMIC vs HSpice, IBIS, and measurement), improved modeling technology (slew rate control, current flow from Vcc to GND), EMI model, IMIC to IBIS conversion, and more examples of packages including a power and ground model. CONNECTOR MODELING STATUS (New Item) As a new item Kellee Chrisafulli reviewed the IBIS Users Group connector model standardization. Kellee indicated that the group is headed by Fabrizio Zanella of EMC and consists of participants from Molex, Teradyne, Berg, Ansoft, and Hyperlynx. The goal is to provide a format that can work with Spice and Field solver applications. Kellee listed a number of points under discussion (without elaboration). The committee is considering (series) cascaded L/R/C sections with coupling using a matrix format. The connector vendors want maximum bandwidth (minimum risetime) information such that EDA simulators will issue soft warnings if the limits are exceeded. The sections sections can be extracted from 2-D or 3-D solvers, or by other methods such as by LCZ or TDR measurements, with or without an external reference. Partial or loop inductances can be formatted. Kellee invited others to participate in the weekly discussions. SSO CONSIDERATIONS (Ad hoc Presentation) - D.C. Sessions (VLSI Technology) D.C. Sessions sketched and showed the equations for estimating SSO effects on timing measurements. His example derived from a real situation showed that SSO effects for an 8:1:1 I/O:PWR:GND ration would generate a 1.33ns time constant to 63% value. For a .35u design he showed that the Tco(max) number 90% changed from 1.9ns without considering SSO to 3.0ns considering SSO - 30% of the cycle time. D.C. noted that currently customers must deal with this the hard way. s2ibis can be used to generate a best case model with no supply inductance for hold analysis. s2ibis can also be used to generate waveforms with SSO power and ground inductance (single values multiplied by the number of switching stages) to get degraded waveforms. However, he consider this to be a kludge. D.C finished his presentation by emphasizing the the various simulation tools need better support for SSO type simulations. (This presentation will be uploaded to eda.org.) VERSION 3.1/3.2 AND IBISCHK3 RELEASE PLANS (With Some New Items) As a result of the expressed need to get both IBIS Version 3.1 and the ibischk3 parser ratified as soon as possible, Bob Ross outlined the following plan for discussion: The development of the IBISCHK2 parser is effectively done. We will vote at the next meeting to close (freeze) this effort. Ratify IBIS Version 3.1 as just a Version 3.0 editorial upgrade consistent with the ibischk3 parser work to date. No recent enhancement BIRD would be included since that would result in a parser turn. Focus on cleaning up some specification technical and editorial issues. This could be done by the next meeting. Ratify the ibischk3 parser at the next meeting. Atul Agarwal is ready to send ibischk3 Version 3.0.2 immediately after Bob reports back to him on some questions. All the issues raised so far should be resolved. The ibischk3 portion should be in excellent shape. The ebdchk3 should also have all problems and questions resolved, but we should learn more as we get experience with real test cases. The released parser will be designated ibischk3 Version 3.1.0. Bob noted that this release should have one executable with the EBD checking initiated with the -ebd flag. Move the new enhancement BIRDs in to an IBIS Version 3.2 release and to make the corresponding ibischk3 Version 3.2.0 with the new features. Expect to make the release as soon as possible and before the end of the year. The technical features moved to the Version 3.2 release are: BIRD51 - 3-state_ECL Model Type BIRD46.1 - 20 Character File Name Extension BIRD48-50 - Add Submodel Extension BIRD42.3 - Current Tables (if ratified) Any others that are immediately processed Bob discussed some technical questions that were raised by Atul during the development of the ibischk3 and ebdchk3 parser. Technically BIRDs would need to be generated to resolve these details. However, the next version of the IBIS document would include the committee decisions. These issues were discussed: (1) The pin length name is five characters for the [Pin] keyword and eight characters for the [Pin List] keyword for EBD files. The ebdchk3 parser currently test for a five character limit only per some early advice. The committee resolved to keep the Specification as is and to ask for a change in the parser code. [The change will be done]. (2) There are some restrictions on the order of certain keywords that are assumed in ibischk3 and ebdchk3 testing. For example, the keywords giving the number of entries and list order are presumed to come before the actual lists. This needs to be documented. The committee resolved to accept these practical restrictions and just document them as editorial additions. (3) For EBD files, Fork and Endfork must be on separate lines to avoid some ambiguity in detecting some error conditions. (This would not be needed if the other syntax is correct.) The committee accepted this as an editorial change. (4) Similarly, for EBD files the section sequence 'Len = ... /' must all be on one line to avoid some ambiguity in testing for errors. This restriction was also accepted and will be included as an editorial change. (5) As an editorial note, the reserved word 'NC' needs to be listed along with the subparameters as entries for EBD files. It is currently buried in the description. This can be done as an editorial change. (6) The length limit of the reference designator was not given. The existing parser sets the limit to five characters based on an early recommendation. However, Bob recommended this be specified as ten characters. This was discussed along with the fact that the reference designator syntax is standardized. Ten characters would allow the multiple board numbering systems with the first set of characters to correspond do different boards. Ten characters would also work with the just approved BIRD46.1 extending the file name limit to twenty characters. This change was approved. [The parser will be changed.] (7) Bob asked whether the maximum number of Vgs optional tables under the [Series MOSFET] keyword needs to be specified. Currently the limit is set to a very high value of 100. This will be entered, if needed into the Specification. (8) While the [Series MOSFET] keyword was never intended to be used for the [Off] condition, this was never prohibited. The document will not prohibit this usage, nor will the parser test for this. (9) BIRD52 - [Driver Schedule] Clarifications: Bob noted that this is really an editorial BIRD that states that [Driver Schedule] is located under the [Model] keyword. Bob expects the substance of BIRD52 to be added to the document. Also, the comment that an example is needed will be addressed. So Bob plans to have BIRD52 voted on at the next meeting. (10) Matthew Flora added that the [Pin] subparameters R_pin, L_pin and C_pin can be in any order according to the parser tests. This was not clear in the document. This note can be added. As part of the closure and completion of the BIRDs, Bob will generate example files showing how the new BIRDs would be implemented. These will provide more test cases for parser development. In particular, BIRD48-50 and the [Driver Schedule] keywords will be illustrated. AR - Bob Ross develop and upload example files for the Version 3.1 and Version 3.2 IBIS features. Regarding Editorial Completion, Stephen Peters volunteered to help in this process. Bob and Matthew will join. Anyone else is welcome. We many need to meet for a day or so to go over some details. BIRD44 - Interpretation of min/max/weak/strong Data: Bob indicated that BIRD44 needs to be closed. No progress has occurred, and the specification has advanced so that it may need to be reconstructed. Bob will put it for a vote at the next meeting. To summarize, the plan is to resolve all of the open BIRDs at the next meeting, to generate a draft Version 3.1 (and Version 3.1e file) for review and for voting at the next meeting, to get the latest Version 3.0.2 parser code (to be sent shortly) for review, and to ratify it as the Version 3.1.0 parser at the next meeting. Work will then continue to include the new features in a Version 3.2 IBIS release and a corresponding Version 3.2.0 parser release. AR - Bob Ross upload the Version 3.1e and draft Version 3.1 IBIS document for review. IBISCHK2+ PARSER PLANS (New Item) Chris Rokusek asked what the plans were for ibischk2+. Bob Ross suggested that one final release be generated with all the fixes that could be done against existing BUGs. This would be incorporated in ibischk2+ and also in ibischk3. From that point on only ibischk3 would be maintained. Note, the ibischk2+ code is included in ibischk3. (Atul Agarwal advises Bob that the approved BUG fixes through BUG28 are included in ibischk3 and the ibischk2+ portion of ibischk3.) IBIS VERSION 4.0 FEATURES Before adjourning, the group listed a number of IBIS model and simulation features that might be candidates for IBIS Version 4.0. This generated some discussion. The features are listed without comment or clarification: (1) Better Input Characterization, also Variable Capacitance (2) Package Model for SSO (3) Supply Distribution Beyond [Pin Mapping] (4) Lead Coupling in Package Group (large K factors) (5) Interface to Structural Models (6) Interface to Equation Description (7) IBIS Models Invoke External Executable (OMI Interface) (8) Connector Models (9) Die in Multiple Packages (10) Package Model Extensions for Coupling NEXT MEETING: The next meeting will be on Friday, July 17, 1998 from 8:00 AM to 10:00 AM. Votes are scheduled on the BIRD42.3, BIRD44, BIRD48.4, BIRD49.3, BIRD50.3, and BIRD52.1. Also a ratification vote is scheduled on IBIS Version 3.1. The acceptance of the ibischk3 parser will be put to a vote. Stephen Peters will conduct the meeting since Bob will be on vacation. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentorg.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ==============================================================================