From owner-ibis Tue Mar 2 11:13:28 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA18060; Tue, 2 Mar 1999 11:13:27 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA16660; Tue, 2 Mar 1999 11:07:40 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA01474; Tue, 2 Mar 1999 11:07:37 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA07106; Tue, 2 Mar 99 11:07:38 PST Date: Tue, 2 Mar 99 11:07:38 PST Message-Id: <9903021907.AA07106@bob> To: ibis-users@eda.org, ibis@eda.org, si-list@silab.eng.sun.com Subject: AGENDA - EUROPEAN IBIS SUMMIT MEETING To All: Below is the Agenda showing the planned sequence of presentations. Exact times are not given since we will be flexible to allow discussions, unscheduled topics and questions topics. The General Questions and Discussions Topic shown in the AGENDA may occur at any time. See you in Munich! Best Regards Bob Ross Mentor Graphics A G E N D A E U R O P E A N I B I S S U M M I T M E E T I N G 12 PM - 6 PM, Tuesday, March 9, 1999 ASTRON HOTEL/Neue Messe Eggenfeldener Strasse 100 Munich, Germany Co-sponsored by Mentor Graphics, INCASES, High Design Technology (HDT) AGENDA: 12:00: LUNCH (Provided to all participants) 13:00 MEETING BEGINS Current IBIS Activities and Issues Bob Ross, Mentor Graphics Detecting Typical Bugs in IBIS Models Werner Rissiek, INCASES Engineering Validation of an Enhanced Two Waveform Behavioral Model Bernhard Unger, Siemens AG IBIS Version 3.2 Update Stephen Peters, Intel General Questions and Discussions - IBIS Interpretation 15:00 BREAK IBIS Management and CHECK at Siemens ICN Gerald Bannert, Siemens DOGEN, An Internal Model Library Management Tool Hans Pichlmaier, Siemens IBIS Future Requirements Stephen Peters, Intel Future Requirements on Frequency Dependent Package and MCM Modeling Werner Rissiek, INCASES Engineering General Questions and Discussions - Future Requirements - Any other topic of interest - Meeting Wrapup 18:00 END OF MEETING From owner-ibis Tue Mar 2 12:01:38 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA18282; Tue, 2 Mar 1999 12:01:38 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id TAA08129; Tue, 2 Mar 1999 19:56:21 GMT Message-Id: <199903021956.TAA08129@thalia.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.2232.9) id ; Tue, 2 Mar 1999 11:56:20 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@eda.org\" " , "\"ibis@eda.org\" " , "\"si-list@silab.eng.sun.com\" " Subject: SI opening at Intel, Folsom, CA Date: Tue, 2 Mar 1999 11:55:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Intel Corporation has an immediate opening for a signal integrity engineer at the Platform Component Division (PCD) in Folsom California. If you are qualified and interested please contact and/or send resume to Henri Maramis via EMAIL or phone at henri.maramis@intel.com (916) 356-6413. Responsibilities: Designs and performs analog simulations of system level interconnects for PC based platforms. Prepares I/O buffer models, transmission line models, and packaging parasitic models for accurate correlated simulations. Performs system level critical path timing, pre and post layout analyses. Uses engineering judgment in data analysis to establish design process and CAD tool flow. U.S. typically requires a Bachelor's Degree in Elec. Eng. or Comp. Eng. +3 years experience, or a Master's Degree +2 years experience. Skills: Knowledge/experience with IBIS models and simulation/timing tools, such as HSPICE, Quad Design, Cadence SpecctraQuest, Interconnectix, and Timing Designer. Extended coursework in electromagnetic fields and waves, and transmission line analysis. Knowledge of PC based system architecture, high speed bus interfaces, and high performance signaling techniques. This includes bus and system timing, signal integrity analysis, cross talk analysis, ground bounce analysis, power integrity analysis, as well as board layout techniques. From owner-ibis Tue Mar 2 13:32:19 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA18561 for ; Tue, 2 Mar 1999 13:32:19 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id VAA29901 for ; Tue, 2 Mar 1999 21:27:03 GMT Message-Id: <199903022127.VAA29901@thalia.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.2232.9) id ; Tue, 2 Mar 1999 13:27:02 -0800 From: "Muranyi, Arpad" To: "\"ibis@eda.org\" " Subject: BIRD 58 Date: Tue, 2 Mar 1999 13:26:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" **************************************************************************** ** **************************************************************************** ** BIRD ID#: 58 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99 DATE ACCEPTED BY IBIS OPEN FORUM: pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) does not provide enough information to the model maker and EDA tool vendor on essential details of this keyword. The spec. can be interpreted in several different ways which can lead to serious discrepancies and consequences. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: One paragraph from BIRD35.3 is included in the [Driver Schedule] usage rules section of the specification. This portion seems to have been inadvertently left out from the spec. and explains the gray areas. The additional words do not change the original intent behind this keyword. It is only added to spell out how the keyword must be used so that the model maker and EDA tool vendor could be in agreement on how the model works. The new section is marked with a "*" character at the beginning of each line. |=========================================================================== == | 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] keyword overrides any existing [Pullup], |* [Pulldown] and [Ramp] or [Rising Waveform] and [Falling |* Waveform] data for that model. However, the required tables |* for [Model] are still required for backwards compatibility |* reasons for simulators which do not support multi-staged |* switching. This information can be used as a composite model |* cross-check, although the resulting model may not perform in |* the same manner as the multi-stage model. | | 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. | | Note: In a future release, the [Driver Schedule] keyword may | be replaced by a newer method of specification that is | consistent with some other planned extensions. However, the | [Driver Schedule] syntax will continue to be supported. |--------------------------------------------------------------------------- -- [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: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using the [Driver Schedule] keyword failed. The initial testing of this model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several people, it became apparent that the specification does not mention some of the key information that is necessary to build a correct IBIS model for this kind of a buffer. The following paragraph in BIRD35.3 contains the missing information which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from the specification, and should be pasted into the appropriate location as shown above. (Note that the first and second sentences are deleted because they do not provide new information in the context above). "The new keyword [Driver Schedule] provides a syntax for sequencing other models. This is given as a keyword under the [Model] keyword. It overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and [Falling Waveform] data for that model. However, the required tables for [Model] are still required for backwards compatibility reasons for simulators which do not support multi-staged switching. This information can be used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules which were documented in BIRD35.3 and was implemented accordingly in ICX. **************************************************************************** ** From owner-ibis Tue Mar 2 13:49:27 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA18658 for ; Tue, 2 Mar 1999 13:49:26 -0800 (PST) Received: from pcocd2.intel.com (pcocd2.intel.com [132.233.250.145]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id VAA02009 for ; Tue, 2 Mar 1999 21:44:11 GMT Received: from fri2010 (fri2010-fddi.fm.intel.com [132.233.105.118]) by pcocd2.intel.com (8.8.5/8.8.5) with SMTP id NAA24414 for ; Tue, 2 Mar 1999 13:44:10 -0800 (PST) From: Arpad Muranyi - PCD~ Received: by fri2010 (AIX 4.1/UCB 5.64/FMDT-RS6000) id AA54618; Tue, 2 Mar 1999 13:44:09 -0800 Date: Tue, 2 Mar 1999 13:44:09 -0800 Message-Id: <9903022144.AA54618@fri2010> To: ibis@eda.org This is just a re-send in attempt to get the longer lines not wrap around. Arpad ****************************************************************************** ****************************************************************************** BIRD ID#: 58 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99 DATE ACCEPTED BY IBIS OPEN FORUM: pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) does not provide enough information to the model maker and EDA tool vendor on essential details of this keyword. The spec. can be interpreted in several different ways which can lead to serious discrepancies and consequences. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: One paragraph from BIRD35.3 is included in the [Driver Schedule] usage rules section of the specification. This portion seems to have been inadvertently left out from the spec. and explains the gray areas. The additional words do not change the original intent behind this keyword. It is only added to spell out how the keyword must be used so that the model maker and EDA tool vendor could be in agreement on how the model works. The new section is marked with a "*" character at the beginning of each line. |============================================================================= | 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] keyword overrides any existing [Pullup], |* [Pulldown] and [Ramp] or [Rising Waveform] and [Falling |* Waveform] data for that model. However, the required tables |* for [Model] are still required for backwards compatibility |* reasons for simulators which do not support multi-staged |* switching. This information can be used as a composite model |* cross-check, although the resulting model may not perform in |* the same manner as the multi-stage model. | | 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. | | Note: In a future release, the [Driver Schedule] keyword may | be replaced by a newer method of specification that is | consistent with some other planned extensions. However, the | [Driver Schedule] syntax will continue to be supported. |----------------------------------------------------------------------------- [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: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using the [Driver Schedule] keyword failed. The initial testing of this model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several people, it became apparent that the specification does not mention some of the key information that is necessary to build a correct IBIS model for this kind of a buffer. The following paragraph in BIRD35.3 contains the missing information which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from the specification, and should be pasted into the appropriate location as shown above. (Note that the first and second sentences are deleted because they do not provide new information in the context above). "The new keyword [Driver Schedule] provides a syntax for sequencing other models. This is given as a keyword under the [Model] keyword. It overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and [Falling Waveform] data for that model. However, the required tables for [Model] are still required for backwards compatibility reasons for simulators which do not support multi-staged switching. This information can be used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules which were documented in BIRD35.3 and was implemented accordingly in ICX. ****************************************************************************** From owner-ibis Wed Mar 3 09:10:55 1999 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 JAA21522; Wed, 3 Mar 1999 09:10:55 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA16736; Wed, 3 Mar 1999 09:16:07 -0800 (PST) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id JAA29832; Wed, 3 Mar 1999 09:05:38 -0800 (PST) Received: from ichips.intel.com (loopback.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id JAA02076; Wed, 3 Mar 1999 09:05:37 -0800 (PST) Message-Id: <199903031705.JAA02076@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: Job Announcements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Mar 1999 09:05:37 -0800 From: Stephen Peters Hello All: For everyone's information, the official IBIS open forum policy regarding job postings is as follows (quote is from an earlier e-mail from the IBIS Open Forum Chair): "We have established a policy that the IBIS reflectors are not to be used for recruitment activities because of our membership with EIA (which disallows this) and because the IBIS activity and participation is company sponsored." Remember that the SI list is available for job postings. Thanks for your cooperation. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum From owner-ibis Wed Mar 3 10:23:11 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA21686; Wed, 3 Mar 1999 10:23:10 -0800 (PST) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id SAA15832; Wed, 3 Mar 1999 18:17:54 GMT Message-Id: <199903031817.SAA15832@calliope1.fm.intel.com> Received: by FMSMSX19 with Internet Mail Service (5.5.2448.0) id ; Wed, 3 Mar 1999 10:17:53 -0800 From: "Muranyi, Arpad" To: "\"ibis@eda.org\" " , "\"ibis-users@eda.org\" " Subject: RE: Job Announcements Date: Wed, 3 Mar 1999 10:17:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain I apologize for the posting on these two reflectors, I was not aware of this policy. Arpad ============================================================================ = Hello All: For everyone's information, the official IBIS open forum policy regarding job postings is as follows (quote is from an earlier e-mail from the IBIS Open Forum Chair): "We have established a policy that the IBIS reflectors are not to be used for recruitment activities because of our membership with EIA (which disallows this) and because the IBIS activity and participation is company sponsored." Remember that the SI list is available for job postings. Thanks for your cooperation. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum From owner-ibis Thu Mar 4 11:48:07 1999 Received: from mailhost.pii.com (mailhost.pii.com [192.77.209.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA25636 for ; Thu, 4 Mar 1999 11:48:06 -0800 (PST) Received: from nashex.pii.com (nashex.pii.com [192.168.203.242]) by mailhost.pii.com (8.9.1/8.9.1/Praegitzer-antispam) with ESMTP id LAA15290 for ; Thu, 4 Mar 1999 11:43:09 -0800 (PST) Received: by nashex.pii.com with Internet Mail Service (5.5.1960.3) id <19DXY9ZF>; Thu, 4 Mar 1999 14:39:59 -0500 Message-ID: <31F863AE4B2DD211A01900A0C9CFAD3C0BF9F7@nashex.pii.com> From: Rick Newell To: ibis@eda.org Subject: add name to list Date: Thu, 4 Mar 1999 14:39:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain subscribe ibis-list From owner-ibis Wed Mar 10 22:26:17 1999 Received: from public3.bta.net.cn (public3.bta.net.cn [202.96.0.193]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA17105 for ; Wed, 10 Mar 1999 22:26:15 -0800 (PST) Received: from frank (ab-1-96.bta.net.cn [202.99.63.100]) by public3.bta.net.cn (8.9.1/8.9.1) with SMTP id OAA19552 for ; Thu, 11 Mar 1999 14:20:51 +0800 (GMT) Message-Id: X-Sender: viewprc@public3.bta.net.cn X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 11 Mar 1999 13:44:48 +0000 To: ibis@vhdl.org From: Frank Xiao Private Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" unsubscribe Frank From owner-ibis Fri Mar 12 09:38:01 1999 Received: from hotmail.com (wya-lfd88.hotmail.com [207.82.252.152]) by server.eda.org (8.8.5/8.8.3) with SMTP id JAA22573 for ; Fri, 12 Mar 1999 09:38:01 -0800 (PST) Received: (qmail 21766 invoked by uid 65534); 12 Mar 1999 17:32:10 -0000 Message-ID: <19990312173210.21764.qmail@hotmail.com> Received: from 216.111.147.103 by www.hotmail.com with HTTP; Fri, 12 Mar 1999 09:32:09 PST X-Originating-IP: [216.111.147.103] From: "Jin-Man Han" To: ibis@vhdl.org Subject: unsubscribe Date: Fri, 12 Mar 1999 09:32:09 PST Mime-Version: 1.0 Content-type: text/plain Unsuscribe Jin-Man Han Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Fri Mar 12 11:27:01 1999 Received: from mailbox.imicorp.com (mailbox.imicorp.com [206.86.75.200]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA22930 for ; Fri, 12 Mar 1999 11:26:55 -0800 (PST) Received: from imicorp.com ([206.86.75.229]) by mailbox.imicorp.com (8.8.5/TDH060497) with ESMTP id XAA05361 for ; Thu, 11 Mar 1999 23:19:35 -0800 Sender: orberk@imicorp.com Message-ID: <36E969B2.85602D7E@imicorp.com> Date: Fri, 12 Mar 1999 11:23:30 -0800 From: omer_orberk X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@vhdl.org Subject: Unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Unsubscribe Omer Orberk From owner-ibis Wed Mar 17 15:36:16 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA11944 for ; Wed, 17 Mar 1999 15:36:10 -0800 (PST) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id PAA29055 for ; Wed, 17 Mar 1999 15:37:36 -0800 Message-Id: <3.0.5.32.19990317153045.00c0d570@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Mar 1999 15:30:45 -0100 To: ibis@eda.org From: Matthew Flora Subject: IBIS Summit Meeting Minutes 9 Mar 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 3/17/99 SUBJECT: 3/9/99 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram, Norio Matsui Avanti Nik Bannov Cadence Design Mike LaBonte Cisco Systems Syed Huq Compaq Bob Haller, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) Fairchild Semiconductor Peter LaFlamme, Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene* HyperLynx Matthew Flora, Kellee Crisafulli IBM Greg Edlund, Michael Cohen, Praven Patel Incases Olaf Rethmeier, Werner Rissiek*, David Eagles*, Wilhelm Arnoldi*, Ulrich Losch* Intel Corporation Stephen Peters*, Arpad Muranyi, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson, Jeff Day, Richard Mellitz, Peter Liou LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad*, Jean Oudinot*, Markku Kukkanen*, Martin Grober*, Karine Loudet* Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen*, Peter Christiaans* Quantic EMC (Mike Ventham) Texas Instruments Jean-Claude Perrin*, Shankar Balasubramaniah, Ramzi Ammar Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Chris Rokusek, Guy de Burgh*, Cary Mandel*, (Jon Powell), VeriBest Ian Dodd VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel* Analytical Edge Robert Easson* Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger* Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf* ECI Telecom Daniel Adar* EIA Patti Rusher Electronique Catherine Gross* EFM Consulting Ekkehard Miersch* EMC Corporation Fabrizio Zanella Intracon Design Mike Osmond* FCI John Ellis Litton Systems Robert Bremer Molex Incorporated Gus Panella Nortel Networks (& Viewlogic) Martin Hall* Oce Printing Systems Ernst Deiringer* Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Siemens Bernhard Unger*, Christian Mitschke*, Manfred Maurer*, Peter Kaiser*, Wolfram Meyer*, Gerald Bannert*, Harmut Ibowski*, Hans Pichlmaier*, Eckhard Lenski*, Kortheuer Udo*, Katja Zuleeg*, Christian Sporrer* Signals & Systems Engineering Tom Hawkins SiQual Scott McMorrow STMicroelectronics Fabrice Boissieres*, Philippe LeFevre* StorageTek Nick Krull Sun Microsystems Victor Chang Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel* Xilinx Susan Wu (Unaffiliatied, Retired) Bruce Wenniger 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 March 26, 1999 (916) 356-9200 2-306362 7132187 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 ----------------------------------- IBIS SUMMIT MEETING The IBIS Summit Meeting was held at the Astron Hotel in Munich, Germany, near the site of the DATE99 (Design Automation and Test in Europe) conference. About 42 people representing 19 organizations participated in the meeting. These minutes just briefly note some of the meeting content and some of its discussions. Most of the presentations and related documents are available on the World Wide Web at: http://www.eda.org/pub/ibis/summits/mar99/ INTRODUCTIONS - Bob Ross (Mentor Graphics) After a delicious buffet lunch provided at the Astron Hotel for all participants, Bob Ross opened the IBIS meeting by introducing himself and Vice Chairman Stephen Peters. Bob also introduced the sponsors of the lunch and meeting: Mentor Graphics, INCASES and High Design Technology (HDT). Bob asked the participants to introduce themselves and noted that there were a large number of users of EDA tools and IBIS models present. Bob thanked Karine Loudet of Mentor Graphics for her excellent work in handling the local arrangements and producing the poster (which arrived late). Bob Ross called for Ad Hoc presentations and discussion topics. No Ad Hoc presentations were offered, but a last minute presentation was inserted: Fabrice Boissiere - Generation of IBIS Models at STMicroelectronics Later, after the break, Bob introduced Catherine Gross, a technical editor of the French magazine Electronique. The article "Modeles Ibis, Mode d'emploi", co-authored by Jean Oudinot and Kelly Freuler appears in the March, 1999 issue on pages 69-76 and gives a general overview of IBIS. Also, Catherine Gross authored "Les Criteres De Choix" on pages 115 and 116 and discusses simulators and modeling topics including IBIS. PROGRAM NOTES FOLLOW: CURRENT IBIS ACTIVITIES AND ISSUES - Bob Ross, Mentor Graphics Bob Ross started the main meeting by giving a brief overview of what has occurred during the last year. IBIS Version 3.2 was ratified and will be forwarded for ANSI/EIA-656A ratification. The ibischk3.2 parser is nearly completed, but still needs some refinements. IBIS Version 2.1 is moving forward, but is still pending ratification as IEC 62014-1. Bob noted that over 350 people are on the IBIS reflectors. There are 27 member companies (including Philips Semiconductor which was not listed last year), and over 70 organizations and over 170 people participated in IBIS meetings in 1998. Five face-to-face Summits were held. Bob also noted that he knew of over 30 different companies which provide web sites where IBIS models can be requested or downloaded. Other companies provide IBIS models directly. Bob added that there are some major upcoming activities. These include IBIS Version 4.0 considerations, Connector Specification activity and the IBIS User's group activity. The User's group is dealing with the Accuracy Specification and initial educational activity, and is holding regular teleconference meetings. Other activities include defining the relationship with the EIAJ IMIC activity and tracking the EMC/EMI activity in Europe. DETECTION OF TYPICAL BUGS IN IBIS MODELS - Werner Rissiek, INCASES Engineering Werner Rissiek provided an overview concerning the types of problems he has encountered with IBIS models. Some simple checks are recommended. He finds it useful to do a parser check of the model (for minor problems such as file length and name violations) and also to examine the model for "human" plausibility. Werner gave an HSTL example where the where the best termination voltage for waveform extraction (1.5 V) was not used. Rather, the supply voltage of 3.3 V was used. Werner also has seen incorrect polarity conventions for the [Pullup] table. Another plausibility check involves observing where the current passes through 0 A on the table. The cross-over point should be near a rail voltage for CMOS devices. Clamps should not be double counted in the [Pullup] and [Pulldown] tables. The dV value under [Ramp] may conflict with the I/V table data. Bob Ross noted that we do not use dV since it provides redundant information. However, inconsistent values may indicate that other problems exist in the model. Werner also discussed differential models and the fact that differential terminations are not currently used in IBIS models for waveform specification. Werner concluded that IBIS models are well-suited for SI analysis. However, manufacturers should spend more effort to make sure that the models are correct, and users should not trust the model without doing simple plausibility checks. Gerald Bannert suggested that some of the plausibility checks could be done automatically. VALIDATION OF AN ENHANCED TWO WAVEFORM BEHAVIORAL MODEL - Bernhard Unger, Siemens AG Bernhard Unger presented some results that he had presented previously at the February 1, 1999 IBIS Summit regarding two-waveform based IBIS models based on using fixture loads of 18 ohms, 50 ohms and 100 ohms. He also presented some new results showing an improved method to model Simultaneous Switching Noise (SSN). The 18 ohm fixture was selected to produce about one-half the Vcc swing. Bernhard conducted the test using the Fairchild CMOS driver VCX16244 HSPICE model supplied by Peter LaFlamme as a reference and from which the IBIS model (also supplied by Peter LaFlamme) was generated. Four driver conditions were tested: (1) a 50 ohm, 1 ns transmission line loaded with 5 pF, (2) a lumped 500 ohm parallel 30 pF load, (3) a distributed 66 ohm transmission line load, (4) and a DIMM module 66 ohm transmission line load. The simulations were conducted with and without the Vdd/Vss package model parasitics. The simulations were done using two-waveform extracted Kpur(t), Kpdr(t), Kpuf(t) and Kpdf(t) table multipliers according to the SPICE implemented algorithm cited in previous presentations. Bernhard showed a number of overlaying comparisons and concluded that the 50 ohm fixture load provided a good compromise. The 18 ohm fixture load provided better correlation for the DIMM module test case since the effective impedance seen by the buffer was about 25 ohms. When the Vdd/Vss package effects were included, the results were not as well correlated. Bernhard presented an SSN analysis setup with ground and power rail package models. The comparisons with 6 outputs switching showed deviations from the original Spice simulations. To provide more accurate results, Bernard proposed an enhanced two waveform behavioral model that contained multipliers on the pullup and pulldown current sources. Each multiplier is a function of the difference between Vdd and Vss. Each is derived using only one new "SSN Golden Waveform V/T table" for a rising and falling using a prescribed set of Vdd and Vss package pin models. Bernhard showed some improved results, and answered some questions regarding deriving the multipliers from actual switching results. Bernhard concluded with the following points: (1) Two waveform behavioral model simulations provide excellent agreement with transistor based simulations if the IBIS V/T-table loading conditions are comparable with the simulation conditions. (2) The proposed model enhancement causes an important improvement regarding SSN simulations and dependence on package parasitics. Only one additional "SSN Golden Waveform V/T-table" for each rising and falling edge and Vdd/Vss package models are necessary. (3) 50 ohm V/T-table loading conditions seem to be a good compromise for most purposes. (4) IBIS models with different R_fixture loadings are a real need if timing and noise are very critical issues. IBIS VERSION 3.2 UPDATE - Stephen Peters, Intel Stephen Peters gave an IBIS Version 3.2 update similar to the presentation at the February 1, 1999 IBIS Summit Meeting. Version 3.2 was ratified by the IBIS Open Forum at the January, 1999 teleconference meeting and will be forwarded for ANSI/EIA-656A ratification. The golden parser is uploaded (it still needs some fixes). As background, Stephen stated that IBIS Version 2.1 supported I/V tables and V/T tables. It provided initially for GTL plus technology. However, it was limited in describing passive elements, it did not provide adequate multi-stage I/O buffer models and cartridge packaging technology, and lumped L/R/C package models were a practical limitation. Stephen gave an overview and elaborated (showing related keywords) upon four areas of IBIS Version 3.2 enhancements: (1) Support for additional device types - passive (2-pin) devices, terminators, bus switches (2) Extended model specs and simulation hooks - ringback and hysteresis specs, model selectors (3) Support for advanced driver/receiver technology - multi-staged outputs, bus hold, dynamic clamps (4) Enhanced package descriptions - transmission line package stubs, .ebd files. Stephen noted that the future enhancements include uncoupled and coupled connector models. The [Add Submodel] concept can be a path for future expansion since a submodel can be used for anything. There is consideration of a possible merger or incorporation of the IMIC specification. MISCELLANEOUS AND BREAK Before the break, Bob Ross added that prior work regarding the algorithms have been presented at previous IBIS Summits and are uploaded at http://www.eda.org/pub/ibis/summits/ under the feb99, and feb98 directories. He also noted how to sign up on the IBIS reflector (noted at the end of the minutes). IBIS MANAGEMENT AND CUSTOMER'S CHECK ASPECTS - Gerald Bannert (Siemens) Gerald Bannert showed an overview of the Basic Input/Output Library (BIOLIB). Source data includes Vendor HSPICE models, Measurement modes and Vendor data sheets. In the future, IBIS models may be used as a source. A DOGEN utility (discussed in the next presentation) is used to convert the information to valid IBIS+ models. The information includes the models, the pinning, the package, and index. The DOGEN tool is also used to validate libraries based on the IBIS format and vendor specific formats. Project libraries also can be automatically created. Gerald discussed Today's IBIS model availability. About 35% of the models are not available, especially for ASICs and newer technologies. About 65% of the models are available, but these may have a number of problems, errors, and limitations which he listed. He proposed some new parameters. He noted that selecting the proper junction temperature (25 deg. C of 50 deg. C) for typical models strongly influenced the simulation results. Only about 5% of the available models satisfy their needs. Gerald presented the physical background for overshoot. He showed a number of interacting aspects, failure mechanisms and conditions related to the Dynamic_overshoot specification and parameter influence. He also illustrated some methods to establish some limits when manufacturer values were not available based on whether or not the clamping diodes existed. With no clamps, he suggested the D_overshoot values be set to 0.5 V above the rail for a duration of 3 ns, and the S_overshoot values be set at the rail voltages. With clamps, he suggested the voltages be based on a 1:2 ratio of S_overshoot to D_overshoot current limits and the D_overshoot duration be set to 5 ns. Gerald discussed further a number of physical parameter checks. Included were package parameters, power capacitance, min and max ratings beyond limits using D/S_overshoot currents, proper pullup, pulldown tables and realistic waveform table generation conditions, and frequency of operation. Furthermore, Gerald formulated how scaling factors for actual temperature, voltage and process variations might be added to relate to actual application extremes (rather than given worst case conditions). This might be considered for future IBIS and tool support. Customers will demand IBIS Models for all "new" digital ICs for year 2000. The customer will expect the information of the current IBIS specification and a model that is error free and accurate. Optional parameters are needed for some customers and tools. Some tool-specific parameters may also be needed. Siemens is developing a model specification which contain such information and requirements that is expected to be part of a semiconductor purchase contract. This specification should be available during the second quarter of 1999. DOGEN, AN INTERNAL MODEL TOOL - Hans Pichlmaier (Siemens) Hans Pichlmaier gave functional overview of the previously mentioned DOGEN utility. It converts QUAD to IBIS, IBIS to QUAD, SPICE to IBIS.ebd, and SPICE to QUAD.top. It does IBIS scaling from typ to min/max. It does syntax checks and can work with BIOLIB or as a stand-alone utility. Currently the database supports about 1200 devices for models needed in vendor specific formats. An in-house tool was needed to solve the internal model availability issue for use between different EDA tool vendors. Vendor tools have different needs, and the supplied translation tools were not adequate for automated use. Hans showed some details where using an internally standardized naming convention and parameter files, details of which could be added to QUAD formatted models to provide automatic translation into IBIS models. Ramp conversion is done by actual simulation. Hans also showed an example of SPICE netlist to .ebd conversion under development. Part numbers and component pins are defined in a parameter file. Hans illustrated scaling of I/V and V/T data to provide min and max tables from typ tables. A parameter file defines several factors for independent min and max scaling. Hans showed the extensive DOGEN checking functionality. It automatically does checks based on 60 criteria on old Quad models, IBIS model and from models generated in the tool library in support of several simulator specific formats. Sixteen checks are devoted to testing naming compatibility between pin, model and package names. [Pin], [Diff Pin] and other blocks are checked for multiple and unused names in compliance with the in-house naming conventions. A number of common data checks include testing for monotonic data, testing typ is between min and max, checking that all columns contain numerical data without NA entries, and checking that all necessary data is defined. Twenty special data checks are done on such parameters as D_overshoot > S_overshoot > Vcc (or Vinh for LVDS and ECL), range of D_overshoot time, value of the clamp current at the D_overshoot values, etc. Hans presented some future plans. These include support of IBIS Version 3.0 [Driver Schedule], series models and [Series MOSFET], [Model Selector] keywords. An old internal LDRC data base will be transformed to an internal "IBIS+" format. He may also enhance the conversion from SPICE to IBIS+. He also added TOPSPEC to EBD conversions. In response to questions Hans noted that different simulators may or may not have some name length restrictions, but all are beyond the limits set within the IBIS format. These are checked. GENERATION OF IBIS MODELS AT STMICROELECTRONICS - Fabrice Boissieres (STMicroelectronics) Fabrice Boissieres shared his work for automatic IBIS model generation for ASICs. The process is based on a s2ibis adaptation with ELDO models. It integrates the ASIC models with package model information. His goals is to integrate IBIS ASIC models to the application design and also to generate IO libraries for several CMOS processes. Fabrice presented the flow. Included is an IbisGeneration.pl script for configuring s2ibis for the particular IOcell characteristics, and an LSF utility for distributing the computing over several machines. A CheckAndCorrect.pl script checks the results for a non-monotonic behavior and wrong values; graphically displays the corrected versus original model; performs the ibischk3 syntax check. The result is entered into the IOcell_final.ibs library. An ICPack utility is used to integrate IBIS ASIC models. It uses the IBIS IO Library and the ICPack IO library along with connectivity information and package models to produce IBIS ASIC models. Currently the package models are in two families that are linked to the application accuracy requirements. When lead length is important compared to wire length, estimated R,L,C parameters are used. When wire length is not negligible, mutual inductance is taken into account by simulation. Fabrice outlined his current and future work. Current work includes checking the process with different test cases. Future work includes more validation by checking the models against silicon measurements and under different simulation environments. IBIS FUTURE REQUIREMENTS - Stephen Peters, Intel Stephen Peters gave an IBIS future requirements presentation similar to the one presented at the February 1, 1999 IBIS Summit meeting. Stephen noted IBIS handles several things well. It handles CMOS/TTL/ECL technology and controlled rise time parts such as GTL. Bus hold is now available. The EBD and enhanced packages allow more complex paths - as long as coupling is not required. However, what is lacking is multiple buffer switching effects taking into account SSO effects due to pin to pin coupling and power/ground rail bounce. A lossy transmission line is needed. Perhaps it is time for the G matrix and/or a frequency dependent loss for .ebd and .pkg files. Non-ideal ground return paths need to be modeled in the next generation of simulators. Stephen continued that the solution to these are important because of very fast processor buses and source synchronous signaling. The timing budgets are tight and the second order effects are now dominant. [Pin Mapping] is a start, but is not complete. It does not include model on-die capacitance. Pin to pin coupling is almost there, but needs improvement. Perhaps a champion is needed to make use of the connector model information that is is being considered. Stephen stated that the key to SSO modeling is to make the buffer power and ground nodes available. IMIC is interesting, but does not use the standard I/V and V/T description of the buffer. Stephen also noted that the [Add Submodel] keyword has expansion possibilities for a model consisting of a group of buffers and for embedding package descriptions. FUTURE REQUIREMENTS ON FREQUENCY DEPENDENT PACKAGE AND MCM MODELING - Werner Rissiek (INCASES Engineering) Werner Rissiek presented some research work funded by BMBF showing that it will be necessary to consider the frequency dependent behavior of MCM and package interconnect structures in the future. The requirements are to limit the complexity of time domain simulation while still providing reasonable accuracy. Werner showed a typical MCM structure and then showed some lumped element approximations with and without skin effect. He showed good comparisons between scattering parameter S11 and S21 terms between simulation using the lumped elements and measurement. In fact the measurements are suspicious at the higher frequencies for the S21 comparisons. In addition, Werner proposed a 4 X 4 system of frequency dependent transmission lines to consider coupling effects. The complexity is limited to allow efficient parameter extraction and simulations. Werner concludes that (1) Lumped element descriptions are sufficient for frequency dependent modeling of single signal paths on MCM and packages. (2) Currently IBIS is supporting only limited structures to support this kind of modeling. (3) The IBIS format has to become flexible to support various types of lumped element models efficiently. (4) Frequency dependent transmission line parameters will become important for modeling of signal paths including coupling in the future. CONCLUSION Bob Ross closed the meeting by again thanking the meeting sponsors, Karine Loudet, and the presenters for their outstanding presentations. Werner Rissiek reminded people of the DATE99 conference and the PCB Symposium. Bob stated that we should look forward to another IBIS Summit meeting next year in Paris associated with DATE2000. NEXT MEETING: The next teleconference meeting will be on Friday, March 26, 1999 from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, 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. ============================================================================== From owner-ibis Fri Mar 19 10:50:41 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA20580 for ; Fri, 19 Mar 1999 10:50:40 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA02985; Fri, 19 Mar 1999 10:44:47 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA19029; Fri, 19 Mar 1999 10:44:46 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA17388; Fri, 19 Mar 99 10:44:46 PST Date: Fri, 19 Mar 99 10:44:46 PST Message-Id: <9903191844.AA17388@bob> To: ibis@eda.org Subject: IBIS Meeting 3/26/99 Cc: bob_ross@mentorg.com IBIS Open Forum Meeting Agenda for 3/26/99 Bridge Number Reservation # Passcode (916) 356-9200 2-306362 7132187 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Rusher - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions - IEEE P1537 Data Format Project Peters IBIS (East) Users Group Meetings Edlund/Haller DATE99 March 9, 1998 IBIS Summit Meeting Feedback Ross IBIS Version 3.2 Ross/Rusher - EIA Standard Preparations IBISCHK3 Version 3.2.2/3.2.3/3.2.4 Ross/Flora/Rokusek - Source, Executables Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:00 Technical Discussion BUG34 - No Error Reported for Missing V/I Tables in Flora Output Buffers BIRD58 - Driver Schedule Keyword Clarification Muranyi Connector Proposal Review Flora/Crisafulli Accuracy Specification Review Edlund/Haller New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Mon Mar 22 16:22:04 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA29449 for ; Mon, 22 Mar 1999 16:22:03 -0800 (PST) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id TAA32310 for ; Mon, 22 Mar 1999 19:15:58 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id TAA99020 for ; Mon, 22 Mar 1999 19:16:07 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 8525673D.0001788B ; Mon, 22 Mar 1999 19:16:03 -0500 X-Lotus-FromDomain: IBMUS To: ibis@eda.org Message-ID: <8525673D.0001776A.00@d54mta04.raleigh.ibm.com> Date: Mon, 22 Mar 1999 19:14:20 -0500 Subject: IBIS 101: RREF & VREF Keywords Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello all. As an IBIS user, and model librarian, I am seeing a growing problem with basic IBIS understanding. I do know that there are people currently working on creating tutorials and other education for IBIS developers; however, I think we need to clarify the IBIS spec as well for the subject keywords. Here is the problem I'm seeing: Vendors are not sure when to use RREF and VREF. VMEAS and CREF seem to be understood. My understanding is that for open-drain (open-sink) devices, VREF should be set to VCC, and RREF should be set to a value that pulls the voltage up near VCC for the rising time-to-Vmeas and will allow the device to pull the voltage back down to near zero for the falling time-to-Vmeas. VREF should be set to Ground for open-source devices, and RREF should be set to a value that allows the device to pull the voltage up near VCC for the rising time-to-Vmeas and pulls the value down towards ground for the falling time-to-Vmeas. HOWEVER, I am seeing vendors put VREF to obscure values. Sometimes they are set to zero for open-drain devices (hence, the time-to-Vmeas cannot be calculated since the device never gets to Vmeas). Sometimes they put VREF to equal VMEAS; this really causes the various tools to calculate interesting time-to-Vmeas values. Sometimes, I have no idea what the value of VREF really means. I am also seeing vendors use the RREF and VREF on normal totem-pole/push-pull devices; this also causes interesting results in the calculation of the time-to-Vmeas. Should RREF and VREF really be used on these devices? I have reviewed the IBIS Spec (Version 3.2) and the IBIS Cookbook, and there is no clear answer as to when these keywords should be used, and when they should not be used. Should we create a BIRD to clarify the use of these keywords? Also, if my understanding is correct, should we also create a BIRD to add an additional keyword to the "[Model Spec]" keyword: "Vref", such as the "Vmeas" that currently exists in the "[Model Spec]"? If VREF should be set to VCC, then there are MIN, MAX, and TYP values for VREF, not just one TYP value. Bob Ross, can we discuss this issue at the next Open Forum this Friday? Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 From owner-ibis Mon Mar 22 17:02:43 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA29532 for ; Mon, 22 Mar 1999 17:02:39 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA28633; Mon, 22 Mar 1999 16:56:42 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA01305; Mon, 22 Mar 1999 16:56:40 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA26827; Mon, 22 Mar 99 16:56:41 PST Date: Mon, 22 Mar 99 16:56:41 PST Message-Id: <9903230056.AA26827@bob> To: ibis@eda.org, micohen@us.ibm.com Subject: Re: IBIS 101: RREF & VREF Keywords Michael: We will put this topic on the agenda. Bob Ross Mentor Graphics > From: micohen@us.ibm.com > To: ibis@eda.org > Message-ID: <8525673D.0001776A.00@d54mta04.raleigh.ibm.com> > Date: Mon, 22 Mar 1999 19:14:20 -0500 > Subject: IBIS 101: RREF & VREF Keywords > Hello all. > As an IBIS user, and model librarian, I am seeing a growing problem with > basic IBIS understanding. I do know that there are people currently > working on creating tutorials and other education for IBIS developers; > however, I think we need to clarify the IBIS spec as well for the subject > keywords. > Here is the problem I'm seeing: > Vendors are not sure when to use RREF and VREF. VMEAS and CREF seem to be > understood. My understanding is that for open-drain (open-sink) devices, > VREF should be set to VCC, and RREF should be set to a value that pulls the > voltage up near VCC for the rising time-to-Vmeas and will allow the device > to pull the voltage back down to near zero for the falling time-to-Vmeas. > VREF should be set to Ground for open-source devices, and RREF should be > set to a value that allows the device to pull the voltage up near VCC for > the rising time-to-Vmeas and pulls the value down towards ground for the > falling time-to-Vmeas. > HOWEVER, I am seeing vendors put VREF to obscure values. Sometimes they are > set to zero for open-drain devices (hence, the time-to-Vmeas cannot be > calculated since the device never gets to Vmeas). Sometimes they put VREF > to equal VMEAS; this really causes the various tools to calculate > interesting time-to-Vmeas values. Sometimes, I have no idea what the value > of VREF really means. > I am also seeing vendors use the RREF and VREF on normal > totem-pole/push-pull devices; this also causes interesting results in the > calculation of the time-to-Vmeas. Should RREF and VREF really be used on > these devices? > I have reviewed the IBIS Spec (Version 3.2) and the IBIS Cookbook, and > there is no clear answer as to when these keywords should be used, and when > they should not be used. Should we create a BIRD to clarify the use of > these keywords? Also, if my understanding is correct, should we also > create a BIRD to add an additional keyword to the "[Model Spec]" keyword: > "Vref", such as the "Vmeas" that currently exists in the "[Model Spec]"? > If VREF should be set to VCC, then there are MIN, MAX, and TYP values for > VREF, not just one TYP value. > Bob Ross, can we discuss this issue at the next Open Forum this Friday? > Regards, > Michael Cohen > IBM Personal Systems Group > Design Tools Department > D-26D/B-201/R-D104H > 3039 Cornwallis Road > Research Triangle Park, NC 27709 > Phone: 919-543-4042 (T/L 441-4042) > FAX: 919-543-8221 (T/L 441-8221) > Internet Address: micohen@us.ibm.com > IBM Internal Addresses: > From Lotus Notes (#1): Michael Cohen/Raleigh/IBM > From Lotus Notes (#2): micohen@ibmus > From VM: micohen@ibmusm21 From owner-ibis Wed Mar 24 11:34:41 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA06503 for ; Wed, 24 Mar 1999 11:34:39 -0800 (PST) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id LAA04437; Wed, 24 Mar 1999 11:32:59 -0800 Message-Id: <3.0.5.32.19990324112911.00aa6280@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 11:29:11 -0100 To: "Muranyi, Arpad" From: Matthew Flora Subject: Re: BIRD 58 Cc: ibis@eda.org In-Reply-To: <199903022127.VAA29901@thalia.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Arpad, Since you are submitting BIRD 58 as a clarification to the [Driver Schedule] keyword, I was wondering if you could add to the BIRD. From the spec/BIRD: "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." 1) In the above excerpt, it says "The [Model] keyword provides the specification information, ...". Should that instead say "The top-level model provides the specification information, ..."? 2) The excerpt above does not explicitly say which [Voltage Range] and/or [Pullup Reference], [Pulldown Reference] is to be used. My interpretation is that the referenced models use the voltage range/references from the top-level model. Perhaps someone else would interpret it differently. I'd like the spec to explicitly say which voltage range/references are to be used with the [Pulldown] and [Pullup] tables taken from the referenced models. From the spec/BIRD: "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." 3) In the above excerpt, it says "... table be supplied under the [Model] keyword to serve as a reference for validation.". Should that instead say "... table be supplied within the top-level model to serve as a reference for validation."? From the spec/BIRD: "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." I'm sorry, but I find this whole section confusing. 4) It appears that the intent of the keyword is to allow the drive strength of an output buffer to be increased or decreased by adding in (and/or taking out) various tables from other models at strategic times during the transitioning of the buffer's output. Is this intent stated in the spec? 5) The above excerpt refers to transitions and a rising cycle. When is the text referring to the transition (cycle) of the output of the buffer as a whole versus the transition (cycle) of the added "boost" model? 6) If the Rise_on_dly and Rise_off_dly specify the start of the added "boost" model's rising edge and falling edge, respectively, then the example shows "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during the rising transition of the output buffer. Yet the excerpt above says "For each model, the transition sequence must be complete, i.e., it must start and end at the same state." This strikes me as a contradiction. 7) Must at least one of the delay times be specified or can all four be NA? I also noticed some typos in the spec/BIRD: 1) In one place the spec refers to "Falling_off_dly" instead of "Fall_off_dly". 2) "... other models that exists in the .ibs file." The "exists" should be "exist". Now I realize that I may have a misunderstanding of the intent and/or the workings of the [Driver Schedule] keyword. If I do, then I would suggest that the definition of the keyword is not clear enough. Regards, Matthew Flora IBIS Open Forum Secretary (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Wed Mar 24 14:42:14 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA06992 for ; Wed, 24 Mar 1999 14:42:13 -0800 (PST) Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id WAA15725 for ; Wed, 24 Mar 1999 22:36:48 GMT Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 24 Mar 1999 14:36:48 -0800 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0AD4@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: BIRD 58 Date: Wed, 24 Mar 1999 14:36:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Matt, Thanks for your comments. I agree with your observations on the first glance, but I need a little more time to read them and think about each detail. However, as a quick response I want to say that the BIRD turned out the way it did because I was trying to keep the changes to a minimum. So I didn't change any of the existing text, and I only massaged the first sentence in the added section that was copied from BIRD35.3 so that it makes more sense in the context. We should discuss this in our next teleconference. Arpad ============================================================================ ==== -----Original Message----- From: Matthew Flora [mailto:mbflora@hyperlynx.com] Sent: Wednesday, March 24, 1999 4:29 AM To: Muranyi, Arpad Cc: ibis@eda.org Subject: Re: BIRD 58 Arpad, Since you are submitting BIRD 58 as a clarification to the [Driver Schedule] keyword, I was wondering if you could add to the BIRD. From the spec/BIRD: "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." 1) In the above excerpt, it says "The [Model] keyword provides the specification information, ...". Should that instead say "The top-level model provides the specification information, ..."? 2) The excerpt above does not explicitly say which [Voltage Range] and/or [Pullup Reference], [Pulldown Reference] is to be used. My interpretation is that the referenced models use the voltage range/references from the top-level model. Perhaps someone else would interpret it differently. I'd like the spec to explicitly say which voltage range/references are to be used with the [Pulldown] and [Pullup] tables taken from the referenced models. From the spec/BIRD: "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." 3) In the above excerpt, it says "... table be supplied under the [Model] keyword to serve as a reference for validation.". Should that instead say "... table be supplied within the top-level model to serve as a reference for validation."? From the spec/BIRD: "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." I'm sorry, but I find this whole section confusing. 4) It appears that the intent of the keyword is to allow the drive strength of an output buffer to be increased or decreased by adding in (and/or taking out) various tables from other models at strategic times during the transitioning of the buffer's output. Is this intent stated in the spec? 5) The above excerpt refers to transitions and a rising cycle. When is the text referring to the transition (cycle) of the output of the buffer as a whole versus the transition (cycle) of the added "boost" model? 6) If the Rise_on_dly and Rise_off_dly specify the start of the added "boost" model's rising edge and falling edge, respectively, then the example shows "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during the rising transition of the output buffer. Yet the excerpt above says "For each model, the transition sequence must be complete, i.e., it must start and end at the same state." This strikes me as a contradiction. 7) Must at least one of the delay times be specified or can all four be NA? I also noticed some typos in the spec/BIRD: 1) In one place the spec refers to "Falling_off_dly" instead of "Fall_off_dly". 2) "... other models that exists in the .ibs file." The "exists" should be "exist". Now I realize that I may have a misunderstanding of the intent and/or the workings of the [Driver Schedule] keyword. If I do, then I would suggest that the definition of the keyword is not clear enough. Regards, Matthew Flora IBIS Open Forum Secretary (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Fri Mar 26 15:17:12 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA16322 for ; Fri, 26 Mar 1999 15:17:12 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA07732 for ; Fri, 26 Mar 1999 18:10:31 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA14044 for ; Fri, 26 Mar 1999 18:11:14 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256740.007F5C7B ; Fri, 26 Mar 1999 18:11:07 -0500 X-Lotus-FromDomain: IBMUS To: ibis@vhdl.org Message-ID: <85256740.007F574D.00@D51MTA10.pok.ibm.com> Date: Fri, 26 Mar 1999 17:10:50 -0600 Subject: BIRD58 discussion continued Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IBIS Folks, A thought occurred to me during today's BIRD58 discussion during the Open Forum call. What happens when a user gets an IBIS datasheet for a multi-stage driver but isn't aware that the simulator does not use the related keywords? The user may get bogus simulation results and not know it until he or she has failing hardware on the test floor. Now, you can say that the user should be better educated, and that's true. Education is an across-the-board problem for users and modeling engineers. However, we might be allowing an opening for IBIS to get a black eye by allowing for top-level data to exist under the model statement for a multi-stage driver . If the data is there, it may be used. I think I understand the simulator argument; simulator vendors that don't support multi-staged drivers don't want to hurt their sales, right? But unless you pop up a window that tells the user, "You're about to use an IBIS datasheet for a multi-stage driver and we don't support this," the user may unwittingly be taking on a very big risk. It just seems to me that the most responsible thing to do is to make IBIS itself idiot-proof in this respect by not allowing IV curves in the top-level model. VT tables are great; they can be used for correlation. I'm sure this issue was discussed prior to my involvement, so I apologize if I'm trying to resurrect something that was already settled. I'm not sure I totally understand the ramifications of what I'm saying here, but I suspect it might mean holding up IBIS 3.2 and the parser if we actually did what I'm suggesting? In that case, I'm sure this won't be a very popular posting :-( Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Mon Mar 29 17:57:21 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA24999 for ; Mon, 29 Mar 1999 17:57:21 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA16611; Mon, 29 Mar 1999 17:50:54 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA29259; Mon, 29 Mar 1999 17:50:53 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <37002DFD.54885644@mentor.com> Date: Mon, 29 Mar 1999 17:50:53 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org, stevek@hyperlynx.com CC: bob_ross@mentorg.com Subject: driver schedule clarifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve: You asked some good questions and I am responding to the ibis reflector per our discussion. These were discussed at the February IBIS Open Forum meeting. My responses are in your text IN UPPERCASE. Bob Ross Mentor Graphics Date: Thu, 25 Mar 1999 15:59:49 -0800 To: arpad.muranyi@intel.com, bob_ross, mbflora@hyperlynx.com From: Steve Kaufer Subject: driver schedule clarifications Cc: dc.sessions@tempe.vlsi.com Hi Everyone, Here's a summary of the issues relative to [Driver Schedule] that HyperLynx is looking for clarification on in tomorrow's meeting. Matt Flora will be attending for us (and basically listening for the answers). For issues #1 and #2, I've listed the cases that I've heard argued in favor of. I've used the (probably bad) term "sub-model" to refer to models that are not at the top level but are added by / referred to in the [Driver Schedule] table. ***1) If [Driver Schedule] is used, is a top-level model required? If so, how is it used? Case #1: Yes, a top-level model is required, but it represents a "combined" model that only approximates the behavior of the set of models used by [Driver Schedule]. If the target simulator supports [Driver Schedule], the top-level model is not used; all of the models in the [Driver Schedule] table are "sub-models." If the simulator does NOT support [Driver Schedule], it may use the top-level model as an approximate fallback. THIS IS THE CORRECT ANSWER. A SIMULATOR THAT DOES NOT SUPPORT [DRIVER SCHEDULE] WILL PROBABLY REPORT A SYNTAX ERROR. THE USER CAN THEN DELETE THE [DRIVER SCHEDULE] KEYWORD AND RELATED LINES AND GET AN "APPROXIMATE RESPONSE". Case #2: Yes, a top-level model is required. It is the "t=0ns" or first-switching model for each transition. Later-switching models in the table are "sub-models." NOT THE CORRECT INTERPRETATION Case #3: No top-level model is required. I.e., the I-V tables that would normally appear at the top level may be omitted entirely in favor of data contained only in "sub-models." A TOP-LEVEL MODEL IS REQUIRED ***2) Do models that are turned on in one transition carry over, still turned on, into the opposite transition? Consider the following example; assume a rising transition at t=0ns and a falling transition at t=10ns: > | Model_Name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly > | > stage1 0.0ns NA 0.0ns NA > stage2 1.0ns NA 4.0ns NA > stage3 2.0ns NA 8.0ns NA Case #1: No, there is no carry-over. If there was, sourcing and sinking buffers would be "fighting" each other. So the following events occur: time event ----------------- 0ns stage1 turns on high 1ns stage2 turns on high 2ns stage3 turns on high 10ns falling edge begins; all high stages turn off and stage1 turns on low 14ns stage 2 turns on low 18ns stage 3 turns on low INCORRECT Case #2: Yes, there is carry-over. The following events occur: time event ----------------- 0ns stage1 turns on high 1ns stage2 turns on high 2ns stage3 turns on high 10ns stage1 turns on low; stage2 and stage3 stay on high 14ns stage 2 turns on low 18ns stage 3 turns on low CORRECT INTERPRETATION. THE WAY TO LOOK AT THIS IS TO THINK OF A MASTER "CLOCK" WITH A RISING EDGE AND A FALLING EDGE. THE RISE_ON_DLY AND RISE_OFF_DLY ARE RELATIVE TO THE RISING EDGE. THE FALL_ON_DLY AND FALL_OFF_DLY ARE RELATIVE TO THE FALLING EDGE. ***3) Miscellaneous wording changes and clarifications proposed by Matt Flora. On question ***1, HyperLynx doesn't care what the answer is. Having a "fallback" top-level model sounds nice, but I suspect semiconductor modeling folks won't want to create it and that it won't be accurate enough for real use. YOU MAY BE CORRECT. THIS IS REALLY A STUB. On question ***2, the Case#1 interpretation is simpler, and so we'd prefer it if all else was equal. But the question should really be answered by the semiconductor people who know what kinds of buffers are actually being built. One vendor creating multi-stage output cells told me that theirs matches Case#1. If Case#2 is the true intent, then how would an output cell that behaved like Case#1 be represented? YOU WOULD USE "0" FOR THE FALL_OFF_DLY ENTRIES. Regards, Steve Kaufer, HyperLynx 17641 N.E. 67th Court Redmond, WA 98052 tel: 425-869-2320 fax: 425-881-1008 e-mail: stevek@hyperlynx.com From owner-ibis Mon Mar 29 18:11:05 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA25029; Mon, 29 Mar 1999 18:11:05 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA17171; Mon, 29 Mar 1999 18:05:09 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA00653; Mon, 29 Mar 1999 18:05:08 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <37003154.9105651B@mentor.com> Date: Mon, 29 Mar 1999 18:05:08 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mike LaBonte , ibis@eda.org, ibis-users@eda.org Subject: Re: BIRD 58 References: <199903022127.VAA29901@thalia.fm.intel.com> <36FBDBB6.C19AD0D1@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike: Thank you for your input. You have some valid points regarding allowing C_comp to be distributed. This will work for creating driver models as the summation of individual drivers. The problem is that if the top-level model is an I/O model, we would normally not put in a C_comp value = 0. Then in the Input mode, we would have to add up all of the C_comps in the lower level models to come up with the effective C_comp. This is a possible workable solution that does not require any Specification syntax change - just a few more words of interpretation. It would also support moving all of the C_comp to the top-level for another method of building a behavioral buffer by construction. We will have to consider this. Bob Ross Mentor Graphics Subject: Re: BIRD 58 Date: Fri, 26 Mar 1999 14:10:46 -0500 From: Mike LaBonte To: ibis-users@vhdl.org Regarding the c_comp issue discussed in the Mar 26 IBIS meeting, related to BIRD 58, I would like to register my opinion in favor of allowing for the use of separate c_comp values attributed to each Driver Schedule stage. Although c_comp may be named as such because of the original intention that it encapsulate an overall component level capacitance, the practical matter is that Driver Schedule stages are most likely to correspond to actual transistors in an IO section. Each transistor does have it's own effective die capacitance. The designer of the stage buffers may (should) have validated their behavior individually, with c_comp intact. To then use them in a scenario where the c_comp values are not used may not make sense. (insert discussion of the aggregate capacitance for a cluster of transistors vs. sum of individually calculated capacitances here). Furthermore, IBIS could gain maximum flexibility by stating that the c_comp values of individual stages are used in addition to the c_comp that might be specified for the top-level model. In this way, model designers can specify c_comp=0 for any portion that is not to be used. This part of the proposal is debatable in my own mind, simply because I have some difficulty producing an elegant explanation of what the top-level capacitance represents, when the`"transistor" capacitance is already accounted for. But it offers flexibility. And it eliminates the requirement that simulators ignore c_comp data present in the Model, which users may not be aware of. Mike LaBonte From owner-ibis Mon Mar 29 18:19:57 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA25057 for ; Mon, 29 Mar 1999 18:19:57 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA17503; Mon, 29 Mar 1999 18:14:01 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA01434; Mon, 29 Mar 1999 18:14:00 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <37003368.9621C72D@mentor.com> Date: Mon, 29 Mar 1999 18:14:00 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: gedlund@us.ibm.com, ibis@eda.org Subject: Re: BIRD58 discussion continued References: <85256740.007F574D.00@D51MTA10.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg: You raise several good points. My response is in upper case in your text. Thank you for your input. Bob Ross Mentor Graphics Subject: BIRD58 discussion continued Date: Fri, 26 Mar 1999 17:10:50 -0600 From: gedlund@us.ibm.com To: ibis@vhdl.org IBIS Folks, A thought occurred to me during today's BIRD58 discussion during the Open Forum call. What happens when a user gets an IBIS datasheet for a multi-stage driver but isn't aware that the simulator does not use the related keywords? THE SIMULATOR WILL PROBABLY REPORT AN ERROR. SO THE USER MUST CHANGE THE MODEL. THE USER THEN SHOULD BE AWARE THAT THE RESPONSE IS JUST AN APPROXIMATION. The user may get bogus simulation results and not know it until he or she has failing hardware on the test floor. Now, you can say that the user should be better educated, and that's true. Education is an across-the-board problem for users and modeling engineers. However, we might be allowing an opening for IBIS to get a black eye by allowing for top-level data to exist under the model statement for a multi-stage driver . If the data is there, it may be used. I think I understand the simulator argument; simulator vendors that don't support multi-staged drivers don't want to hurt their sales, right? But unless you pop up a window that tells the user, "You're about to use an IBIS datasheet for a multi-stage driver and we don't support this," the user may unwittingly be taking on a very big risk. It just seems to me that the most responsible thing to do is to make IBIS itself idiot-proof in this respect by not allowing IV curves in the top-level model. VT tables are great; they can be used for correlation. YOU MAY BE CORRECT. HOWEVER, WE MAY NEED THE IV TABLES TO PRODUCE THE CORRELATION RESPONSE INTO THE GIVEN TEST LOAD. I'm sure this issue was discussed prior to my involvement, so I apologize if I'm trying to resurrect something that was already settled. I'm not sure I totally understand the ramifications of what I'm saying here, but I suspect it might mean holding up IBIS 3.2 and the parser if we actually did what I'm suggesting? In that case, I'm sure this won't be a very popular posting :-( WHAT YOU ARE STATING WOULD CHANGE VERSION 3.2 AND ALSO THE PARSER. IT WOULD ALSO IMPACT SOME EXISTING IBIS MODELS. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Tue Mar 30 17:14:14 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA00899 for ; Tue, 30 Mar 1999 17:14:13 -0800 (PST) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA06629 for ; Tue, 30 Mar 1999 17:08:46 -0800 (PST) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Mar 1999 17:08:45 -0800 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0AF6@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis@eda.org Subject: BIRD58 discussion Date: Tue, 30 Mar 1999 17:08:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" To all involved in this conversation, This is in response to the comments posted in connection with BIRD58 by Steve, Matt (Hyperlinx) Mike (Cadence) and Greg (IBM). Hopefully BIRD58.1 will follow shortly. I am not going to address some of the simpler issues which deal with spelling and simple English clarity. I will come up with something for those in the next revision of the BIRD. Also, I don't understand Matt's question, quote: "The above excerpt refers to transitions and a rising cycle. When is the text referring to the transition (cycle) of the output of the buffer as a whole versus the transition (cycle) of the added "boost" model?" so I am not going to address it now. Matt, could you please explain to me what you meant? Problem #1 (these are my numbers now) ========== The major issue seems to revolve around where things go between the top level and the scheduled models. The following section quoted from the spec (unchanged in BIRD58) makes a clear statement that the only things that are used from the scheduled models are the pd and pu I-V curves (not including the clamp I-V curves) and the V-t curves along with the Ramp information. According to the last sentence, it is not illegal to define the specification information, clamp I-V curves and C-comp in the scheduled model(s). However, to me this says that if they are there, they should be ignored, because this information is "provided" by the [Model] keyword (meaning the top-level model). | 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. I hate to say this, but according to this, if we want to allow the scheduled models to carry "usable" information other than the pd, pu I-V curves, V-t curves and Ramp information is a spec change. Of course it is a different question what the tools actually do with the data that is not supposed to be there. If they use it, they actually violate the spec, in my opinion. On the other hand, Greg has a good point about the user of the model getting confused and possibly expecting different results not knowing what is used or not. But why should we allow redundant data if it is not supposed to be used (according to the paragraph above)? This relates to some other issues to which I will return below. Problem #2 ========== Matt brought up that the above section does not include the voltage range, and reference voltages, and asks where those should be placed. In my opinion they are all mentioned in the above section if we look at the meaning of the words "specification information" carefully. This is arguable, but to me the comma after the word "information" is an indication for a list, which means that the words "specification information" do not refer to the following items in the sentence ([GND Clamp] and [POWER Clamp], and C_comp), but to all other IBIS parameters and subparameters not listed here. According to this argument everything goes, including voltage range, reference voltages, Vinh, Vinl, Vref, Cref, etc. And using the previous argument, these should all be in the top-level model, or else they must be ignored. And please don't call me a lawyer, some times we just have to look at the words the way they are written :-) On the other hand, if the comma in the above sentence was intended to mean "i.e.", the previous argument is invalid, and the remaining keywords should all be listed in this section one by one with appropriate explanations on where they should be placed. Problem #3 ========== Matt raised the following question: "It appears that the intent of the keyword is to allow the drive strength of an output buffer to be increased or decreased by adding in (and/or taking out) various tables from other models at strategic times during the transitioning of the buffer's output. Is this intent stated in the spec?" The answer is in the spec/BIRD58: | 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. | Problem #4 ========== Steve asked the following question: "Do models that are turned on in one transition carry over, still turned on, into the opposite transition?" with examples to illustrate the issue. I discussed this with Bob at length and I concluded the following. I feel that the meaning of the delay parameters may not be clear to most readers (which included myself). Think of an open sink buffer for the next four points. This buffer has a pulldown driver only, which is basically a GTL type buffer. Let's assume that the model uses the [Driver Schedule] keyword. The meaning of the delay parameters then is as follows: a) Fall_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device. This is the normal way to turn on a driving device. b) Fall_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. This can turn off a driving device before the next edge occurs. c) Rise_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. This turns the driving device off on the subsequent edge, and is the normal way of turning it off. d) Rise_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device. In my opinion this case is purely theoretical and impractical. The point I am trying to make here is that the pulldown can be turned on/off by either one of the two internal pulses, and this is defined through the particular delay variable used. An equivalent truth table can be made for a pullup device. For a complementary driver (which is a combination of both pullup and pulldown devices) the truth table for these parameters is as follows: a) Fall_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device and turns OFF the I-V curve of the pullup device if it was not turned off by the Rise_off_dly parameter yet. This is the normal way of doing a high to low transition. b) Fall_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. Theoretically, this parameter could also be used to turn on the pullup device from the falling internal pulse, but it is highly unlikely that it would be done in practice. c) Rise_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pullup device and turns OFF the I-V curve of the pulldown device if it was not turned off by the Fall_off_dly parameter yet. This is the normal way of doing a low to high transition. d) Rise_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pullup device. Theoretically, this parameter could also be used to turn on the pulldown device from the rising internal pulse, but it is highly unlikely that it would be done in practice. (I hope I got it right...) Note that even though these parameters use the words "on" and "off", they don't always refer to the devices being turned on and/or off. This may partially be the reason for much of the confusion. So given all this, if we are modeling a complementary buffer, which has only on-delays (rise_on_dly and Fall_on_dly) specified in its model, the previous state must be extended to the time when the new transition begins. This may result in a situation in which a buffer with more than one stages will have crowbar currents between one or more of its delayed and/or non delayed stages. Notice that there is one special case that seems impossible with the above tables. Here is a falling edge example to illustrate that: The pullup of a complementary buffer is turned off by the falling edge without delay but the pulldown is turned on with a delay by the same edge. This combination can still be modeled by separating the pullup and pulldown halves of the buffer into two open_??? models. Problem #5 ========== Quote from Matt: "If the Rise_on_dly and Rise_off_dly specify the start of the added "boost" model's rising edge and falling edge, respectively, then the example shows "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during the rising transition of the output buffer. Yet the excerpt above says "For each model, the transition sequence must be complete, i.e., it must start and end at the same state." This strikes me as a contradiction." Keeping in mind the reasoning from the previous point, this is not a contradiction. Note that the examples mentioned in this quote use two "ON" delays. However, note that one of the "ON" delay actually turns the device off. So these examples correctly show that the scheduled device started and ended in the same state (OFF). Problem #6 ========== Quote from Matt: "Must at least one of the delay times be specified or can all four be NA?" Given the example in the previous problem and the requirement that the model starts and finished in the same state, one may quickly realize that only five combination of the delay parameters are valid. One of the invalid combinations is the four NAs. Problem #7 ========== I would like to revisit the issue of C_comp. First of all, my statement in the last teleconference was not entirely correct, which will become apparent from the following thoughts. In the meeting I suggested that having one C_comp in the top-level model may cause less accurate simulation results, because the simulator has to compensate for the effects of C_comp in the V-t curves. My reason was that the independent V-t curves in the models of the separate stages requires that we know what C_comp is for each of those stages, and a combined value in the top-level model is not sufficient. Mike basically seconded this idea in his EMAIL response. After thinking about this some more I realized that this is only true if the models of each stage were generated independently, that is completely separated from each other in the netlist. However, one can also make a model for each stage by just disabling the stages that are not needed for the model of the particular stage being modeled. If models are generated with this method, the capacitance of the disabled stages will still load the V-t curve of the one stage that is being modeled, therefore a combined C_comp is what should be used in the simulators for compensating the V-t curves. This would suggest that the proper place for C_comp is in the top level model. So this really boils down to what technique is used during the generation of the V-t curve data. Given the argument in the first point, it may make sense to keep C_comp in the top level only, and instruct the model maker that the V-t curves of the stages should always be generated by keeping the whole buffer in the netlist, only disabling the unwanted sections using the controls of their prediver circuit. Another reason to keep all of the "remaining parameters" in the top level model is that the staged models are really used only for describing the driver, hence the name [Driver Schedule]. The information that is used for receiver mode operation are supposedly all in the top-level model (if we agree with what I wrote above). Summary ======= The situation is not as bad as I thought before. With a few clarifications and/or rewording I believe that the existing spec is good and useful without any functional changes. I am sorry that this turned out this long, but this is a fairly complicated problem. I am eager to hear your comments. Sincerely, Arpad Muranyi Intel Corporation ==================================================================== From owner-ibis Wed Mar 31 11:23:37 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA05551 for ; Wed, 31 Mar 1999 11:23:32 -0800 (PST) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id LAA27587 for ; Wed, 31 Mar 1999 11:23:03 -0800 Message-Id: <3.0.5.32.19990331111800.009899e0@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 31 Mar 1999 11:18:00 -0100 To: ibis@eda.org From: Matthew Flora Subject: IBIS Open Forum Minutes 26 Mar 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 3/31/99 SUBJECT: 3/26/99 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram, Norio Matsui, Neven Orhanovic* Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq Compaq Bob Haller, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor Peter LaFlamme, Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene HyperLynx Matthew Flora*, Kellee Crisafulli IBM Greg Edlund*, Michael Cohen*, Praven Patel Incases Olaf Rethmeier, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson*, Jeff Day, Richard Mellitz, Peter Liou LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Chris Rokusek, Guy de Burgh*, Cary Mandel, (Jon Powell) VeriBest Ian Dodd VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf ECI Telecom Daniel Adar EIA Patti Rusher Electronique Catherine Gross EFM Consulting Ekkehard Miersch Intracon Design Mike Osmond FCI John Ellis Litton Systems Robert Bremer Molex Incorporated Gus Panella Nortel Networks (& Viewlogic) Martin Hall Oce Printing Systems Ernst Deiringer Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliatied, Retired) Bruce Wenniger 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 April 16, 1999 (916) 356-9200 5-103468 9824139 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 Neven Orhanovic is now at Applied Simulation Technology and is interested in IBIS and IMIC issues. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that several new members now exist based on paid invoices: Avanti (also one ibischk3 parser license) EMC Corporation Fairchild Semiconductor Time Domain Analysis Systems SiQual These companies are now listed in the Voting Members section above. Some other payments are still being checked. REVIEW OF MINUTES AND AR'S Bob Ross reported that Nik Bannov of Avanti has been corrected to Nikolai Bannov in the previous minutes (March 9, 1999, February 19, 1999 and February 1, 1999). The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob Ross noted that there was a change in the EIA structure that could impact the IBIS Open Forum. Bob is seeking more information on this. PRESS AND WEB PAGE UPDATES Bob Ross reported that some delays in getting the official EIA IBIS Web page updates has been resolved. A revised logo for Applied Simulation Technology and new logo for Siemens have been uploaded on the Poster page. Bob reported that Syed Huq has made some roster updates. Bob also reported that the IBIS/IMIC team (Bob, Stephen Peters, Raj Raghuram, Norio Matsui) and IBIS Officers and several others have responded to a request for input for a March 22, 1999 article on IBIS and IMIC. This will be a cover story in the Japanese magazine Nikkei Electronics. The editor asked several questions, and Bob and others responded. The article will be in Japanese. Arpad Muranyi asked about the status of this article and whether there will be an English version. Bob responded that he has asked some Mentor Graphics personnel in Japan to provide a translation. Bob noted that there was a brief mention of IBIS in the "Focus Report: PCB and MCM Tools" in the March 1999 issue of Integrated System Design, pp. 48-56. Also, the article "Stop Taking Your Models for Granted" by Cheryl Ajluni in Electronic Design, March 8, 1999, pp. 48-56 discusses IBIS and other types of models. Also two articles in the March 1999 issue of Printed Circuit Design Magazine mention IBIS: "Designing PC Motherboards: Little Margin for Error" by Greg Aldrich. pp. 20-23, and "Signal Integrity Software" by Keith Kowal, pp. 30-35. Bob noted that IBIS was mentioned several news publications in writeups associated with product press releases. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that Philips Semiconductor has added additional technologies at its previously reported Logic Modeling Link: http://www.philipslogic.com/support/ibis/ Also several links have been moved: Enhanced Memory Systems (Rampton) to: http://www.edram.com/modelreq.htm National Semiconductor to: http://www.national.com/models/ibis/ and PMC-Sierra to: http://www.pmc-sierra.com/products/Ibis/index.html Texas Instruments has a new link: http://www.ti.com/sc/docs/msp/flatlink/sim.htm and some Data Product models found by direct Search on IBIS that do not appear on the Data Products page. IBM has Power PC links for the 603e, EM603e, 604e, 740 and 750 series under the "Documentation" links (these models were formerly under other links): http://www.chips.ibm.com:80/products/powerpc/chips/ OPENS FOR NEW ISSUES Michael Cohen for Vref, Rref and Vmeas Discussion INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross repeated a previous report that IEC has circulated IBIS Version 2.1 on November 6, 1998. The Committee Draft for Vote (CDV) closes ballot on April 15, 1999. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross had no futher report other than the discussion above regarding a contribution to the Nikkei Electronics IBIS and IMIC article. Bob noted that we need to consider as an agenda item how IBIS and IMIC should be related. We have been deferring this discussion because of the other IBIS Open Forum activities and Version 3.2 and ibischk3 parser issues. - IEC 93/67/NP IBIS and EMC Simulation - Bob Ross noted that Jean-Claude Perrin planned an Experts meeting on March 12, 1999 to review a draft document. Bob has not yet seen the document. Arpad Muranyi asked, and Bob provided a general overview of what the group planned to do. The group is interested in adding syntax to the IBIS format to allow modeling EMI generation and EMI susceptability (through internal generators and transfer functions to pins). Bob has not yet seen the recent details. Bob noted that that there may also be other pending approaches to this from commercial vendors and from planned advances in the IMIC format. - JC-16.2 Subcommittee: Modeling and Test - No report. - IEEE P1537 Electronic Data Format Project (Previously listed as the Standard Component Data Sheet) - No report. IBIS (EAST) USERS GROUP MEETINGS Greg Edlund reported that the second conference call meeting was held on March 19, 1999. Accuracy Specification details were discussed. There may be interest in holding some IBIS User's Group face-to-face meetings again. Greg also noted that the Connector Group held one meeting separately after the DesignCon99 February 1, 1999 IBIS Summit meeting. Bob Ross noted that at the previous teleconference meeting on February 26, 1999, Ed Sayre had discussed the pending education activities. Arpad Muranyi asked what was planned, and Bob responded that Ed was thinking about getting a professional educator to develop an IBIS course. The material would then be available to anyone and might even be adapted by commercial vendors along with vendor specific issues. The course could possibly be uploaded for general distribution. Arpad noted that he is giving an IBIS course as part of the set of tutorials on Circuit Simulation and Signal Integrity in Microelectronic Circuits and Systems given April 19-21, 1999 in Phoenix, Arizona. Apad is willing to provide the course material, if he is permitted. AR - Arpad Muranyi check whether he can provide his material to the IBIS Open Forum. Bob noted that the next IBIS Users teleconference meeting is scheduled on April 9, 1999. DATE99 MARCH 9, 1999 IBIS SUMMIT MEETING FEEDBACK Bob Ross noted that he, Stephen Peters and Guy de Burg attended the second European IBIS Summit Meeting held in Munich, Germany at the same time as DATE99. Guy commented that this was a very effective meeting and appreciated hearing about the experiences and concerns from the European vendors. Several people were concerned about the quality of IBIS models. Bob elaborated that several presentations by Siemens addressed this issue by discussing internal model development processes and a list of new IBIS model requirements. Also, Bob noted that Dr. Bernhard Unger showed some extensions to his modeling approach which he had presented at the DesignCon99 February 1, 1999 IBIS Summit meeting to model SSO effects. The approach is interesting since it is based on some simple, additional waveforms and some multiplying coefficients to the existing model. Arpad Muranyi asked, and Bob responded that the presentations for this meeting are uploaded at: http://www.eda.org/pub/ibis/summits/mar99/ Bob noted that Mentor Graphics, INCASES Engineering and High Design Technology (HDT) funded the meeting. Based on the success of this meeting, Bob expects that another European IBIS Summit meeting will be held next year in Paris, France associated with the DATE2000 meeting. IBIS VERSION 3.2 EIA STANDARD PREPARATIONS Bob Ross reported that he does not know the current status regarding setting up an electronic balloting mechanism for ANSI/EIA-656A ratification of IBIS Verison 3.2 per plan at the January 15, 1999 meeting. Bob also stated that Arpad Muranyi provided a more readable copy of IBIS Version 3.2 in .pdf format. Arpad noted that it contains a table of contents for the keywords and sections. The document is uploaded as: http://www.eda.org/pub/ibis/ver3.2/ver3_2.pdf So far, no link exists to this document. You need to go directly into the directory to find it (and some other information). Matthew Flora suggested that a note be put in the current link on the EIA IBIS Home page regarding the existence of this document. IBISCHK3 VERSION 3.2.2 - VERSION 3.2.5 Since the February 19, 1999 meeting Version 3.2.4 has been distributed to the companies supporting the development. This version corrected a memory leak problem and the Hewlett-Packard operating system version has been fixed. Bob Ross commented that Chris Rokusek validated this last fix using Version 3.2.4. The bug was that ibischk3 was not able to correctly process IBIS files with file names longer than 8 characters on Hewlett-Packard workstations. It worked fine for other workstations and operating systems. IBIS Version 3.2 now supports file names up to 20 characters long. Bob noted that ibischk3 Version 3.2.4 still has the "preliminary" tag and identifies itself as version 3.2.3 from the -h menu. [After the meeting, Bob checked that this was incorrect - he may have called an older version of ibischk3.] We need to issue an approved release without the "preliminary" tag, and this should be designated Version 3.2.5. Matthew Flora volunteered to work with Atul Agarwal to modify the source code for the official release. AR - Matthew Flora work with Atul Agarwal to produce and distribute the official ibischk3 Version 3.2.5 release without the "preliminary tag. Bob noted that while this release may not be perfect, it is stable and very useful. We will make and upload ibischk3 executables for this release when it is available. Bob stated that the paperwork has been signed regarding compensating Atul Agarwal for his additional work. COOKBOOK STATUS (Not Discussed) IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora indicated that he had received some simple model questions that he could answer. He did not think these questions needed to forwarded to the other committee members. Everyone supported this approach. Matthew mentioned that several of the questions implied that people had not been using the latest version of IBISCHK2 (v2.1.17), so when they ran IBISCHK3, the warnings that were generated seemed new and limited to IBISCHK3 or to IBIS 3.2. Therefore, there was concern that people would not use IBISCHK3 for validating IBIS 2.1 models. Matthew suggested updating the IBIS Open Forum Web site to in someway indicate that IBISCHK3 is the recommended parser to be used to validate any IBIS model. Bob Ross wanted to remove the long-standing AR that Matthew provide a short write-up on the model review committee work. The information is available. AR - Matthew Flora to communicate with Syed Huq regarding puttind a tag line next to the IBISCHK3 link to indicate that the committee recommends IBISCHK3 be used for all cases instead of IBISCHK2. OLD TOPIC - BIRD56 - RELAXATION OF THE [Series Pin Mapping] RESTRICTION Bob Ross also removed an old AR for Arpad Muranyi to provide a sample IBIS model related to BIRD56. A sample has already been provided. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross gave the history of BUG34. Under certain conditions ibischk3 does not issue a Warning or Error message when [Pulldown] and [Pullup] tables are missing from an output buffer. We had classified this as Annoying, Low, and Open. We also did not include fixing this problem as part of the extended ibischk3 parser project because (1) this problem has existed in all versions of the ibischk parser, and (2) we needed time to understand what combinations of Model_types and missing tables were to be reported. In other words, it was not a critical problem in practice, and it would require some work to formulate a solution. Matthew Flora, who submitted BUG34, further stated that he would accept a Warning message. Matthew also noted that the existance of the required [Ramp] keyword was checked. Arpad Muranyi wondered if this was really an error since the IV tables are optional. Bob stated that the document makes the [Pullup] and [Pulldown] tables optional because Open_drain (Open_sink) and Open_source model types do not require both tables. However, simulators needed both tables for totem pole outputs and one table for Open_* outputs. There are cases where only one table is needed if the optional [Rising Waveform] and [Falling Waveform] tables clearly indicate an Open_drain or Open_source characteristic even if the Model_type is Output. In this case the [Ramp] keyword is ambigous. But it is overridden by the waveform information. Bob proposed that Matthew list all of the conditions where a Warning message is needed. This may involve grouping all Output_*, 3_state_* and I/O_* model types and documenting the [Pullup] and [Pulldown] tables. The reason that a Warning is given is that there still could be sufficient information with waveform tables is a [Pullup] or [Pulldown] table is omitted. This would be issued as a revised BUG34. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. Bob noted that this check would provide a suitable Warning. However it still would not capture some pathelogical problems. An example would be having both IV tables having meaningless data (such as 0 currents in both). BIRD58 - DRIVER SCHEDULE KEYWORD CLARIFICATION Arpad Muranyi stated that he issued BIRD58 because a key clarification paragraph that existed in BIRD35.3 was not in the Version 3.2 document. The paragraph states that a top-level set of [Pullup], [Pulldown] and [Ramp] data is required, but is not used. Rather, the model is composed only of the models referenced by the [Driver Schedule] keyword. Arpad discovered this omission while trying to construct an IBIS model using the information from the Version 3.2 document. Arpad wanted only to provide minimal changes so as not to impact the process to ratify IBIS Version 3.2. Matthew Flora presented several other editorial changes (but was confused with the sections regarding what the [Driver Schedule] keyword delays mean). Bob Ross noted that all of the clarifications are editorial and are permitted as part of the formal review process. Bob Ross also commented on some questions by Steve Kaufer of HyperLynx. Steve also had questions regarding how the top-level model was to be interpreted and how the delays were to be simulated. Bob noted that the top-level model was required, but not used. It could be used for validation purposes or to be used when the simulator did not support the [Driver Schedule] keyword but still needed a "stub" model for simulation. Bob stated that this would not normally be as accurate. Arpad suggested that the top-level model could have accurate IV tables. Bob questioned what would be accurate since the tables could be switched in and out. Bob suggested an accurate VT representation so that the end-point checks would be met using ibischk3. However, such a table might be non-monotonic - a possible problem with some simulators. Bob also indicated that if both Rise_on_dly and Fall_on_dly values are given, they are relative to the begining of the "clock" rising edge and "clock" falling edge respectively. Bob plans to provide a written response to these questions on the IBIS reflector. Matthew Flora asked if having all NA's is permissible. Bob thought that this was not prohibited, but that this was an ambigous case. The scheduled model would not switch, but the simulator would not know what state the device was in (for example, "low" or "high" state, or also "high-Z" or "on"). This prohibition could also be added as an editorial clarification. The required top-level information includes overall Model_type, C_comp and stub [Pullup], [Pulldown] and [Ramp] information. Clamping information is moved to the top-level so that the input mode of an I/O_* model has all of the information visible. After these and other comments, Bob suggested that Arpad issue BIRD58.1 with Matthew's comments. More detailed discussion on this topic should move to the IBIS reflector. VREF, RREF, VMEAS DISCUSSION Michael Cohen expressed concern that he sees many IBIS models with incorrect, missing or unrealistic Vref, Rref, and Vmeas entries. He feels that many IBIS model developers do not understand the meaning of these parameters. For example, he has seen Open Drain models with Rref connected to a Vref to ground. He has also seen Rref, but no corresponding Vmeas. Michael suggested more discussion in the Cookbook and possibly a Version 3.2 parser check. Bob Ross indicated that Vmeas and timing test loads are strongly suggested for all I/O_*, 3-state_* and Output_* models, but are technically not required for historical upward compatibility reasons. However, several simulators really use this information. Bob suggested that this could be a topic for more reflector discussion (as meeting time ran out). ONNECTOR PROPOSAL REVIEW (Not Discussed) ACCURACY SPECIFICATION REVIEW (Not Discussed) NEXT MEETING: The following teleconference meeting will be on Friday, April 16, 1999 from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, 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 Systems (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 Wed Mar 31 13:51:07 1999 Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA06003 for ; Wed, 31 Mar 1999 13:51:06 -0800 (PST) From: jaydiep@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id QAA105608 for ; Wed, 31 Mar 1999 16:45:13 -0500 Received: from d54mta06.raleigh.ibm.com (d54mta06.raleigh.ibm.com [9.67.228.38]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v1.8) with SMTP id QAA39672 for ; Wed, 31 Mar 1999 16:45:07 -0500 Received: by d54mta06.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256745.00777BCA ; Wed, 31 Mar 1999 16:45:04 -0500 X-Lotus-FromDomain: IBMUS To: ibis_list@us.ibm.com Message-ID: <85256745.007778C6.00@d54mta06.raleigh.ibm.com> Date: Wed, 31 Mar 1999 16:45:40 -0500 Subject: IPA 510 software Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Dear IBIS gurus, I just read the minutes of the summit held on 3/26, and there was no mention of the above subject. I recall that the discussion was tabled at a (several?) previous meeting(s), but there are those of us out here for which the IPA 510 software would be of great benefit even without any support (though some minimal documentation would obviously be useful). I would like to request that the subject again be brought to the table and resolved if possible, so those of us in the user community might have the benefit of its use. I won't pretend to understand all the legal ramifications of the IBIS Forum "owning" the distribution of the software, but it would seem that if it's understood that the software is distributed "as is," there would not be any liability nor any implied burden to support or upgrade it. Thanks for your consideration. Jay Diepenbrock Senior Engineer Interconnect Technology & Qualification IBM Global Procurement, B8UA/061, RTP, NC Phone: 919-543-8804 Fax: 919-543-3642 Email: jaydiep@us.ibm.com From owner-ibis Wed Mar 31 17:24:58 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA06760 for ; Wed, 31 Mar 1999 17:24:58 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA07085; Wed, 31 Mar 1999 17:19:01 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA27109; Wed, 31 Mar 1999 17:18:59 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3702C983.AA8E2058@mentor.com> Date: Wed, 31 Mar 1999 17:18:59 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: Re: BIRD58 discussion References: <4575832C8E71D111AC4100A0C96B512703BB0AF6@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad: You have made some very good observations. I have a few comments in your text in UPPERCASE. My suggestion is to consider the points and then draft a BIRD58.1 which will force some choices. We then have a reference for more discussion. Bob Ross Mentor Graphics To all involved in this conversation, This is in response to the comments posted in connection with BIRD58 by Steve, Matt (Hyperlinx) Mike (Cadence) and Greg (IBM). Hopefully BIRD58.1 will follow shortly. I am not going to address some of the simpler issues which deal with spelling and simple English clarity. I will come up with something for those in the next revision of the BIRD. Also, I don't understand Matt's question, quote: "The above excerpt refers to transitions and a rising cycle. When is the text referring to the transition (cycle) of the output of the buffer as a whole versus the transition (cycle) of the added "boost" model?" so I am not going to address it now. Matt, could you please explain to me what you meant? Problem #1 (these are my numbers now) ========== The major issue seems to revolve around where things go between the top level and the scheduled models. The following section quoted from the spec (unchanged in BIRD58) makes a clear statement that the only things that are used from the scheduled models are the pd and pu I-V curves (not including the clamp I-V curves) and the V-t curves along with the Ramp information. According to the last sentence, it is not illegal to define the specification information, clamp I-V curves and C-comp in the scheduled model(s). However, to me this says that if they are there, they should be ignored, because this information is "provided" by the [Model] keyword (meaning the top-level model). | 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. I hate to say this, but according to this, if we want to allow the scheduled models to carry "usable" information other than the pd, pu I-V curves, V-t curves and Ramp information is a spec change. Of course it is a different question what the tools actually do with the data that is not supposed to be there. If they use it, they actually violate the spec, in my opinion. On the other hand, Greg has a good point about the user of the model getting confused and possibly expecting different results not knowing what is used or not. But why should we allow redundant data if it is not supposed to be used (according to the paragraph above)? This relates to some other issues to which I will return below. SOME CHOICES WERE MADE AT THE TIME OF ADOPTION BASED ON SOME EXISTING PRACTICAL CONSIDERATIONS: (1) THE TOP LEVEL MODEL CONTAINED IN ONE LOCATION THE "INPUT" OR "HIGH-Z" STATE INFORMATION FOR EASY REFERENCE. (THUS C_COMP AND THE CLAMPS.) THE ASSUMPTION WAS THAT THESE WERE ALWAYS IN THE BUFFER REGARDLESS OF ANY SCHEDULED TURN ON OR TURN OFF OF ANY BUFFER. THIS MADE IT EASIER TO LOCATE THESE PARAMETERS. (I NOW WOULD RECONSIDER THIS.) (2) THE "SPECIFICATION" PARAMETERS, "POLARITY" AND "MODEL TYPE" OF THE TOP-LEVEL PROVIDED THE OVERALL DEFINITION. (THUS, WE DID NOT HAVE TO DEAL WITH ANY CONTRDICTORY INFORMATION IN THE SCHEDULED MODELS. (3) THE SCHEDULED MODELS COULD FUNCTION AS COMPLETE, INDEPENDENT MODELS (ONE APPLICATION WOULD BE TO MODEL DOUBLE-STRENGTH, PARALLELED BUFFERS USING DRIVER SCHEDULE KEYWORD.) (4) WE WANTED TO ADD DRIVER SCHEDULE WITH A MINIMUM OF NEW, SPECIAL SYNTAX RULES WHICH WOULD HAVE COMPLICATED THE IBISCHK3 PARSER WITH A LOT OF NEW SPECIAL CASES. ALSO, THE MODEL DEVELOPER WOULD THEN HAVE DIFFERENT RULES FOR DIFFERENT SITUATIONS. (5) THE TOP-LEVEL MODEL PROVIDED A "STUB" MODEL OF LOWER ACCURACY AND WITH A POSSIBLE "GOLDEN WAVEFORM" THIS WAS LEFT OPEN. AT THAT TIME, SIMULATORS WERE JUST ADDING THE DRIVER SCHEDULE FEATURE, SO THIS PROVIDED A LOWER-LEVEL ALTERNATIVE (JUST LIKE USING RAMP IN PLACE OF UNUSABLE OR BAD WAVEFORM DATA). I WOULD PROBABLY MAKE A FEW DIFFERENT CHOICES TODAY. HOWEVER, THIS PROVIDES SOME OF THE OVERALL CONTEXT FOR WHICH THE DRIVER SCHEDULE KEYWORD IS BASED. Problem #2 ========== Matt brought up that the above section does not include the voltage range, and reference voltages, and asks where those should be placed. In my opinion they are all mentioned in the above section if we look at the meaning of the words "specification information" carefully. This is arguable, but to me the comma after the word "information" is an indication for a list, which means that the words "specification information" do not refer to the following items in the sentence ([GND Clamp] and [POWER Clamp], and C_comp), but to all other IBIS parameters and subparameters not listed here. According to this argument everything goes, including voltage range, reference voltages, Vinh, Vinl, Vref, Cref, etc. And using the previous argument, these should all be in the top-level model, or else they must be ignored. IN THIS CASE, I FAVOR USING THE GIVEN VOLTAGE RANGES AND REFERENCE VOLTAGES THAT EXIST IN THE SCHEDULED MODEL. THEY ARE REQUIRED AND NEEDED IF THE SCHEDULED MODEL COULD EXIST AS A COMPLETE MODEL BY ITSELF. THE VOLTAGE RANGE AND REFERENCES ARE REALLY RELATED TO THE PULLDOWN AND PULLUP KEYWORDS AND RAMP AND WAVEFORM DEFINITIONS OF THE SCHEDULED MODELS. SO SCHEDULED MODEL VOLTAGES SHOULD OVERRIDE THE TOP LEVEL VOLTAGES. I WOULD FAVOR ADDING CLARIFICATION ON THIS. THE TOP LEVEL VOLTAGES WOULD STILL BE USED FOR THE TOP-LEVEL MODEL DATA. And please don't call me a lawyer, some times we just have to look at the words the way they are written :-) On the other hand, if the comma in the above sentence was intended to mean "i.e.", the previous argument is invalid, and the remaining keywords should all be listed in this section one by one with appropriate explanations on where they should be placed. Problem #3 ========== Matt raised the following question: "It appears that the intent of the keyword is to allow the drive strength of an output buffer to be increased or decreased by adding in (and/or taking out) various tables from other models at strategic times during the transitioning of the buffer's output. Is this intent stated in the spec?" The answer is in the spec/BIRD58: | 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. | YOUR EXAMPLE IN PROBLEM #4 GIVES A CASE WHERE AN OUT OF PHASE PULLDOWN (BASED ON THE RISE_ON_DLY AND RISE_OFF_DLY) PROVIDES AN PULLDOWN CURRENT THAT REDUCES THE OVERALL DRIVE STRENGTH. ALSO, IT IS THEORETICALLY PERMITTED TO SCHEDULE A FALL_ON_DLY LATER THAN A FALL_OFF_DLY TO GET AN OPPOSITE POLARITY EFFECT TO REDUCE THE STRENGTH. THIS IS HOW WE COULD DEAL WITH DIFFERENT POLARITIES IN THE SCHEDULED MODELS. WE DID NOT USE THE SCHEDULED MODEL POLARITY INFORMATION, BUT MADE EXPLICIT REFERENCE TO LOW-TO-HIGH OR HIGH-TO-LOW TRANSITION DEFINITIONS. Problem #4 ========== Steve asked the following question: "Do models that are turned on in one transition carry over, still turned on, into the opposite transition?" with examples to illustrate the issue. I discussed this with Bob at length and I concluded the following. I feel that the meaning of the delay parameters may not be clear to most readers (which included myself). Think of an open sink buffer for the next four points. This buffer has a pulldown driver only, which is basically a GTL type buffer. Let's assume that the model uses the [Driver Schedule] keyword. The meaning of the delay parameters then is as follows: a) Fall_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device. This is the normal way to turn on a driving device. b) Fall_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. This can turn off a driving device before the next edge occurs. c) Rise_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. This turns the driving device off on the subsequent edge, and is the normal way of turning it off. d) Rise_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device. In my opinion this case is purely theoretical and impractical. The point I am trying to make here is that the pulldown can be turned on/off by either one of the two internal pulses, and this is defined through the particular delay variable used. An equivalent truth table can be made for a pullup device. For a complementary driver (which is a combination of both pullup and pulldown devices) the truth table for these parameters is as follows: a) Fall_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pulldown device and turns OFF the I-V curve of the pullup device if it was not turned off by the Rise_off_dly parameter yet. This is the normal way of doing a high to low transition. b) Fall_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a FALLING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pulldown device. Theoretically, this parameter could also be used to turn on the pullup device from the falling internal pulse, but it is highly unlikely that it would be done in practice. c) Rise_on_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns ON the I-V curve of the pullup device and turns OFF the I-V curve of the pulldown device if it was not turned off by the Fall_off_dly parameter yet. This is the normal way of doing a low to high transition. d) Rise_off_dly => is the amount of time that elapses from the internal simulator pulse initiating a RISING edge and the actual t=0 time of the V-t curve that turns OFF the I-V curve of the pullup device. Theoretically, this parameter could also be used to turn on the pulldown device from the rising internal pulse, but it is highly unlikely that it would be done in practice. (I hope I got it right...) Note that even though these parameters use the words "on" and "off", they don't always refer to the devices being turned on and/or off. This may partially be the reason for much of the confusion. So given all this, if we are modeling a complementary buffer, which has only on-delays (rise_on_dly and Fall_on_dly) specified in its model, the previous state must be extended to the time when the new transition begins. This may result in a situation in which a buffer with more than one stages will have crowbar currents between one or more of its delayed and/or non delayed stages. Notice that there is one special case that seems impossible with the above tables. Here is a falling edge example to illustrate that: The pullup of a complementary buffer is turned off by the falling edge without delay but the pulldown is turned on with a delay by the same edge. This combination can still be modeled by separating the pullup and pulldown halves of the buffer into two open_??? models. USING "OPEN_* BUFFERS IS ACTUALLY THE PREFERRED APPLICATION. HOWEVER, WITH TOTEM STRUCTURES AND WITH 2-RISING AND 2-FALLING WAVEFORMS, YOU CAN ALSO GET THE INDIVIDUAL PULLDOWN AND PULLUP TURNON AND TURNOFF CHARACTERISTICS OF THAT SCHEDULED MODEL (AND WHATEVER CROWBAR CURRENT OR LACK OF CROWBAR CURRENT THAT MAY BE PRODUCED). Problem #5 ========== Quote from Matt: "If the Rise_on_dly and Rise_off_dly specify the start of the added "boost" model's rising edge and falling edge, respectively, then the example shows "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during the rising transition of the output buffer. Yet the excerpt above says "For each model, the transition sequence must be complete, i.e., it must start and end at the same state." This strikes me as a contradiction." Keeping in mind the reasoning from the previous point, this is not a contradiction. Note that the examples mentioned in this quote use two "ON" delays. However, note that one of the "ON" delay actually turns the device off. So these examples correctly show that the scheduled device started and ended in the same state (OFF). Problem #6 ========== Quote from Matt: "Must at least one of the delay times be specified or can all four be NA?" Given the example in the previous problem and the requirement that the model starts and finished in the same state, one may quickly realize that only five combination of the delay parameters are valid. One of the invalid combinations is the four NAs. I AGREE THAT 4 NAS IS NOT ONLY MEANLESS, BUT YOU DO NOT KNOW WHAT STATE THE BUFFER IS IN (LOW OR HIGH FOR A TOTEM POLE OUTPUT) OR (HIGH-Z OR ON FOR AN OPEN_* OUTPUT) Problem #7 ========== I would like to revisit the issue of C_comp. First of all, my statement in the last teleconference was not entirely correct, which will become apparent from the following thoughts. In the meeting I suggested that having one C_comp in the top-level model may cause less accurate simulation results, because the simulator has to compensate for the effects of C_comp in the V-t curves. My reason was that the independent V-t curves in the models of the separate stages requires that we know what C_comp is for each of those stages, and a combined value in the top-level model is not sufficient. Mike basically seconded this idea in his EMAIL response. After thinking about this some more I realized that this is only true if the models of each stage were generated independently, that is completely separated from each other in the netlist. However, one can also make a model for each stage by just disabling the stages that are not needed for the model of the particular stage being modeled. If models are generated with this method, the capacitance of the disabled stages will still load the V-t curve of the one stage that is being modeled, therefore a combined C_comp is what should be used in the simulators for compensating the V-t curves. This would suggest that the proper place for C_comp is in the top level model. So this really boils down to what technique is used during the generation of the V-t curve data. ONE PRACTICAL METHOD IS TO SET C_COMP TO 0 IN ALL SCHEDULED MODELS AND USE THE TOP-LEVEL C_COMP AS A LOAD. THIS IS ALREADY COMPATIBLE WITH SOME OTHER FORMATS AND SUPPORTS SEEING THE C_COMP IN THE HIGH-Z OR INPUT MODE. THE OTHER METHOD, AS YOU SUGGEST IS TO DISTRIBUTE THE C_COMP IN THE INDIVIDUAL SCHEDULED STAGES AND PRODUCE THE CORRESPONDING WAVEFORMS ASSUMING THOSE LOADS. WE MAY PUT C_COMP = 0 IN THE TOP-LEVEL MODEL. WE WOULD HAVE TO SPECIFY THAT IN THE INPUT OR HIGH-Z STATE, ALL OF THE SCHEDULED DRIVER C_COMP VALUES WOULD BE ADDED. I WOULD ALSO SUPPORT ALLOWING THIS, BUT THIS WOULD CHANGE THE SPEC. THE TOP-LEVEL MODEL C_COMP VALUE, IF ANY WOULD STILL SERVE AS A LOAD TO THE SCHEDULED MODELS. ALSO, THE TOP-LEVEL C_COMP WOULD SERVE AS THE TOTAL C_COMP BOTH FOR DRIVER AND INPUT OR HIGH-Z MODE IF IT WERE USED AS A STUB MODEL. HOWEVER, IT IS ALREADY KNOWN TO BE NOT AS ACCURATE AS THE FULL DRIVER SCHEDULE MODEL. THEREFORE THIS IS NOT A MAJOR PROBLEM. Given the argument in the first point, it may make sense to keep C_comp in the top level only, and instruct the model maker that the V-t curves of the stages should always be generated by keeping the whole buffer in the netlist, only disabling the unwanted sections using the controls of their prediver circuit. Another reason to keep all of the "remaining parameters" in the top level model is that the staged models are really used only for describing the driver, hence the name [Driver Schedule]. The information that is used for receiver mode operation are supposedly all in the top-level model (if we agree with what I wrote above). Summary ======= The situation is not as bad as I thought before. With a few clarifications and/or rewording I believe that the existing spec is good and useful without any functional changes. I am sorry that this turned out this long, but this is a fairly complicated problem. I AGREE, BUT WE HAVE SOME CHOICES TO MAKE. WE CAN GIVE MORE DETAILS AS AN EDITORIAL INTERPRETATION BASED ON WHAT PEOPLE WANT AND HAVE ALREADY IMPLEMENTED I am eager to hear your comments. Sincerely, Arpad Muranyi Intel Corporation ==================================================================== From owner-ibis Wed Mar 31 17:46:29 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA06832 for ; Wed, 31 Mar 1999 17:46:28 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA08121; Wed, 31 Mar 1999 17:40:31 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA29729; Wed, 31 Mar 1999 17:40:30 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3702CE8E.E3F27E0F@mentor.com> Date: Wed, 31 Mar 1999 17:40:30 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: jaydiep@us.ibm.com CC: ibis@eda.org Subject: Re: IPA 510 software References: <85256745.007778C6.00@d54mta06.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jay: We had a long discussion at the February 19, 1999 meeting and raised a large number of pro and con arguments. By a split vote, we decided that the IBIS Open Forum should not manage this software. The minutes are archived under: http://www.eda.org/pub/ibis/minutes/m021999.txt Best Regards, Bob Ross Mentor Graphics Dear IBIS gurus, I just read the minutes of the summit held on 3/26, and there was no mention of the above subject. I recall that the discussion was tabled at a (several?) previous meeting(s), but there are those of us out here for which the IPA 510 software would be of great benefit even without any support (though some minimal documentation would obviously be useful). I would like to request that the subject again be brought to the table and resolved if possible, so those of us in the user community might have the benefit of its use. I won't pretend to understand all the legal ramifications of the IBIS Forum "owning" the distribution of the software, but it would seem that if it's understood that the software is distributed "as is," there would not be any liability nor any implied burden to support or upgrade it. Thanks for your consideration. Jay Diepenbrock Senior Engineer Interconnect Technology & Qualification IBM Global Procurement, B8UA/061, RTP, NC Phone: 919-543-8804 Fax: 919-543-3642 Email: jaydiep@us.ibm.com