From owner-ibis Wed Oct 4 11:32:25 2000 Received: from InterJet.microcontrol.com (mcceng.visi.com [209.98.4.34]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e94IWLX02868 for ; Wed, 4 Oct 2000 11:32:24 -0700 (PDT) Received: (from daemon@localhost) by InterJet.microcontrol.com (8.8.5/8.8.5) id PAA08441 for ; Wed, 4 Oct 2000 15:23:08 -0500 (CDT) Received: from H47K101.microcontrol.com(192.168.1.214), claiming to be "microcontrol.com" via SMTP by InterJet.microcontrol.com, id smtpdyL8429; Wed Oct 4 20:23:02 2000 Message-ID: <39DB73DA.A58F02FC@microcontrol.com> Date: Wed, 04 Oct 2000 13:15:55 -0500 From: Mike Loerzel Organization: Micro Control Company X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: PWM Pspice model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anybody know where I can find a complete Pspice model for a Pulse Width Modulator? Thanks, -- Mike Loerzel New Product Design Technician MICRO CONTROL COMPANY 7956 Main St. NE, Mpls, MN 55432 PH: 612-277-9243 Fax: 612-786-6543 EMAIL: m.loerzel@microcontrol.com From owner-ibis Fri Oct 6 11:52:20 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e96IqGX17135 for ; Fri, 6 Oct 2000 11:52:19 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id LAA11836; Fri, 6 Oct 2000 11:49:20 -0700 (PDT) Received: from cadence.com (d158140105119 [158.140.105.119]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id OAA10895; Fri, 6 Oct 2000 14:49:19 -0400 (EDT) Message-ID: <39DE1EAD.2EE70CC7@cadence.com> Date: Fri, 06 Oct 2000 14:49:17 -0400 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Ross CC: ibis@eda.org Subject: Re: IBIS BIRD64.1 - Package Model Selector References: <3835F5DD.75E6DBCB@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as LAA11836 at Fri Oct 6 11:49:20 2000 To follow up on my comments on BIRD 64.1 at the IBIS forum teleconference today, I would like to propose that: 1) The BIRD should declare scoping requirements It is not stated where the [Package Model Selector] can appear in an IBIS file, and to which [Component] it applies. We might add a paragraph like: ############################################################# Each [Package Model Selector] keyword specifies the set of package models for only one component, which is given by the previous [Component] keyword. The [Package Model Selector] keyword may not appear before the first [Component] keyword in an IBIS file. ############################################################# 2) [Package Model] and [Package Model Selector] are mutually exclusive When [Package Model Selector] is used, [Package Model] makes no sense. The [Package Model] keyword *could* give the name of the default package model, but I agree with the idea of the default as specified by the first [Package Model Selector] value. We might add a paragraph like: ############################################################# The appearance of the [Package Model Selector] keyword after a [Component] keyword overrides any [Package Model] keyword that may appear often the same [Component] keyword. ############################################################# Concerning Roy Leventhal's comment on how [Package Model Selector] might be used, I see 2 issues: A) The assignable package models must have the same pinouts. Although some die can be shipped in various packages, the physical pin arrangements are often altered to accommodate each package. The designs that incorporate these parts are routed differently. A simulation tool might not be able to iterate through the set of package models while maintaining consistency with the design at hand. A part with both plastic and ceramic packages, on the other hand, might be easily accommodated, assuming the pinouts are the same. B) A fully specified part name encompasses the package type. Some companies may have model naming policies that require model names to match manufacturer part numbers. But this makes the model package-specific. A good example is ceramic vs. plastic, where the manufacturer part numbers include different package suffixes. In fact, the design environment may count on package-specific model names, to assist with associating parts with models. In this case, "radically" different package models should not be assigned. But I don't see this as a reason to not *allow* radically different package models in a [Package Model Selector] list. Mike LaBonte Cadence Design Systems Bob Ross wrote: > > To IBIS Committee: > > Arpad Muranyi submitted BIRD 64.1 in response to a number of recent > comments including those made at the November 19, 1999 IBIS Meeting. > BIRD64.1 does not necessarily implement some of the comments. The > Analysis and Background sections have been expanded significantly and > contain some of the rationale for this revision. We expect more > discussion and debate. > > Bob Ross > Mentor Graphics > > ******************************************************************************* > ******************************************************************************* > > BIRD ID#: 64.1 > ISSUE TITLE: Package Model Selector > REQUESTER: Arpad Muranyi, Intel > DATE SUBMITTED: 10-25-99, 11-19-99 > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > > ****************************************************************************** > ****************************************************************************** > > STATEMENT OF THE ISSUE: > > The current IBIS specification (3.2) does not provide a selection mechanism > for multiple package models. This may be necessary when a certain die is > shipped in various package styles, or when the corner cases of the package > are described with different package models. > > This BIRD is written to provide an easy solution to this deficiency. This > feature will allow simulator tools to implement a user friendly package > model selection interface and/or better automation for batch and sweep > simulations. > > ****************************************************************************** > > STATEMENT OF THE RESOLVED SPECIFICATIONS: > > A new keyword shall be introduced in the IBIS specification to provide a user > friendly package model selection mechanism for components which use multiple > package models. The proposed keyword [Package Model Selector] shall contain a > list of all package model names that the simulator can pick from. The first > entry in the list is considered to be the default package model. The package > model names listed under the [Package Model Selector] must follow the rules > of the package model names associated with the [Package Model] keyword. > > To help the user of the simulator tool to make an intelligent choice, it is > highly recommended that a description be placed to the right of each package > model name in the list as a comment. > > |============================================================================= > | Keyword: [Package Model Selector] > | Required: No. > | Description: Used to select a package model from a list of package models. > | Sub-Params: None. > | Usage Rules: The [Package Model Selector] keyword can be used in place of > | the [Package Model] keyword. The only difference between the > | two keywords is that the [Package Model Selector] allows > | multiple package models to be listed. All package model names > | must appear below the [Package Model Selector] keyword. > | > | The package model names listed under the [Package Model > | Selector] must follow the rules of the package model names > | associated with the [Package Model] keyword. > | > | The first entry under the [Package Model selector] keyword > | shall be considered the default by the simulator tool. > |============================================================================= > | > [Package Model Selector] > | > 208-pin_plastic_PQFP_package-even_mode | What more can be said here? > 208-pin_plastic_PQFP_package-odd_mode | It's all in the name. > 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here. > 208-pin_ceramic_PQFP_package-odd_mode | And some more here too. > | > ****************************************************************************** > > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: > > Problem statement > > Some components are shipped in multiple package styles. Also, there are > situations when the corner cases of a package are modeled with multiple > package models. Currently, in these cases the user of the IBIS model has to > manually edit the IBIS file to change the package model name that is called by > the [Package Model] keyword in order to reference a different package model. > This makes automated simulations difficult, if not impossible. > > Possible solutions > > Add a new, simple keyword to the IBIS specification which works similar to the > already existing [Model Selector] keyword. > > ****************************************************************************** > > ANY OTHER BACKGROUND INFORMATION: > > Several IBIS model users expressed their desire in private conversations and > IBIS meetings to have such a package model selection mechanism in the IBIS > specification to make their work easier. > > An alternate syntax was suggested by Bob Ross during an EMAIL and telephone > correspondence on 10/25/99. The suggested syntax is identical to the [Model > Selector] syntax, according to which the [Package Model Selector] would be > assigned a name that is called by the (higher level) [Package Model] keyword. > However, unlike in the [Model Selector] case, there is no need for calling the > [Package Model Selector] from a higher level. This BIRD favors the simpler > vs. the more consistent approach. > > Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ., > min., and max. columns in the list of package models under the model selector > name to assist in automating the package model selection based on corner > cases. According to the exisiting rules this is not possible, becuase the > package model names are allowed to be up to 40 characters in length. Three > package model names on the same line could add up to 122 characters, which > violates the current 80 character per line rules of the IBIS specification. > > Further, package model names are allowed to include blank characters, which > requires a delimiter other than the space or tab character between the > typ., min., and max. columns. The usage of a new delimiter introduces another > inconsistency in the IBIS specification, since spaces and/or tab characters > are widely used as delimiters between columns in current IBIS versions. > > A technical dilemma regarding the automated selection of package models based > on typ., min., and max. qualifiers remains to be answered also. What do typ., > min., and max. represent? Impedance, wave velocity, trace length, or perhaps > the amount of cross talk? Simulation tool users will most likely make their > choices based on individual preferences, possibly depending on project > requirements. For this reason it seems to make more sense to give only a list > that contains all of the package models without the typ., min., and max. > qualifiers. The selection and automated usage of the various package models > should then be done through a GUI or configuration mechanisms provided by the > tool. > > The differences between the model name and package model name restrictions > required a change even in this BIRD. The description field of the [Model > Selector] keyword is separated by one or more space or tab character(s) from > the model name. However, since package model names can contain blank > characters, space or tab characters will not work as delimiters for the > description field of the [Package Model Selector] keyword. > > Since the contents of the description field is only used for informational > purposes which does not effect the simulations I decided to use the comment > character (|) as the delimiter for now. This option was actually discussed > for the [Model Selector] also but voted down for the reason that tools reading > an IBIS model have all the rights to ignore all comments, therefore a GUI > would not know how to distinguish between a legitimate descrription and a > meaningless comment. Does anyone have a better suggestion? > > ****************************************************************************** From owner-ibis Fri Oct 6 14:59:10 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e96Lx7X17687 for ; Fri, 6 Oct 2000 14:59:10 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA26627; Fri, 6 Oct 2000 14:56:08 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA02886; Fri, 6 Oct 2000 14:56:06 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39DE4A76.7B98CD0E@mentor.com> Date: Fri, 06 Oct 2000 14:56:06 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mike LaBonte CC: Bob Ross , ibis@eda.org Subject: Re: IBIS BIRD64.1 - Package Model Selector References: <3835F5DD.75E6DBCB@mentor.com> <39DE1EAD.2EE70CC7@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike: Great job in capturing the issues discussed at the October 6, 2000 meeting. Could you actually prepare BIRD64.2 for distribution on the IBIS reflector? This would involve inserting your proposed text changes as they would appear in the final document, adding reasons and comments to the ANALYSIS PATH ... section and listing yourself as a co-author and adding the new date to the list of dates when you send it out. We may have to respond to comments on your proposed improvements issue additional revisions of BIRD64.2 prior to a scheduled vote at the next meeting. Thanks, Bob Ross Mentor Graphics Mike LaBonte wrote: > > To follow up on my comments on BIRD 64.1 at the IBIS forum > teleconference today, I would like to propose that: > > 1) The BIRD should declare scoping requirements > It is not stated where the [Package Model Selector] can appear > in an IBIS file, and to which [Component] it applies. We might > add a paragraph like: > > ############################################################# > Each [Package Model Selector] keyword specifies the set of > package models for only one component, which is given by > the previous [Component] keyword. The [Package Model Selector] > keyword may not appear before the first [Component] keyword > in an IBIS file. > ############################################################# > > 2) [Package Model] and [Package Model Selector] are mutually exclusive > When [Package Model Selector] is used, [Package Model] makes > no sense. The [Package Model] keyword *could* give the name of > the default package model, but I agree with the idea of the > default as specified by the first [Package Model Selector] value. > We might add a paragraph like: > > ############################################################# > The appearance of the [Package Model Selector] keyword after > a [Component] keyword overrides any [Package Model] keyword > that may appear often the same [Component] keyword. > ############################################################# > > Concerning Roy Leventhal's comment on how [Package Model Selector] > might be used, I see 2 issues: > > A) The assignable package models must have the same pinouts. > Although some die can be shipped in various packages, the physical > pin arrangements are often altered to accommodate each package. > The designs that incorporate these parts are routed differently. > A simulation tool might not be able to iterate through the > set of package models while maintaining consistency with the > design at hand. A part with both plastic and ceramic packages, > on the other hand, might be easily accommodated, assuming the > pinouts are the same. > > B) A fully specified part name encompasses the package type. > Some companies may have model naming policies that require > model names to match manufacturer part numbers. But this > makes the model package-specific. A good example is ceramic > vs. plastic, where the manufacturer part numbers include > different package suffixes. In fact, the design environment > may count on package-specific model names, to assist with > associating parts with models. In this case, "radically" > different package models should not be assigned. But I don't > see this as a reason to not *allow* radically different package > models in a [Package Model Selector] list. > > Mike LaBonte > Cadence Design Systems > From owner-ibis Fri Oct 6 15:21:10 2000 Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e96ML9X17751 for ; Fri, 6 Oct 2000 15:21:09 -0700 (PDT) Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com (8.9.3/8.9.3) with ESMTP id XAA18999; Fri, 6 Oct 2000 23:16:20 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com (8.9.3/8.9.3) with SMTP id XAA29785; Fri, 6 Oct 2000 23:12:46 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256970.007ADAA8 ; Fri, 6 Oct 2000 23:21:53 +0100 X-Lotus-FromDomain: 3COM From: "Roy Leventhal" To: Mike LaBonte cc: Bob Ross , ibis@eda.org Message-ID: <80256970.007AD3B8.00@notesmta.eur.3com.com> Date: Fri, 6 Oct 2000 16:59:57 -0500 Subject: Re: IBIS BIRD64.1 - Package Model Selector Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Mike, At today's speeds radically different packages and die will result in radically different SI and EMI behavior. As well, different die + package combinations will dissipate power generated heat radically differently. This will affect SI and EMI. I don't believe IBIS currently models this behavior. Nor are model providers competent or caring enough to include the necessary data and characterization to implement such modeling if IBIS provided for it. Further, SPICE itself is rarely implemented in a fashion that models such behavior correctly - all in one file. Thus, I believe that models should be package/die specific. But, based on evidence, you can certainly convince me otherwise. Best Regards, Roy Mike LaBonte on 10/06/2000 01:49:17 PM Sent by: Mike LaBonte To: Bob Ross cc: ibis@eda.org (Roy Leventhal/MW/US/3Com) Subject: Re: IBIS BIRD64.1 - Package Model Selector To follow up on my comments on BIRD 64.1 at the IBIS forum teleconference today, I would like to propose that: 1) The BIRD should declare scoping requirements It is not stated where the [Package Model Selector] can appear in an IBIS file, and to which [Component] it applies. We might add a paragraph like: ############################################################# Each [Package Model Selector] keyword specifies the set of package models for only one component, which is given by the previous [Component] keyword. The [Package Model Selector] keyword may not appear before the first [Component] keyword in an IBIS file. ############################################################# 2) [Package Model] and [Package Model Selector] are mutually exclusive When [Package Model Selector] is used, [Package Model] makes no sense. The [Package Model] keyword *could* give the name of the default package model, but I agree with the idea of the default as specified by the first [Package Model Selector] value. We might add a paragraph like: ############################################################# The appearance of the [Package Model Selector] keyword after a [Component] keyword overrides any [Package Model] keyword that may appear often the same [Component] keyword. ############################################################# Concerning Roy Leventhal's comment on how [Package Model Selector] might be used, I see 2 issues: A) The assignable package models must have the same pinouts. Although some die can be shipped in various packages, the physical pin arrangements are often altered to accommodate each package. The designs that incorporate these parts are routed differently. A simulation tool might not be able to iterate through the set of package models while maintaining consistency with the design at hand. A part with both plastic and ceramic packages, on the other hand, might be easily accommodated, assuming the pinouts are the same. B) A fully specified part name encompasses the package type. Some companies may have model naming policies that require model names to match manufacturer part numbers. But this makes the model package-specific. A good example is ceramic vs. plastic, where the manufacturer part numbers include different package suffixes. In fact, the design environment may count on package-specific model names, to assist with associating parts with models. In this case, "radically" different package models should not be assigned. But I don't see this as a reason to not *allow* radically different package models in a [Package Model Selector] list. Mike LaBonte Cadence Design Systems Bob Ross wrote: > > To IBIS Committee: > > Arpad Muranyi submitted BIRD 64.1 in response to a number of recent > comments including those made at the November 19, 1999 IBIS Meeting. > BIRD64.1 does not necessarily implement some of the comments. The > Analysis and Background sections have been expanded significantly and > contain some of the rationale for this revision. We expect more > discussion and debate. > > Bob Ross > Mentor Graphics > > ******************************************************************************* > ******************************************************************************* > > BIRD ID#: 64.1 > ISSUE TITLE: Package Model Selector > REQUESTER: Arpad Muranyi, Intel > DATE SUBMITTED: 10-25-99, 11-19-99 > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > > ****************************************************************************** > ****************************************************************************** > > STATEMENT OF THE ISSUE: > > The current IBIS specification (3.2) does not provide a selection mechanism > for multiple package models. This may be necessary when a certain die is > shipped in various package styles, or when the corner cases of the package > are described with different package models. > > This BIRD is written to provide an easy solution to this deficiency. This > feature will allow simulator tools to implement a user friendly package > model selection interface and/or better automation for batch and sweep > simulations. > > ****************************************************************************** > > STATEMENT OF THE RESOLVED SPECIFICATIONS: > > A new keyword shall be introduced in the IBIS specification to provide a user > friendly package model selection mechanism for components which use multiple > package models. The proposed keyword [Package Model Selector] shall contain a > list of all package model names that the simulator can pick from. The first > entry in the list is considered to be the default package model. The package > model names listed under the [Package Model Selector] must follow the rules > of the package model names associated with the [Package Model] keyword. > > To help the user of the simulator tool to make an intelligent choice, it is > highly recommended that a description be placed to the right of each package > model name in the list as a comment. > > |============================================================================= > | Keyword: [Package Model Selector] > | Required: No. > | Description: Used to select a package model from a list of package models. > | Sub-Params: None. > | Usage Rules: The [Package Model Selector] keyword can be used in place of > | the [Package Model] keyword. The only difference between the > | two keywords is that the [Package Model Selector] allows > | multiple package models to be listed. All package model names > | must appear below the [Package Model Selector] keyword. > | > | The package model names listed under the [Package Model > | Selector] must follow the rules of the package model names > | associated with the [Package Model] keyword. > | > | The first entry under the [Package Model selector] keyword > | shall be considered the default by the simulator tool. > |============================================================================= > | > [Package Model Selector] > | > 208-pin_plastic_PQFP_package-even_mode | What more can be said here? > 208-pin_plastic_PQFP_package-odd_mode | It's all in the name. > 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here. > 208-pin_ceramic_PQFP_package-odd_mode | And some more here too. > | > ****************************************************************************** > > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: > > Problem statement > > Some components are shipped in multiple package styles. Also, there are > situations when the corner cases of a package are modeled with multiple > package models. Currently, in these cases the user of the IBIS model has to > manually edit the IBIS file to change the package model name that is called by > the [Package Model] keyword in order to reference a different package model. > This makes automated simulations difficult, if not impossible. > > Possible solutions > > Add a new, simple keyword to the IBIS specification which works similar to the > already existing [Model Selector] keyword. > > ****************************************************************************** > > ANY OTHER BACKGROUND INFORMATION: > > Several IBIS model users expressed their desire in private conversations and > IBIS meetings to have such a package model selection mechanism in the IBIS > specification to make their work easier. > > An alternate syntax was suggested by Bob Ross during an EMAIL and telephone > correspondence on 10/25/99. The suggested syntax is identical to the [Model > Selector] syntax, according to which the [Package Model Selector] would be > assigned a name that is called by the (higher level) [Package Model] keyword. > However, unlike in the [Model Selector] case, there is no need for calling the > [Package Model Selector] from a higher level. This BIRD favors the simpler > vs. the more consistent approach. > > Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ., > min., and max. columns in the list of package models under the model selector > name to assist in automating the package model selection based on corner > cases. According to the exisiting rules this is not possible, becuase the > package model names are allowed to be up to 40 characters in length. Three > package model names on the same line could add up to 122 characters, which > violates the current 80 character per line rules of the IBIS specification. > > Further, package model names are allowed to include blank characters, which > requires a delimiter other than the space or tab character between the > typ., min., and max. columns. The usage of a new delimiter introduces another > inconsistency in the IBIS specification, since spaces and/or tab characters > are widely used as delimiters between columns in current IBIS versions. > > A technical dilemma regarding the automated selection of package models based > on typ., min., and max. qualifiers remains to be answered also. What do typ., > min., and max. represent? Impedance, wave velocity, trace length, or perhaps > the amount of cross talk? Simulation tool users will most likely make their > choices based on individual preferences, possibly depending on project > requirements. For this reason it seems to make more sense to give only a list > that contains all of the package models without the typ., min., and max. > qualifiers. The selection and automated usage of the various package models > should then be done through a GUI or configuration mechanisms provided by the > tool. > > The differences between the model name and package model name restrictions > required a change even in this BIRD. The description field of the [Model > Selector] keyword is separated by one or more space or tab character(s) from > the model name. However, since package model names can contain blank > characters, space or tab characters will not work as delimiters for the > description field of the [Package Model Selector] keyword. > > Since the contents of the description field is only used for informational > purposes which does not effect the simulations I decided to use the comment > character (|) as the delimiter for now. This option was actually discussed > for the [Model Selector] also but voted down for the reason that tools reading > an IBIS model have all the rights to ignore all comments, therefore a GUI > would not know how to distinguish between a legitimate descrription and a > meaningless comment. Does anyone have a better suggestion? > > ****************************************************************************** From owner-ibis Fri Oct 6 18:09:33 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9719VX18265 for ; Fri, 6 Oct 2000 18:09:32 -0700 (PDT) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id VAA26011 for ; Fri, 6 Oct 2000 21:06:32 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id VAA19822 for ; Fri, 6 Oct 2000 21:06:31 -0400 (EDT) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id SAA03521 for ; Fri, 6 Oct 2000 18:05:25 -0700 (PDT) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id SAA02521; Fri, 6 Oct 2000 18:06:19 -0700 Date: Fri, 6 Oct 2000 18:06:19 -0700 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200010070106.SAA02521@f22.innoveda.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes (10/6/00) Date: 10/6/00 SUBJECT: 10/6/00 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com Roy Leventhal* Agilent (EEsof, etc.) Mark Chang Ansoft Corporation (Eric Bracken) Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti Nikolai Bannov Cadence Design Mike LaBonte*, Todd Westerhoff, Ian Dodd*, Donald Telian, Patrick Dos Santos Cisco Systems Syed Huq, Irfan Elahi, John Fisher Compaq [Bob Haller], Peter LaFlamme, Ron Bellomio, Shafier Rahman, Doug Burns Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella, Brian Arsenault, Terry Jernberg, Alexander Nosovitski, Elena Gutman, Shan Haq Fairchild Semiconductor Craig Klem HyperLynx (& Pads Software) Matthew Flora*, [Kellee Crisafulli], (Now merged with Innoveda) Gene Garat, John Angulo*, [Al Davis], Lynne Green IBM Michael Cohen, Greg Edlund*, Jerry Hayes Innoveda (Viewlogic Systems) Chris Rokusek, Guy de Burgh*, Jun Tian, Cary Mandel, Brad Griffin, (Jon Powell) Intel Corporation Stephen Peters*, Arpad Muranyi, Will Hobbs, Richard Mellitz, Charles Phares, Meir Nakar, Sigeti Gabi, Tudor Secasiu, Dave Lorang LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross*, Tom Dagostino, Malcolm Ash, Kim Owen, Jean Oudinot, Sherif Hammad, Hazam Hegazy, Weston Beal, Ken Bakalar Micron Technology Randy Wolff*, Son Huynh* Mitsubishi Shahab Ahmed, Carleen Murphy, Scott Estrich Molex Incorporated Gus Panella Motorola Ron Werner National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Tony Sinker, Kathy Breda, Jinhua Chen Nortel Networks Steve Coe, Calvin Trowell, Hassan Ali Philips Semiconductor D.C. Sessions, Todd Andersen (& VLSI Technology) Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens AG Bernhard Unger, Gerald Bannert SiQual Scott McMorrow, Wis Macomson Texas Instruments Stephen Nolan, Ramzi Ammar, Mac McCaughey, Thomas Fisher, Jean-Claude Perrin, Jean-Yves Oberle Time Domain Analysis Systems Dima Smolyansky, Steven Corey Tyco Electronics (AMP) (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) Werner Rissiek, John Berrie OTHER PARTICIPANTS IN 2000: Actel Corp. Silvia Montoya Advansis Mikio Kiyono Aerospatiale Matra CCR Lionel Dreux, Julien Boullie Alcatel (Lannion, Bell) Daniel Peron, Steven Criel Brocade Communications Robert Badal Cereva Networks Bob Haller ECI Telecom Daniel Adar EIA Cecilia Fleming* Fraunhofer Institute Michael Kurten Jet Propulsion Lab John Treichlew KAW Shinichi Maeda Hewlett Packard Paul Gregory RCI Chris Rode Rockwell Collins Ron Hau Signals & Systems Engineering Tom Hawkins ST Micorelectronics Fabrice Boissiere, Pierre Saintot Sun Microsystems Victor Chang Thomson-CSF Savenrio Lerose, Pascal Vaslin, Thierry Zak, Sylvie Lasserre Transfer Hans Klos, Wilco Hamhuis Xilinx, Inc. Susan Wu Independent, Consultant Hideki Fukuda, Al Davis In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode October 27, 2000 (916) 356-9200 8-160059 4748326 November 17, 2000 (916) 356-9200 8-160063 1329512 December 8, 2000 (916) 356-9200 To be issued December 22, 2000 (916) 356-9200 To be issued 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 Innoveda and HyperLynx have merged. Per the precedent set by JEDEC, we will still treat them as independent companies with 2 votes for the remainder of 2000. They will continue to be listed separately. This honors the fact that HyperLynx (Pads Software) and Innoveda had purchased independent memberships for 2000 to the IBIS Open Forum. Randy Wolff and Son Huynh from Micron Technology both produce IBIS models for Micron and are interested in programs to produce more accurate models. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that Protel has purchased the ibischk3 parser license. Bob also reported that Year 2001 EIA IBIS Open Forum budgets are being proposed and reviewed by the IBIS Officers. We continue to have 34 members, but may get another one. REVIEW OF MINUTES AND AR'S The August 25, 2000 and September 14, 2000 IBIS Minutes were approved without any changes. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS PRESS AND WEB PAGE UPDATES Cecilia Fleming has fixed a bad default link on the ibis home page for http://www.eigroup.org/ibis/ Mike LaBonte has checked it out and it appears to work correctly. NEW MODELS AVAILABLE, LIBRARY UPDATE Mike Labonte updated the IBIS Model page and include a link to MMC Networks. IBIS Models are available by direct contact. One needs to contact: http://www.mmcnet.com/ to get user name and password for access. A customer supplied Mike with this link. Send reports of any new links to Mike. (His address is at the end of these Minutes.) Bob Ross reported an updated link from Lucent: http://www.lucent.com/micro/netcom/orca/s_resources/ibis.html and also some example models from UTMC Microelectronics Systems http://www.utmc.com/products/80196_examples.html OPENS FOR NEW ISSUES None. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross will work with Stephen Peters and Cecilia Fleming to help draft header information based on some updated requirements from IEC. Others are welcome to help. The IBIS officers will probably help review the information. Bob noted that we need to supply (1) a precise scope, (2) normative references, if any, (3) an Introduction covering background and future activities, and (4) and an introductory note on the cover of the FDIS simply stating that IBIS Version 2.1 is out of date and is being replaced by IBIS Version 3.2. AR - Bob Ross and Stephen Peters supply the required information to Cecilia Fleming by October 13, 2000. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross had no report and restated that he is waiting for some updated information that he can upload or distribute. - JEDEC JC-16 - Modeling and Testing - D.C. Sessions invites IBIS members to participate at the next JEDEC JC-16 and JC-42 meetings December 6-7, 2000 in Kona, Hawaii. Contact D.C. if you are interested for a Chairman's invitation at his ibis e-mail account: ibis@lumbercartel.com PCB CONFERENCE EAST IBIS SUMMIT MEETING REVIEW Bob Ross asked for comments on the recent IBIS Summit Meeting held on September 14, 2000 in Worcester, Massachusetts at the same time as the PCB Conference East. Stephen Peters felt it was a good meeting. Bob commented that we had more coverage of future topics (Connectors, IBIS Futures) than in the past, but we also had a user's perspective and a I/O Buffer Accuracy Report sample. Mike LaBonte commented that he did not sufficiently raise an issue regarding different levels of accuracy needed for different types of analysis (timing, cross-talk, etc.) that was within Roy Leventhal's presentation. This discussion could take place on the IBIS reflectors. Bob Ross reported the invoices have been sent to the four co-sponsors: Cadence, HyperLynx (now Innoveda), Mentor Graphics and North East Systems Associates (NESA). The meeting documents and presentations are now uploaded at: http://www.eda.org/pub/ibis/summits/sep00/ Roy indicated that he will supply an updated version with notes. Greg Edlund supplied an I/O Buffer Accuracy report sample (from which the presentation slides were taken). Greg plans to also supply a C utility for uploading to correlations as soon as he can take out some proprietary code. Bob expects to hold an IBIS Summit Meeting next year and will start setting the date and location as soon as he finds out the PCB Conference East details for next year. FUTURE SUMMIT PLANNING The next IBIS Summit Meeting is planned on January 29, 2000 in Santa Clara, California along with DesignCon 2001 (January 29 - February 1, 2000). Bob Ross noted that National Semiconductor is a co-sponsor of this meeting and will provide the lunch. Milt Swartz will continue to assist in the arrangements of this meeting. DesignCon is the other co-sponsor as a result of IBIS Associate Sponsorship of DesignCon 2001. The early planning has been done. We also plan to have a passive IBIS booth on the exhibit floor for literature and interaction. More activity will occur in several months. Bob is also starting to make meeting arrangements for the European IBIS Summit meeting to be held March, 2000 in Munich, Germany along with the Design Automation and Testing (DATE 2001) conference and exhibit. Bob believes that we will have co-sponsorship again from Mentor Graphics and Zuken (Incases) and invites other co-sponsors as well. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo reported that he has just received a new IBIS model for the committee to review. John also indicated that as a result of the recent merger, Innoveda now has three reviewers. Mentor and Cadence have the other reviewers. He needs some reviewers from other EDA companies. Bob Ross will work off-line to give him some possible contacts. After some discussion, we felt that it was all right for Innoveda to have several reviewers (representing Innoveda and the former HyperLynx products). The reviewers are chosen only from EDA tool vendors so that the models are reviewed and tested in a cross-section of EDA tools by people who will work with the latest releases and understand the tool issues that need to be considered. CONNECTOR PROPOSAL REVIEW (CONTINUED) Bob Ross reported that a Connector Working Group meeting was held on September 5, 2000 prepare for the IBIS Summit Meeting on September 14, 2000. No subsequent meeting was held. However the next meetings are planned on October 10 and October 17, 2000. Kellee Crisafulli will not be able to participate since he has left HyperLynx (Innoveda) and moved on to a non-EDA industrial position. We will miss his driving force and contributions, but the remaining members will try to finalize the document. Ian Dodd mentioned that there has not been much committee discussion on the pseudo-languages for automapping (Swath Matrix expansion). That should be part of the discussion for the next meeting. IBIS FUTURES (IBIS-X, API, BIRDxx) Bob Ross stated that an IBIS Futures Working Group meeting was held on September 5, 2000 to prepare for the September 14, 2000 IBIS Summit Meeting. Another meeting is scheduled on October 10, 2000. Mike LaBonte reported on the October 3, 2000 meeting. There was not much progress to report. Arpad Muranyi is on sabbatical. Al Davis is prototyping the macro language software. We did discuss issuing a BNF format. Mike also mentioned an idea of working with the Connector Specification Working Group when we consider package and internal die interconnection issues. IBISCHK3 BUG TRACKING Bob Ross reported on the ibischk3 parser development status based on a recent e-mail from Atul Agarwal. He has not done any work since finishing several BUGs several months ago. When he returns from a business trip in late October 2000, he will give an estimate on how long it will take to do the remaining BUGs. The currently outstanding BUGs are BUG36 - BUG46. One or two corrections are needed to bring ibischk3 in compliance with the the current Specification. - BUG47 - Change Waveform Mismatch Warning to Error and Warning Mike LaBonte introduced BUG47. Currently ibischk3 issues a Warning message when the V-T waveform table end points values deviate from the calculated end point values based on the I-V tables by more than 2% of the calculated range of DC end points. BUG47 keeps this check, but adds and Error message if the end point mismatch exceeds 10% (the Warning message is then not issued.) Bob Ross stated that we had already discussed this in the August 25, 2000 meeting. The value 10% was regarded as a reasonable value showing lack of correlation to justify issuing an Error versus a Warning message. Ian Dodd raised an issue that some measured lack of correlation may be based on DC measurements being done using DC methodology rather than using AC methods at the same clock frequency as the V-T measurements (such as would be caused by different internal thermal effect). This sparked some discussion. The main point, however, remains that the specification expects that the V-T tables do correlate with the I-V data. So this test remains valid. Bob classified BUG47 as Enhancement, Low and Open. Mike stated that he would also have suggested the same classification for BUG47. Bob planned to forward BUG47 to Atul for fixing. Matthew Flora commented that V-T and I-V mismatch was one of the major problems with IBIS models that are being reviewed. He suggested more descriptive Warning and Error messages because many people do not understand what this message implies. Matthew also suggested that the actual percentage mismatch be reported when this message is issued. Bob expanded that we would need two reported actual percentages for each Error or Warning for the starting voltage and ending voltage. We discussed various aspects of this issue. Bob stated that we need to agree on the amended message warnings before releasing BUG47 to Atul. Matthew and Mike should work together on this. We will plan to review the revised wording at the next IBIS meeting. AR - Matthew Flora work with Mike LaBonte to revise the message report text of BUG47. BIRD61.1 - ENHANCED CHARACTERIZATION OF RECEIVERS Not Discussed. BIRD64.1 - PACKAGE MODEL SELECTOR Bob Ross introduced BIRD64.1. It was originally issued by Arpad Muranyi in October and November 1999 and has been discussed in the past. At the August 27, 2000 meeting we ran out of time before considering it for a vote. Bob briefly outlined that BIRD64.1 introduced the [Package Model Selector] keyword under which a number of possible package names were listed. Each of these could be selected through an EDA tool interface or through scripts or programs. The main motivation for BIRD64.1 was to allow selection of package options (particularly tolerances) automatically. Currently, just loading replacement IBIS models with new packages is not considered a satisfactory option. Bob emphasized that the major reason for BIRD64.1 was to test electrical variations of package models. For example, even mode and odd mode package models give some corner cases for considering common mode and differential coupling situations and their simplified electrical characteristics. Some package tolerances also can be included. Other options were listed: Do nothing - rely on just loading in replacement models Adopt BIRD64.1 as written Adopt a convention closer to the [Model Selector] conventions (this includes two parameters and some global scoping and different syntax) Expand the [Package Model] keyword to have typ-min-max columns Bob commented that some of the other options would be difficult to implement because of some current IBIS syntax conventions. For example, model names for [Model Selector] are single-words with a maximum of 20 characters. Model names for [Define Package Model] can be multi-word names with a maximum of 40 characters. A limitation on BIRD64.1 as written is that the list of package model names do not have any electrical information concerning typ-min-max. The list can be in any order and for any number of corners. The user would have to know beforehand the ordering convention and content for each [Package Model Selector] list and program the automated application accordingly. If a typ-min-max ordering were given by another alternative above, then we would always require the typ column to comply with existing IBIS conventions for other keywords. Bob then asked for other comments prior to calling for a vote. Mike LaBonte stated BIRD64.1 did not declare the scoping requirements. It is not stated where the [Package Model Selector] can appear in an IBIS file, and to which [Component] it applies. After looking at BIRD64.1, Bob agreed with the comment. Bob indicated that he assumed that unlike [Model Selector], [Package Model Selector] was scoped with [Component] in a manner similar to [Package Model]. Bob also indicated that this change contains enough technical text to require releasing an updated BIRD64.2 before voting for approval. Roy Leventhal commented that [Package Model Selector] was not intended to support different packages. The example in BIRD64.1 shows both a set of choices for package tolerances (odd mode, even mode) and also a choice for two packages (plastic and ceramic). We did not elaborate on the choice for different packages. However one implication is that we cannot use the [Package Model Selector] to support packages with different pin numbers. Different part numbers should be used in this case consistent with different part naming conventions. Different packages with the same pin number would be permitted, but the main reason for the [Package Model Selector] keyword is to support the need for issuing tolerance variations on package models and to support automated analysis using such models. John Angulo asked whether further reflector discussion was needed because BIRD64.1 was not finalized. Bob answered yes. Roy called for a vote on whether BIRD64.1 should be rejected at this time (a possible option which would eliminate the need for any further work) - NO, or whether BIRD64.1 should be held open for further processing - YES. The vote was a unanimously YES that we should continue processing BIRD64.1. (This was NOT a vote to approve BIRD64.1.) Bob stated that we need to make the changes to BIRD64.1 and issue BIRD64.2 so we can review and vote on the actual text of the added comments. AR - The IBIS Committee (Arpad Muranyi is on sabbatical and no one else was specifically tasked to do this) to issue BIRD64.2 to address Mike LaBonte's scoping comments and to add Roy Leventhal's comments that [Package Model Selector] is not intended to be used for just package selections. 100 POINTS ISSUE Bob Ross asked Ian Dodd to issue a BIRD on this subject as an AR. AR - Ian Dodd issue a BIRD on allowing 1000 point Waveform tables. BIRD65 - C_comp REFINEMENTS Not discussed. BIRD66 - [Model Spec] Vref ADDITION Not discussed. NEXT MEETING: The next teleconference meeting will be on Friday, October 27, 2000 from 8:00 AM to 10:00 AM. BIRD64.2 is scheduled for a vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Mike LaBonte (978) 262-6496, Fax: (978) 446-6798 mikelabonte@cadence.com Senior Technologist, Cadence Design Systems 270 Billerica Road Chelmsford, MA 01824 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 angulo@hyperlynx.com Development Engineer, HyperLynx, Inc. 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Sat Oct 7 19:58:40 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e982wdX22408 for ; Sat, 7 Oct 2000 19:58:40 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id TAA11517; Sat, 7 Oct 2000 19:55:43 -0700 (PDT) Received: from cadence.com (ch-5300-28 [158.140.101.28]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id WAA29145; Sat, 7 Oct 2000 22:55:39 -0400 (EDT) Message-ID: <39DFE22A.FA810EC0@cadence.com> Date: Sat, 07 Oct 2000 22:55:38 -0400 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Roy Leventhal CC: ibis@eda.org Subject: Re: IBIS BIRD64.1 - Package Model Selector References: <80256970.007AD3B8.00@notesmta.eur.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as TAA11517 at Sat Oct 7 19:55:43 2000 Roy, Good point about the choice of package affecting die operation due to different thermal characteristics. I'm convinced - we probably should not encourage use of [Package Model Selector] for uses other than to cover variations of the same package. Mike Roy Leventhal wrote: > > Mike, > > At today's speeds radically different packages and die will result in radically > different SI and EMI behavior. As well, different die + package combinations > will dissipate power generated heat radically differently. This will affect SI > and EMI. > > I don't believe IBIS currently models this behavior. Nor are model providers > competent or caring enough to include the necessary data and characterization to > implement such modeling if IBIS provided for it. Further, SPICE itself is rarely > implemented in a fashion that models such behavior correctly - all in one file. > > Thus, I believe that models should be package/die specific. > > But, based on evidence, you can certainly convince me otherwise. > > Best Regards, > > Roy > > Mike LaBonte on 10/06/2000 01:49:17 PM > > Sent by: Mike LaBonte > > To: Bob Ross > cc: ibis@eda.org (Roy Leventhal/MW/US/3Com) > Subject: Re: IBIS BIRD64.1 - Package Model Selector > > To follow up on my comments on BIRD 64.1 at the IBIS forum > teleconference today, I would like to propose that: > > 1) The BIRD should declare scoping requirements > It is not stated where the [Package Model Selector] can appear > in an IBIS file, and to which [Component] it applies. We might > add a paragraph like: > > ############################################################# > Each [Package Model Selector] keyword specifies the set of > package models for only one component, which is given by > the previous [Component] keyword. The [Package Model Selector] > keyword may not appear before the first [Component] keyword > in an IBIS file. > ############################################################# > > 2) [Package Model] and [Package Model Selector] are mutually exclusive > When [Package Model Selector] is used, [Package Model] makes > no sense. The [Package Model] keyword *could* give the name of > the default package model, but I agree with the idea of the > default as specified by the first [Package Model Selector] value. > We might add a paragraph like: > > ############################################################# > The appearance of the [Package Model Selector] keyword after > a [Component] keyword overrides any [Package Model] keyword > that may appear often the same [Component] keyword. > ############################################################# > > Concerning Roy Leventhal's comment on how [Package Model Selector] > might be used, I see 2 issues: > > A) The assignable package models must have the same pinouts. > Although some die can be shipped in various packages, the physical > pin arrangements are often altered to accommodate each package. > The designs that incorporate these parts are routed differently. > A simulation tool might not be able to iterate through the > set of package models while maintaining consistency with the > design at hand. A part with both plastic and ceramic packages, > on the other hand, might be easily accommodated, assuming the > pinouts are the same. > > B) A fully specified part name encompasses the package type. > Some companies may have model naming policies that require > model names to match manufacturer part numbers. But this > makes the model package-specific. A good example is ceramic > vs. plastic, where the manufacturer part numbers include > different package suffixes. In fact, the design environment > may count on package-specific model names, to assist with > associating parts with models. In this case, "radically" > different package models should not be assigned. But I don't > see this as a reason to not *allow* radically different package > models in a [Package Model Selector] list. > > Mike LaBonte > Cadence Design Systems > > Bob Ross wrote: > > > > To IBIS Committee: > > > > Arpad Muranyi submitted BIRD 64.1 in response to a number of recent > > comments including those made at the November 19, 1999 IBIS Meeting. > > BIRD64.1 does not necessarily implement some of the comments. The > > Analysis and Background sections have been expanded significantly and > > contain some of the rationale for this revision. We expect more > > discussion and debate. > > > > Bob Ross > > Mentor Graphics > > > > > ******************************************************************************* > > > ******************************************************************************* > > > > BIRD ID#: 64.1 > > ISSUE TITLE: Package Model Selector > > REQUESTER: Arpad Muranyi, Intel > > DATE SUBMITTED: 10-25-99, 11-19-99 > > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > > > > ****************************************************************************** > > ****************************************************************************** > > > > STATEMENT OF THE ISSUE: > > > > The current IBIS specification (3.2) does not provide a selection mechanism > > for multiple package models. This may be necessary when a certain die is > > shipped in various package styles, or when the corner cases of the package > > are described with different package models. > > > > This BIRD is written to provide an easy solution to this deficiency. This > > feature will allow simulator tools to implement a user friendly package > > model selection interface and/or better automation for batch and sweep > > simulations. > > > > ****************************************************************************** > > > > STATEMENT OF THE RESOLVED SPECIFICATIONS: > > > > A new keyword shall be introduced in the IBIS specification to provide a user > > friendly package model selection mechanism for components which use multiple > > package models. The proposed keyword [Package Model Selector] shall contain a > > list of all package model names that the simulator can pick from. The first > > entry in the list is considered to be the default package model. The package > > model names listed under the [Package Model Selector] must follow the rules > > of the package model names associated with the [Package Model] keyword. > > > > To help the user of the simulator tool to make an intelligent choice, it is > > highly recommended that a description be placed to the right of each package > > model name in the list as a comment. > > > > |============================================================================= > > | Keyword: [Package Model Selector] > > | Required: No. > > | Description: Used to select a package model from a list of package models. > > | Sub-Params: None. > > | Usage Rules: The [Package Model Selector] keyword can be used in place of > > | the [Package Model] keyword. The only difference between the > > | two keywords is that the [Package Model Selector] allows > > | multiple package models to be listed. All package model names > > | must appear below the [Package Model Selector] keyword. > > | > > | The package model names listed under the [Package Model > > | Selector] must follow the rules of the package model names > > | associated with the [Package Model] keyword. > > | > > | The first entry under the [Package Model selector] keyword > > | shall be considered the default by the simulator tool. > > |============================================================================= > > | > > [Package Model Selector] > > | > > 208-pin_plastic_PQFP_package-even_mode | What more can be said here? > > 208-pin_plastic_PQFP_package-odd_mode | It's all in the name. > > 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here. > > 208-pin_ceramic_PQFP_package-odd_mode | And some more here too. > > | > > ****************************************************************************** > > > > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: > > > > Problem statement > > > > Some components are shipped in multiple package styles. Also, there are > > situations when the corner cases of a package are modeled with multiple > > package models. Currently, in these cases the user of the IBIS model has to > > manually edit the IBIS file to change the package model name that is called by > > the [Package Model] keyword in order to reference a different package model. > > This makes automated simulations difficult, if not impossible. > > > > Possible solutions > > > > Add a new, simple keyword to the IBIS specification which works similar to the > > already existing [Model Selector] keyword. > > > > ****************************************************************************** > > > > ANY OTHER BACKGROUND INFORMATION: > > > > Several IBIS model users expressed their desire in private conversations and > > IBIS meetings to have such a package model selection mechanism in the IBIS > > specification to make their work easier. > > > > An alternate syntax was suggested by Bob Ross during an EMAIL and telephone > > correspondence on 10/25/99. The suggested syntax is identical to the [Model > > Selector] syntax, according to which the [Package Model Selector] would be > > assigned a name that is called by the (higher level) [Package Model] keyword. > > However, unlike in the [Model Selector] case, there is no need for calling the > > [Package Model Selector] from a higher level. This BIRD favors the simpler > > vs. the more consistent approach. > > > > Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ., > > min., and max. columns in the list of package models under the model selector > > name to assist in automating the package model selection based on corner > > cases. According to the exisiting rules this is not possible, becuase the > > package model names are allowed to be up to 40 characters in length. Three > > package model names on the same line could add up to 122 characters, which > > violates the current 80 character per line rules of the IBIS specification. > > > > Further, package model names are allowed to include blank characters, which > > requires a delimiter other than the space or tab character between the > > typ., min., and max. columns. The usage of a new delimiter introduces another > > inconsistency in the IBIS specification, since spaces and/or tab characters > > are widely used as delimiters between columns in current IBIS versions. > > > > A technical dilemma regarding the automated selection of package models based > > on typ., min., and max. qualifiers remains to be answered also. What do typ., > > min., and max. represent? Impedance, wave velocity, trace length, or perhaps > > the amount of cross talk? Simulation tool users will most likely make their > > choices based on individual preferences, possibly depending on project > > requirements. For this reason it seems to make more sense to give only a list > > that contains all of the package models without the typ., min., and max. > > qualifiers. The selection and automated usage of the various package models > > should then be done through a GUI or configuration mechanisms provided by the > > tool. > > > > The differences between the model name and package model name restrictions > > required a change even in this BIRD. The description field of the [Model > > Selector] keyword is separated by one or more space or tab character(s) from > > the model name. However, since package model names can contain blank > > characters, space or tab characters will not work as delimiters for the > > description field of the [Package Model Selector] keyword. > > > > Since the contents of the description field is only used for informational > > purposes which does not effect the simulations I decided to use the comment > > character (|) as the delimiter for now. This option was actually discussed > > for the [Model Selector] also but voted down for the reason that tools reading > > an IBIS model have all the rights to ignore all comments, therefore a GUI > > would not know how to distinguish between a legitimate descrription and a > > meaningless comment. Does anyone have a better suggestion? > > > > ****************************************************************************** From owner-ibis Sun Oct 8 22:45:24 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e995jMX27863 for ; Sun, 8 Oct 2000 22:45:23 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id WAA22457 for ; Sun, 8 Oct 2000 22:39:36 -0700 (PDT) Received: from cadence.com (ch-5300-83 [158.140.101.83]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id BAA07845 for ; Mon, 9 Oct 2000 01:39:33 -0400 (EDT) Message-ID: <39E15A10.1BE5A190@cadence.com> Date: Mon, 09 Oct 2000 01:39:28 -0400 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: BIRD64.2 - Package Model Selector Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as WAA22457 at Sun Oct 8 22:39:36 2000 Here is a draft for BIRD64.2, with scoping and exclusivity requirements added. It also has a minor change intended to convey Roy Leventhal's suggestion that [Package Model Selector] should not be used to mix and match different package types. Mike ******************************************************************************* ******************************************************************************* BIRD ID#: 64.2 ISSUE TITLE: Package Model Selector REQUESTER: Arpad Muranyi, Intel; Mike LaBonte, Cadence DATE SUBMITTED: 10-25-99, 11-19-99, 10-8-2000 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current IBIS specification (3.2) does not provide a selection mechanism for multiple package models. This may be necessary when a certain die is shipped in various package styles, or when the corner cases of the package are described with different package models. This BIRD is written to provide an easy solution to this deficiency. This feature will allow simulator tools to implement a user friendly package model selection interface and/or better automation for batch and sweep simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword shall be introduced in the IBIS specification to provide a user friendly package model selection mechanism for components which use multiple package models. The proposed keyword [Package Model Selector] shall contain a list of all package model names that the simulator can pick from. The first entry in the list is considered to be the default package model. The package model names listed under the [Package Model Selector] must follow the rules of the package model names associated with the [Package Model] keyword. To help the user of the simulator tool to make an intelligent choice, it is highly recommended that a description be placed to the right of each package model name in the list as a comment. |============================================================================= | Keyword: [Package Model Selector] | Required: No. | Description: Used to select a package model from a list of package models. | Sub-Params: None. | Usage Rules: The [Package Model Selector] keyword can be used in place of | the [Package Model] keyword. The only difference between the | two keywords is that the [Package Model Selector] allows | multiple models to be listed for a package. A component may | not have both a [Package Model Selector] keyword and a | [Package Model] keyword. | | Each [Package Model Selector] keyword specifies the set of | package models for only one component, which is given by | the previous [Component] keyword. The [Package Model Selector] | keyword may not appear before the first [Component] keyword | in an IBIS file.| | | All package model names must appear below the [Package Model | Selector] keyword. The package model names listed under the | [Package Model Selector] must follow the rules of the package | model names associated with the [Package Model] keyword. | | The first entry under the [Package Model selector] keyword | shall be considered the default by the simulator tool. |============================================================================= | [Package Model Selector] | 208-pin_plastic_PQFP_package-even_mode | What more can be said here? 208-pin_plastic_PQFP_package-odd_mode | It's all in the name. 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here. 208-pin_ceramic_PQFP_package-odd_mode | And some more here too. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Problem statement Some components are shipped in multiple package styles. Also, there are situations when the corner cases of a package are modeled with multiple package models. Currently, in these cases the user of the IBIS model has to manually edit the IBIS file to change the package model name that is called by the [Package Model] keyword in order to reference a different package model. This makes automated simulations difficult, if not impossible. Possible solutions Add a new, simple keyword to the IBIS specification which works similar to the already existing [Model Selector] keyword. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Several IBIS model users expressed their desire in private conversations and IBIS meetings to have such a package model selection mechanism in the IBIS specification to make their work easier. An alternate syntax was suggested by Bob Ross during an EMAIL and telephone correspondence on 10/25/99. The suggested syntax is identical to the [Model Selector] syntax, according to which the [Package Model Selector] would be assigned a name that is called by the (higher level) [Package Model] keyword. However, unlike in the [Model Selector] case, there is no need for calling the [Package Model Selector] from a higher level. This BIRD favors the simpler vs. the more consistent approach. Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ., min., and max. columns in the list of package models under the model selector name to assist in automating the package model selection based on corner cases. According to the exisiting rules this is not possible, becuase the package model names are allowed to be up to 40 characters in length. Three package model names on the same line could add up to 122 characters, which violates the current 80 character per line rules of the IBIS specification. Further, package model names are allowed to include blank characters, which requires a delimiter other than the space or tab character between the typ., min., and max. columns. The usage of a new delimiter introduces another inconsistency in the IBIS specification, since spaces and/or tab characters are widely used as delimiters between columns in current IBIS versions. A technical dilemma regarding the automated selection of package models based on typ., min., and max. qualifiers remains to be answered also. What do typ., min., and max. represent? Impedance, wave velocity, trace length, or perhaps the amount of cross talk? Simulation tool users will most likely make their choices based on individual preferences, possibly depending on project requirements. For this reason it seems to make more sense to give only a list that contains all of the package models without the typ., min., and max. qualifiers. The selection and automated usage of the various package models should then be done through a GUI or configuration mechanisms provided by the tool. The differences between the model name and package model name restrictions required a change even in this BIRD. The description field of the [Model Selector] keyword is separated by one or more space or tab character(s) from the model name. However, since package model names can contain blank characters, space or tab characters will not work as delimiters for the description field of the [Package Model Selector] keyword. Since the contents of the description field is only used for informational purposes which does not effect the simulations I decided to use the comment character (|) as the delimiter for now. This option was actually discussed for the [Model Selector] also but voted down for the reason that tools reading an IBIS model have all the rights to ignore all comments, therefore a GUI would not know how to distinguish between a legitimate descrription and a meaningless comment. Does anyone have a better suggestion? Revision 64.2 changes 10-8-2000, Mike LaBonte: Added scoping requirements and mutually exclusive relationship with [Package Model]. Changed wording "... allows multiple package models to be listed" to "... allows multiple models to be listed for a package". The new phrasing implies that [Package Model Selector] should be used to specifiy multiple models for one package, not models for multiple packages. It might be inappropriate to place package models with different pin assignments, thermal characteristics, etc. on a [Package Model Selector] list, since these variations would normally require changes to other elements of the component model. ****************************************************************************** From owner-ibis Fri Oct 20 15:33:07 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9KMX5X01008 for ; Fri, 20 Oct 2000 15:33:06 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA04038; Fri, 20 Oct 2000 15:29:58 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA17752; Fri, 20 Oct 2000 15:29:56 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39F0C765.59D6B417@mentor.com> Date: Fri, 20 Oct 2000 15:29:57 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Agenda 10/27/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 10/27/00 Bridge Number Reservation # Passcode (916) 356-9200 8-160059 4748326 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update LaBonte, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin/Ross - JEDEC JC-16 Modeling and Testing Sessions Future Summit Planning Ross IBIS Model Review Committee Angulo New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella IBIS Futures Group Report (IBIS-X, API, BIRDxx) LaBonte ibischk3 Bug Tracking Ross - BUG47 Change Waveform Mismatch Warning to Error LaBonte and Warning BIRD61.1 - Enhanced Characterization of Receivers Ross BIRD64.2 - Package Model Selector (Vote) LaBonte/Cohen BIRD65 - C_comp Refinements Ross BIRD66 - [Model Spec] Vref Addition Ross 100 Points Issue Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Tue Oct 24 13:54:41 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9OKsaX20108 for ; Tue, 24 Oct 2000 13:54:40 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA22743; Tue, 24 Oct 2000 13:51:28 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA17537; Tue, 24 Oct 2000 13:51:25 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39F5F64B.D6B0D9CE@mentor.com> Date: Tue, 24 Oct 2000 13:51:23 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD67 - Increase V-T Table 100 Point Limit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: BIRD67 is proposed to resolve the long-standing 100 point limitation issue on V-T tables by allowing up to 1000 points. Bob Ross Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 67 ISSUE TITLE: Increase V-T Table 100 Point Limit REQUESTER: Bob Ross, Mentor Graphics, Ian Dodd, Cadence DATE SUBMITTED: October 24, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The 100 point limitation on V-T tables is too limiting because of increased accuracy needs and the fact that the available point may have to be distributed among the typ, min, and max columns. A 1000 point limit is proposed. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: In the following keyword, the value 100 is replaced by 1000 on the line designated by |* |============================================================================= | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge waveforms | of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, C_fixture, | L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that describe | the shape of an output waveform. These time/voltage points | are taken under the conditions specified in the | R/L/C/V_fixture and R/L/C_dut subparameters. The table itself | consists of one column of time points, then three columns of | voltage points in the standard typ, min, and max format. The | four entries must be placed on a single line and must be | separated by at least one white space. All four columns are | required. However, data is only required in the typical | column. If minimum or maximum data is not available, use the | reserved word "NA". The first value in the time column need | not be '0'. Time values must increase as one parses down the |* table. The waveform table can contain a maximum of 1000 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backward compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; i.e., the | first entry (or entries) in a voltage column must be the DC | voltage of the output before switching and the last entry (or | entries) of the column must be the final DC value of the | output after switching. Each table must contain at least two | entries. Thus, numerical values are required for the first | and last entries of any column containing numerical data. | | A [Model] specification can contain more than one rising edge | or falling edge waveform table. However, each new table must | begin with the appropriate keyword and subparameter list as | shown below. If more than one rising or falling edge waveform | table is present, then the data in each of the respective | tables must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a common | reference point on the input stimulus waveform. | | The 'fixture' subparameters specify the loading conditions | under which the waveform is taken. The R_dut, C_dut, and | L_dut subparameters are analogous to the package parameters | R_pkg, C_pkg, and L_pkg and are used if the waveform includes | the effects of pin inductance/capacitance. The diagram below | shows the interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | NOTE: The use of L_dut, R_dut, and C_dut is strongly | discouraged in developing Waveform data from simulation | models. Some simulators may ignore these parameters because | they may introduce numerical time constant artifacts. | | Only the R_fixture and V_fixture subparameters are required, | the rest of the subparameters are optional. If a subparameter | is not used, its value defaults to zero. The subparameters | must appear in the text after the keyword and before the first | row of the waveform table. | | V_fixture defines the voltage for typ, min, and max supply | conditions. However, when the fixture voltage is related to | the power supply voltages, then the subparameters | V_fixture_min and V_fixture_max can be used to further specify | the fixture voltage for min and max supply voltages. | | NOTE: Test fixtures with R_fixture and V_fixture, | V_fixture_min, and V_fixture_max only are strongly encouraged | because they provide the BEST set of data needed to produce | the best model for simulation. C_fixture and L_fixture can be | used to produce waveforms which describe the typical test case | setups for reference. | | NOTE: In most cases two [Rising Waveform] tables and two | [Falling Waveform] tables will be necessary for accurate | modeling. | | All tables assume that the die capacitance is included. | Potential numerical problems associated with processing the | data using the effective C_comp for effective die capacitance | may be handled differently among simulators. |----------------------------------------------------------------------------- [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This topic has been discussed at several IBIS Meeting and on e-mail. BIRD67 complies with the action item to propose a correction to the 100 point limit problem on V-T tables. There now exists both the requirement that V-T tables have high resolution for accuracy and also extend to a time where the DC value reaches the correct DC final value. A further requirement is that the high resolution exists on all columns - typ, min, and max. However, often the waveforms for min and max columns are both delayed differently and have their sharpest transition points distributed at different time values from each other and from the typ column points. Since the time points are all referenced to the same time axis for all columns, the selection of actual time values for best accuracy might be different for each column. A worst case scenerio would have approximately 33 selected time points available for each column. This provides too low of a resolution needed for some of the higher speed devices and for some corresponding accuracy requirements. This issue is further confused by whether NA entries in a particular column count as one of the maximum 100 entries in that column. The worst case interpretation is that it does. Also ibischk3 enforces this limitation regardless of contents of any column. Often tools used to generate V-T tables use constant time steps. This often provides conflicting delta time requirements: small enough for the necessary resolution for the fastest responses, and large enough so that the final DC value is reached for the slowest response using 100 points or less. More complicated optimal distribution of points may be the only solution. With more allowable points even the simplier constant delta time tables can be provided. BIRD67 simply increases the maximum value allowed to 1000. We still want to provide a limit to prevent vendors from providing unnecessarily large amounts of V-T data. At this time we feel that 1000 points is more than adequate. BIRD67 retains the 100 point limit for all other tables. The 100 point limit is still reasonable for these situations. Having a common limit of 1000 would also be attractive for consistency, but this would also encourage producing needlessly large files. An older BIRD17 had proposed raising the limit to 151 for greater resolution and to allow even distribution of some I-V data based on 5 V technology. BIRD17 was rejected. One reason was that a common tool at that time had a limit of 100 points when processing table based VCCS and VCVS functions - a key element in processing IBIS models. The need to be compatible with this tool still exists, but the need for greater resolution also exists. The burden now shifts to the specific tool - either it must change its limits or else provide the filtering algorithm to do the best selection of data points. Most other tools do not have such a 100 point restriction. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Tue Oct 24 13:58:08 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9OKw6X20131 for ; Tue, 24 Oct 2000 13:58:07 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA23161; Tue, 24 Oct 2000 13:54:58 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA18125; Tue, 24 Oct 2000 13:54:57 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39F5F720.17A3A450@mentor.com> Date: Tue, 24 Oct 2000 13:54:56 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: BIRD68 by David Lorang is issued for clarification. Bob Ross Mentor Graphics ****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 68 ISSUE TITLE: Clarify that Rising and Falling Waveforms Should be Correlated REQUESTOR: David Lorang, Intel DATE SUBMITTED: October 24, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Rising waveform data should be correlated with falling waveform data to help simulators provide accurate duty cycles for their output waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Add the following new paragraph to the [Rising Waveform], [Falling Waveform] Keywords in Section 6 before the paragraph that starts with, "A [Model] specification can contain more that one rising edge...": | The data in all of the waveform tables should be time | correlated. In other words, the edge data in each of the | tables (rising and falling) should be entered with respect to | a point in time when the input stimulus is assumed to have | initiated a logic transition. The first line in each | waveform table should be assumed to be the reference point in | time corresponding to a logic transition. For example, | assume that some internal rising edge logic transition starts | at time = 0. Then a rising edge voltage-time table might be | created starting at time zero. The first several table | entries might be some "lead-in" time caused by some undefined | internal buffer delay before the voltage actually starts | transitioning. The falling edge stimulus--for the purpose of | setting reference time for the voltage-time curve--should also | start at time = 0. And, the falling edge voltage-time table | would be created starting at time zero with a possibly | different amount of "lead-in" time caused by a possibly | different--but corresponding--falling edge internal buffer | delay. Any actual device differences in internal buffer | delay time between rising and falling edges should appear as | differing lead-in times between the rising and the falling | waveforms in the tables just as any differences in actual | device rise and fall times appear as differing voltage-time | entries in the tables. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This change is necessary because errors in the relationship between rising and falling edges cause duty cycle distortion in the simulated waveform. Preserving the timing relationship between rising and falling edge timing is important due to the effects of inter-symbol interference (ISI). Intersymbol interference can be thought of as the effect of the previous edge (and in fact edges before that) on the signal quality of the current edge of a signal. If the timing between a previous and current edge is in error, then the ISI effect will be inaccurate also. Note that an I/O buffer specification characterizes the shape of a buffers output waveform and does not and usually cannot, determine the internal delay of that buffer. It is the duty of a component data sheet to express the timing relationships between its various I/O pins. But the timing relationship between an output buffer's own rising and falling edges is characterization of that output buffer and does fall within the realm of the buffer's specification, and thus that timingrelationship should be preserved, if possible. The specification makes it clear that multiple waveforms for a given signal edge should be time correlated, but it does not specifically state that correlation should also be maintained between rising and falling edges. Consider the following example: A buffer has the following measured Tco (Time Clock-to-output) values. Tco (rising edge): 2ns Tco (falling edge): 3ns Suppose that we have measured waveforms as shown in the timing diagram below. 0ns 10ns 20ns | | | ___________________ ____________________ | | | | | | | | CLK | |___________________| | ___________________ _________________ / \ / / \ / OUTPUT __/ \_______________/ |<->| TcoR = 2ns |<-->| TcoR = 3ns Although IBIS modeling does not deal with Tco directly, it does model the shapes of the waveforms. For the measured information above, an IBIS model might be created to provide the following rising and falling waveforms: Vfinal ___ ___ / / Rising / / / Vinitial ___ / Vinitial ___ \ \ Falling \ \ \ Vfinal ___ \___ | | | T=0 T=2 T=3 (ns) And if so, although the waveforms are the correct shape, a time domain simulation would provide erroneous and misleading results: 0ns 10ns 20ns | | | ___________________ ____________________ | | | | | | | | CLK | |___________________| | ___________________ _________________ / \ / Original OUTPUT / \ / __/ \_______________/ |<->| TcoR = 2ns |<-->| TcoF = 3ns ________________ _________________ / \ / Simulated OUTPUT / \ / / \_________________/ |-| TcoR = 1ns |-| TcoF = 1ns The timing diagram shows that the delay from clock to output has changed--and that is OK because IBIS is not intended to specify that. The problem is that the rising and falling edges have changed by different amounts causing duty cycle distortion of the simulated waveform. A better handling of this situation would have the rising and falling waveforms correlated so that for our example the IBIS V-T models would look like this: Vfinal ___ ___ / / Rising / / / Vinitial ___ / Vinitial ___ ___ \ \ Falling \ \ \ Vfinal ___ \___ | | | | T=0 T=1 T=2 T=3 (ns) With these waveforms when a time domain simulation is run, the waveform would still have a different Tco than the original measurement, but because the rising and falling edges are correlated, the output signal shape is accurate (i.e. the simulated waveform no longer has the duty cycle distortion.) 0ns 10ns 20ns | | | ___________________ ____________________ | | | | | | | | CLK | |___________________| | ___________________ _________________ / \ / Original OUTPUT / \ / __/ \_______________/ |<->| TcoR = 2ns |<-->| TcoF = 3ns ___________________ _________________ / \ / Simulated OUTPUT/ \ / / \______________/ |-| TcoR = 1ns |<->| TcoF = 2ns In summary, the IBIS specification should maintain correlation between all rising and falling waveforms to enable simulators that use the IBIS data to provide accurate results. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From owner-ibis Thu Oct 26 05:26:31 2000 Received: from geneva.cereva.com (fwuser@ip03.datx.com [209.213.90.252]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9QCQSX28882 for ; Thu, 26 Oct 2000 05:26:30 -0700 (PDT) Message-ID: <3D60630D3600D411896F0090278D4E48A89A44@spawn.cereva.com> From: "Haller, Robert" To: "'Bob Ross'" , ibis@eda.org Subject: RE: IBIS BIRD67 - Increase V-T Table 100 Point Limit Date: Thu, 26 Oct 2000 08:24:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bob R. and Ian, Nice to see this bird, but I have a question/issue. I agree that 100 point V-T curve limit is often insufficient because of increased accuracy requirements. I believe the bird falls short (IMHO) by not relaxing the 100 point limit in the I-V curves also. The same argument you give for increasing the number of points in the V-T curves also exist for I-V curves. In the past, I discussed this issue with other model creators, and they too have run into cases where they could not accurately include all of the "I" points needed for min typ max because of the common "V" axis. One example is when I created then correlated models for HSTL devices designed with on chip parallel termination. Very small changes in I result in significant changes in V. If you don't nail the exact operating points with enough I-V points you obtain DC offsets in your resultant output waveforms. I would strongly suggest while modifying 100 -> 1000 point change to the V-T curves we should also relax that restriction on the I-V from 100->1000. We should be proactive, If additional points are not required they don't have to be used, but if more points are needed the limitation is not in the specification. regards, Bob H. Cereva Networks 3 Network Drive Marlboro MA. 01752 Phone: 508-486-9660 X 3365 FAX: 508-486-9661 Email: rhaller@cereva.com -----Original Message----- From: Bob Ross [mailto:bob_ross@mentorg.com] Sent: Tuesday, October 24, 2000 4:51 PM To: ibis@eda.org Subject: IBIS BIRD67 - Increase V-T Table 100 Point Limit To All: BIRD67 is proposed to resolve the long-standing 100 point limitation issue on V-T tables by allowing up to 1000 points. Bob Ross Mentor Graphics **************************************************************************** ** **************************************************************************** ** BIRD ID#: 67 ISSUE TITLE: Increase V-T Table 100 Point Limit REQUESTER: Bob Ross, Mentor Graphics, Ian Dodd, Cadence DATE SUBMITTED: October 24, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The 100 point limitation on V-T tables is too limiting because of increased accuracy needs and the fact that the available point may have to be distributed among the typ, min, and max columns. A 1000 point limit is proposed. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: In the following keyword, the value 100 is replaced by 1000 on the line designated by |* |=========================================================================== == | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge waveforms | of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, C_fixture, | L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that describe | the shape of an output waveform. These time/voltage points | are taken under the conditions specified in the | R/L/C/V_fixture and R/L/C_dut subparameters. The table itself | consists of one column of time points, then three columns of | voltage points in the standard typ, min, and max format. The | four entries must be placed on a single line and must be | separated by at least one white space. All four columns are | required. However, data is only required in the typical | column. If minimum or maximum data is not available, use the | reserved word "NA". The first value in the time column need | not be '0'. Time values must increase as one parses down the |* table. The waveform table can contain a maximum of 1000 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backward compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; i.e., the | first entry (or entries) in a voltage column must be the DC | voltage of the output before switching and the last entry (or | entries) of the column must be the final DC value of the | output after switching. Each table must contain at least two | entries. Thus, numerical values are required for the first | and last entries of any column containing numerical data. | | A [Model] specification can contain more than one rising edge | or falling edge waveform table. However, each new table must | begin with the appropriate keyword and subparameter list as | shown below. If more than one rising or falling edge waveform | table is present, then the data in each of the respective | tables must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a common | reference point on the input stimulus waveform. | | The 'fixture' subparameters specify the loading conditions | under which the waveform is taken. The R_dut, C_dut, and | L_dut subparameters are analogous to the package parameters | R_pkg, C_pkg, and L_pkg and are used if the waveform includes | the effects of pin inductance/capacitance. The diagram below | shows the interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | NOTE: The use of L_dut, R_dut, and C_dut is strongly | discouraged in developing Waveform data from simulation | models. Some simulators may ignore these parameters because | they may introduce numerical time constant artifacts. | | Only the R_fixture and V_fixture subparameters are required, | the rest of the subparameters are optional. If a subparameter | is not used, its value defaults to zero. The subparameters | must appear in the text after the keyword and before the first | row of the waveform table. | | V_fixture defines the voltage for typ, min, and max supply | conditions. However, when the fixture voltage is related to | the power supply voltages, then the subparameters | V_fixture_min and V_fixture_max can be used to further specify | the fixture voltage for min and max supply voltages. | | NOTE: Test fixtures with R_fixture and V_fixture, | V_fixture_min, and V_fixture_max only are strongly encouraged | because they provide the BEST set of data needed to produce | the best model for simulation. C_fixture and L_fixture can be | used to produce waveforms which describe the typical test case | setups for reference. | | NOTE: In most cases two [Rising Waveform] tables and two | [Falling Waveform] tables will be necessary for accurate | modeling. | | All tables assume that the die capacitance is included. | Potential numerical problems associated with processing the | data using the effective C_comp for effective die capacitance | may be handled differently among simulators. |--------------------------------------------------------------------------- -- [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This topic has been discussed at several IBIS Meeting and on e-mail. BIRD67 complies with the action item to propose a correction to the 100 point limit problem on V-T tables. There now exists both the requirement that V-T tables have high resolution for accuracy and also extend to a time where the DC value reaches the correct DC final value. A further requirement is that the high resolution exists on all columns - typ, min, and max. However, often the waveforms for min and max columns are both delayed differently and have their sharpest transition points distributed at different time values from each other and from the typ column points. Since the time points are all referenced to the same time axis for all columns, the selection of actual time values for best accuracy might be different for each column. A worst case scenerio would have approximately 33 selected time points available for each column. This provides too low of a resolution needed for some of the higher speed devices and for some corresponding accuracy requirements. This issue is further confused by whether NA entries in a particular column count as one of the maximum 100 entries in that column. The worst case interpretation is that it does. Also ibischk3 enforces this limitation regardless of contents of any column. Often tools used to generate V-T tables use constant time steps. This often provides conflicting delta time requirements: small enough for the necessary resolution for the fastest responses, and large enough so that the final DC value is reached for the slowest response using 100 points or less. More complicated optimal distribution of points may be the only solution. With more allowable points even the simplier constant delta time tables can be provided. BIRD67 simply increases the maximum value allowed to 1000. We still want to provide a limit to prevent vendors from providing unnecessarily large amounts of V-T data. At this time we feel that 1000 points is more than adequate. BIRD67 retains the 100 point limit for all other tables. The 100 point limit is still reasonable for these situations. Having a common limit of 1000 would also be attractive for consistency, but this would also encourage producing needlessly large files. An older BIRD17 had proposed raising the limit to 151 for greater resolution and to allow even distribution of some I-V data based on 5 V technology. BIRD17 was rejected. One reason was that a common tool at that time had a limit of 100 points when processing table based VCCS and VCVS functions - a key element in processing IBIS models. The need to be compatible with this tool still exists, but the need for greater resolution also exists. The burden now shifts to the specific tool - either it must change its limits or else provide the filtering algorithm to do the best selection of data points. Most other tools do not have such a 100 point restriction. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: **************************************************************************** ** From owner-ibis Thu Oct 26 09:31:28 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9QGVOX00099 for ; Thu, 26 Oct 2000 09:31:27 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA19981; Thu, 26 Oct 2000 09:28:15 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA27874; Thu, 26 Oct 2000 09:28:14 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39F85B9C.23CE38F8@mentor.com> Date: Thu, 26 Oct 2000 09:28:12 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Haller, Robert" CC: "'Bob Ross'" , ibis@eda.org Subject: Re: IBIS BIRD67 - Increase V-T Table 100 Point Limit References: <3D60630D3600D411896F0090278D4E48A89A44@spawn.cereva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob: We will introduce BIRD67 and discuss it at the Meeting on Friday, October 27,2000. Your points will be discussed at that time. They are valid based on the fact that the original limits were never expected to compromise model accuracy. Another point expressed privately will also be raised. It is whether the limit should be 1001 to allow "nice" begining and end points on V-T tables along with "nice" spacing values. For example, 1001 table entries spanning 0nS to 10.00nS with 10pS spacing. Bob Ross Mentor Graphics "Haller, Robert" wrote: > > Bob R. and Ian, > Nice to see this bird, but I have a question/issue. > I agree that 100 point V-T curve limit is often insufficient because of > increased accuracy requirements. I believe the bird falls short (IMHO) by > not relaxing the 100 point limit in the I-V curves also. > > The same argument you give for increasing the number of points in the V-T > curves also exist for I-V curves. In the past, I discussed this issue with > other model creators, and they too have run into cases where they could not > accurately include all of the "I" points needed for min typ max because > of the common "V" axis. One example is when I created then correlated models > > for HSTL devices designed with on chip parallel termination. Very small > changes in I result in significant changes in V. If you don't nail the exact > > operating points with enough I-V points you obtain DC offsets in your > resultant output waveforms. > > I would strongly suggest while modifying 100 -> 1000 point change to the V-T > > curves we should also relax that restriction on the I-V from 100->1000. > We should be proactive, If additional points are not required they don't > have > to be used, but if more points are needed the limitation is not in the > specification. > > regards, > Bob H. > > Cereva Networks > 3 Network Drive > Marlboro MA. 01752 > Phone: 508-486-9660 X 3365 > FAX: 508-486-9661 > Email: rhaller@cereva.com > From owner-ibis Fri Oct 27 17:29:44 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9S0TgX07780 for ; Fri, 27 Oct 2000 17:29:43 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA00938; Fri, 27 Oct 2000 17:26:33 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA26075; Fri, 27 Oct 2000 17:26:32 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39FA1D37.D1AD6D14@mentor.com> Date: Fri, 27 Oct 2000 17:26:31 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: BIRD67.1 is the same as BIRD67, except the 1000 point limit is clarified as 1000 rows. This deals with the issue brought up at the October 27, 2000 meeting regarding whether NA's are counted as points. Bob Ross Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 67.1 ISSUE TITLE: Increase V-T Table 100 Point Limit REQUESTER: Bob Ross, Mentor Graphics, Ian Dodd, Cadence DATE SUBMITTED: October 24, 2000, October 27, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The 100 point limitation on V-T tables is too limiting because of increased accuracy needs and the fact that the available point may have to be distributed among the typ, min, and max columns. A 1000 point limit is proposed. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: In the following keyword, the value 100 is replaced by 1000, and points is replace by rows on the lines designated by |* |============================================================================= | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge waveforms | of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, C_fixture, | L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that describe | the shape of an output waveform. These time/voltage points | are taken under the conditions specified in the | R/L/C/V_fixture and R/L/C_dut subparameters. The table itself | consists of one column of time points, then three columns of | voltage points in the standard typ, min, and max format. The | four entries must be placed on a single line and must be | separated by at least one white space. All four columns are | required. However, data is only required in the typical | column. If minimum or maximum data is not available, use the | reserved word "NA". The first value in the time column need | not be '0'. Time values must increase as one parses down the |* table. The waveform table can contain a maximum of 1000 data |* rows. A maximum of 100 waveform tables are allowed per | model. Note that for backward compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; i.e., the | first entry (or entries) in a voltage column must be the DC | voltage of the output before switching and the last entry (or | entries) of the column must be the final DC value of the | output after switching. Each table must contain at least two | entries. Thus, numerical values are required for the first | and last entries of any column containing numerical data. | | A [Model] specification can contain more than one rising edge | or falling edge waveform table. However, each new table must | begin with the appropriate keyword and subparameter list as | shown below. If more than one rising or falling edge waveform | table is present, then the data in each of the respective | tables must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a common | reference point on the input stimulus waveform. | | The 'fixture' subparameters specify the loading conditions | under which the waveform is taken. The R_dut, C_dut, and | L_dut subparameters are analogous to the package parameters | R_pkg, C_pkg, and L_pkg and are used if the waveform includes | the effects of pin inductance/capacitance. The diagram below | shows the interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | NOTE: The use of L_dut, R_dut, and C_dut is strongly | discouraged in developing Waveform data from simulation | models. Some simulators may ignore these parameters because | they may introduce numerical time constant artifacts. | | Only the R_fixture and V_fixture subparameters are required, | the rest of the subparameters are optional. If a subparameter | is not used, its value defaults to zero. The subparameters | must appear in the text after the keyword and before the first | row of the waveform table. | | V_fixture defines the voltage for typ, min, and max supply | conditions. However, when the fixture voltage is related to | the power supply voltages, then the subparameters | V_fixture_min and V_fixture_max can be used to further specify | the fixture voltage for min and max supply voltages. | | NOTE: Test fixtures with R_fixture and V_fixture, | V_fixture_min, and V_fixture_max only are strongly encouraged | because they provide the BEST set of data needed to produce | the best model for simulation. C_fixture and L_fixture can be | used to produce waveforms which describe the typical test case | setups for reference. | | NOTE: In most cases two [Rising Waveform] tables and two | [Falling Waveform] tables will be necessary for accurate | modeling. | | All tables assume that the die capacitance is included. | Potential numerical problems associated with processing the | data using the effective C_comp for effective die capacitance | may be handled differently among simulators. |----------------------------------------------------------------------------- [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This topic has been discussed at several IBIS Meeting and on e-mail. BIRD67 complies with the action item to propose a correction to the 100 point limit problem on V-T tables. There now exists both the requirement that V-T tables have high resolution for accuracy and also extend to a time where the DC value reaches the correct DC final value. A further requirement is that the high resolution exists on all columns - typ, min, and max. However, often the waveforms for min and max columns are both delayed differently and have their sharpest transition points distributed at different time values from each other and from the typ column points. Since the time points are all referenced to the same time axis for all columns, the selection of actual time values for best accuracy might be different for each column. A worst case scenerio would have approximately 33 selected time points available for each column. This provides too low of a resolution needed for some of the higher speed devices and for some corresponding accuracy requirements. This issue is further confused by whether NA entries in a particular column count as one of the maximum 100 entries in that column. The worst case interpretation is that it does. Also ibischk3 enforces this limitation regardless of contents of any column. Often tools used to generate V-T tables use constant time steps. This often provides conflicting delta time requirements: small enough for the necessary resolution for the fastest responses, and large enough so that the final DC value is reached for the slowest response using 100 points or less. More complicated optimal distribution of points may be the only solution. With more allowable points even the simplier constant delta time tables can be provided. BIRD67 simply increases the maximum value allowed to 1000. We still want to provide a limit to prevent vendors from providing unnecessarily large amounts of V-T data. At this time we feel that 1000 points is more than adequate. BIRD67 retains the 100 point limit for all other tables. The 100 point limit is still reasonable for these situations. Having a common limit of 1000 would also be attractive for consistency, but this would also encourage producing needlessly large files. An older BIRD17 had proposed raising the limit to 151 for greater resolution and to allow even distribution of some I-V data based on 5 V technology. BIRD17 was rejected. One reason was that a common tool at that time had a limit of 100 points when processing table based VCCS and VCVS functions - a key element in processing IBIS models. The need to be compatible with this tool still exists, but the need for greater resolution also exists. The burden now shifts to the specific tool - either it must change its limits or else provide the filtering algorithm to do the best selection of data points. Most other tools do not have such a 100 point restriction. BIRD67.1 changes points to rows to clarify that the limit is for time entries rather than number of actual data points in each column. This is the most conservative interpretation. The 1000 points is retained rather than increasing to 1001 to discourage people to automatically putting in the maximum allowable points when they are not needed. The issue of increasing the 100 row limit for I-V tables would be addressed in another BIRD. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Mon Oct 30 12:01:24 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9UK1FX18056 for ; Mon, 30 Oct 2000 12:01:23 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id OAA25217 for ; Mon, 30 Oct 2000 14:58:03 -0500 (EST) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id OAA09179 for ; Mon, 30 Oct 2000 14:58:02 -0500 (EST) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id LAA17421 for ; Mon, 30 Oct 2000 11:56:32 -0800 (PST) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id MAA09332; Mon, 30 Oct 2000 12:57:46 -0700 Date: Mon, 30 Oct 2000 12:57:46 -0700 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200010301957.MAA09332@f22.innoveda.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes (10/27/00) Date: 10/30/00 SUBJECT: 10/27/00 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com Roy Leventhal Agilent (EEsof, etc.) Mark Chang Ansoft Corporation (Eric Bracken) Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti Nikolai Bannov Brocade Communications Robert Badal Cadence Design Mike LaBonte*, Todd Westerhoff, Ian Dodd*, Donald Telian, Patrick Dos Santos Cisco Systems Syed Huq*, Irfan Elahi, John Fisher Compaq [Bob Haller], Peter LaFlamme, Ron Bellomio, Shafier Rahman, Doug Burns Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella, Brian Arsenault, Terry Jernberg, Alexander Nosovitski, Elena Gutman, Shan Haq Fairchild Semiconductor Craig Klem HyperLynx (& Pads Software) Matthew Flora*, [Kellee Crisafulli], (Now merged with Innoveda) Gene Garat, John Angulo*, [Al Davis], Lynne Green IBM Michael Cohen*, Greg Edlund, Jerry Hayes Innoveda (Viewlogic Systems) Chris Rokusek, Guy de Burgh*, Jun Tian, Cary Mandel, Brad Griffin, (Jon Powell) Intel Corporation Stephen Peters*, Arpad Muranyi, Will Hobbs, Richard Mellitz, Charles Phares, Meir Nakar, Sigeti Gabi, Tudor Secasiu, Dave Lorang* LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross*, Tom Dagostino, Malcolm Ash, Kim Owen, Jean Oudinot, Sherif Hammad, Hazam Hegazy, Weston Beal, Ken Bakalar Micron Technology Randy Wolff, Son Huynh Mitsubishi Shahab Ahmed, Carleen Murphy, Scott Estrich Molex Incorporated Gus Panella Motorola Ron Werner National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Tony Sinker, Kathy Breda, Jinhua Chen Nortel Networks Steve Coe, Calvin Trowell, Hassan Ali Philips Semiconductor D.C. Sessions*, Todd Andersen (& VLSI Technology) Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens AG Bernhard Unger, Gerald Bannert SiQual Scott McMorrow, Wis Macomson Texas Instruments Stephen Nolan, Ramzi Ammar, Mac McCaughey, Thomas Fisher, Jean-Claude Perrin, Jean-Yves Oberle Time Domain Analysis Systems Dima Smolyansky, Steven Corey Tyco Electronics (AMP) (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) Werner Rissiek, John Berrie OTHER PARTICIPANTS IN 2000: Actel Corp. Silvia Montoya Advansis Mikio Kiyono Aerospatiale Matra CCR Lionel Dreux, Julien Boullie Alcatel (Lannion, Bell) Daniel Peron, Steven Criel Cereva Networks Bob Haller ECI Telecom Daniel Adar EIA Cecilia Fleming Fraunhofer Institute Michael Kurten Jet Propulsion Lab John Treichlew KAW Shinichi Maeda Hewlett Packard Paul Gregory RCI Chris Rode Rockwell Collins Ron Hau Signals & Systems Engineering Tom Hawkins ST Microelectronics Fabrice Boissiere, Pierre Saintot Sun Microsystems Victor Chang Thomson-CSF Savenrio Lerose, Pascal Vaslin, Thierry Zak, Sylvie Lasserre Transfer Hans Klos, Wilco Hamhuis Xilinx, Inc. Susan Wu Independent, Consultant Hideki Fukuda, Al Davis* In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode November 17, 2000 (916) 356-9200 8-160063 1329512 December 8, 2000 (916) 356-9200 To be issued December 22, 2000 (916) 356-9200 To be issued 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 No new participants. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that Brocade Communications has joined the IBIS Open Forum as an official member, and their entry has been moved to the Voting Member list above. We now have 35 members. REVIEW OF MINUTES AND AR'S The October 6, 2000 IBIS Minutes were approved without any changes. Bob Ross noted that people often e-mail changes and corrections shortly after the Minutes are sent, and the changes get reported at the next meeting. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob Ross commented that the last financial report of the year gives the best information. The monthly reports sometimes give income (such as membership payment) and expenses (the various allocations) as a pro-rated year-to-date entry, and some other items as their total amount. So, in the September report the dues income entry would actually be multiplied by 4/3 to get the actual income. Based on this, we have exceeded our we exceed our budgeted income. The 2001 budget will show an increase of Salaries & Benefits payment to EIA from $9000 to $12000. We are now approaching the break-even point again. PRESS AND WEB PAGE UPDATES Bob Ross reported that the article "IBIS and SPICE Revisited" by Jon Powell appears in the October 2000 issue of Printed Circuit Design, pp. 28-32. This article mentions some recent committee developments. Bob also reported that IBIS was mentioned in the October 2000 issue of IEEE Spectrum in the article "Modeling for Printed-Circuit Board Simulation" by Anil Balaram, pp. 70-74. D.C. Sessions added that while the article mentions IBIS several times, it really does not cover the signal integrity aspects. Bob also reported that the book High Speed Digital System Design, A Handbook of Interconnect Theory and Design Practices, by Stephen Hall, Garrett Hall, and James McCall, published in 2000 by John Wiley mentions IBIS and all of the I-V and V-T behavioral concepts in Chapter 7, "Buffer Modeling". Also the book Digital Signal Integrity, Modeling and Simulation with Interconnects and Packages, Brian Young, published in 2000 by Prentice Hall mentions IBIS several times. Syed Huq has provided some Web page updates and Roster Updates. The official EIA/IBIS-656-A Version 3.2 specification is now located under the Spec link. Syed will also send a message on the IBIS reflector to ask for Roster Updates. Guy de Burgh stated that he has been following up directly on some known membership change situations, but has not received responses yet. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported NEC Corporation IBIS models for memories exist under the Simulation Models links from NEC at: http://www.ic.nec.co.jp/memory/english/model/index.html Advanced Micro Devices (AMD) has some embedded processor models at: http://www.amd.com/products/epd/desiging/tsdocs/1.ibismodel/index.html Lucent Technologies has another link for network and communication ICs: http://www.lucent.com/micro/netcom/products/pdh.html Also, an LSI Logic link has been updated: http://www.lsilogic.com/products/storage_standard_prod/oem/ibis_models/ Mike LaBonte reported IBIS models from GSI Technology at http://www.gsitechnology.com/models1.htm Mike plans to update the Models link with this and other information. He also provides valuable information and observations regarding the content of the libraries. OPENS FOR NEW ISSUES Bob Ross - BIRD67 - Increase V-T Table 100 Point Limit Dave Lorang - BIRD68 - Clarify that Rising and Falling Waveform Tables Should be Correlated D.C. Sessions - V-T Table Compression INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross worked with Stephen Peters and other IBIS Officers and Cecilia Fleming to draft header information based on some updated requirements from IEC regarding scope and historical background. This complies with the AR of the October 6, 2000 IBIS Meeting. The new information has been added to the ANSI/EIA-656-A document and has been sent to Greg Ledenbach, Secretary of IEC TC-93, who has forwarded it to IEC. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross got a report from Jean-Claude Perrin stating that they have done some verification measurements on ICs. They are also doing measurements relating to PCB radiation. Jean-Claude will propose in the TC93 Plenary meeting to write the document as a CDV to create a public working document. His plan is that a future release of IBIS might take the IEC document into account. - JEDEC JC-16 - Modeling and Testing - D.C. Sessions invited IBIS members to participate at the next JEDEC JC-16 and JC-42 meetings December 6-7, 2000 in Kona, Hawaii. Contact D.C. if you are interested for a Chairman's invitation at his ibis e-mail account: ibis@lumbercartel.com D.C. stated that Mike LaBonte plans to attend. D.C. also stated that some interesting technical issues are being raised in the JEDEC JC-16 committee. JEDEC discussions are closed, but he can report as Chair that some public methods to increase the eye-diagram opening in DDR performance has been done using a capacitance to ground. FUTURE SUMMIT PLANNING The next IBIS Summit Meeting is planned on January 29, 2000 in Santa Clara, California along with DesignCon 2001 (January 29 - February 1, 2000). Bob Ross noted that National Semiconductor is a co-sponsor of this meeting and will provide the lunch. Milt Schwartz will continue to assist in the arrangements of this meeting. DesignCon is the other co-sponsor as a result of IBIS Associate Sponsorship of DesignCon 2001. We also plan to have a passive IBIS booth on the exhibit floor for literature and interaction. We will be sending out meeting notice information about six weeks before the meeting. Some other deliverables are due in November to be included in the conference literature. Bob secured a meeting site for the European IBIS Summit meeting to be held March 16, 2000 in Munich, Germany along with the Design Automation and Testing (DATE 2001) conference and exhibit. Bob has co-sponsorship again from Mentor Graphics and Zuken (Incases) and is seeking other co-sponsors as well. Information on these events exists at the Upcoming Events Links of the IBIS Home Page. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo has asked the vendor of the model reported at the October 6, 2000 meeting some questions on it. John is still waiting for resolution before distributing the model. CONNECTOR PROPOSAL REVIEW Bob Ross reported on two Connector Working Group meetings held on October 10 and October 17, 2000. The discussion continued on the For/Next syntax, the possibility of eliminating the Physical Model, and other subjects. There exists some support for keeping the Physical Model, so the issue is subject to more discussion. The next meeting is planned on October 31, 2000. Ian Dodd added that there is ambiguity regarding having the output pins named differently from the input pins. Ian also added that the Working Group would like to see more participants. IBIS FUTURES (IBIS-X, API, BIRDxx) Bob Ross mentioned that Working Group meetings were held on October 10 and October 24, 2000. The next meeting will be held on November 7, 2000. Mike LaBonte stated that the Working Group discussed data sets beyond the typ, min, and max columns allowing more columns. Al Davis still expects the prototype by the end of November 2000. A Working Group goal is to have documentation available for the DesignCon 2001 IBIS Summit Meeting. V-T TABLE COMPRESSION (New Item) D.C. Sessions commented that Philips IBIS models have the V-T time data points optimally compressed and distributed. He can provide a Perl script to do this. This script may be made public for Web distribution. At this time contact D.C. directly for information (see the IBIS Roster Listing link). Al Davis commented that points that are too closely spaced might cause simulation problems because of discontinuous derivatives. IBISCHK3 BUG TRACKING Bob Ross reported that Atul Agarwal does not see any problems in implementing the approved BUGs through BUG46. [Added note after the meeting - Atul did estimate he could do the work by mid November 2000.] Atul may need help on pending BUG47. - BUG47 - Change Waveform Mismatch Warning to Error and Warning We deferred discussion and resolution of BUG47 pending the revised wording proposal. Matthew Flora had some revisions, but they were not sent out. AR - Matthew Flora work with Mike LaBonte to revise the message report text of BUG47. BIRD61.1 - ENHANCED CHARACTERIZATION OF RECEIVERS D.C. Sessions stated that there has been no movement on BIRD61.1. He is calling for a vote. There was some discussion. Bob Ross felt that there were still some technical concerns. The committee had been viewing the IBIS-X or future IBIS direction as a possible solution rather than doing further work on BIRD61.1. Al Davis wanted to contact D.C. off-line to understand some of the concerns and to discuss how IBIS-X might implement and prototype the ideas. The outcome might a new BIRD for the existing IBIS format based on some tested ideas. Bob stated that BIRD61.1 will be scheduled for a vote at the November 17, 2000 IBIS meeting. BIRD64.2 - PACKAGE MODEL SELECTOR Bob Ross introduced BIRD64.2 briefly by noting that the AR from the October 6, 2000 meeting to position the new [Package Model Selector] keyword under [Component] had been complied with by Mike LaBonte. Mike is now listed as a co-author. Some aspects of BIRD64.2 were clarified. Al Davis was concerned with the differences in scoping and syntax between [Package Model Selector] and the [Model Selector]. We discussed some of the reasons for the differences including different calling conventions and scoping. Michael Cohen stated that one of the differences was based on the fact that spaces are technically allowed in package model names, but not in model names. So the second column under [Model Selector] can be a description column. The names also have different character length requirements. During the discussions Michael commented that the value of BIRD64.2 is that package model selections can be set up automatically by script or manually through a graphical user interface (GUI). Bob noted that the 40 character name should provide sufficient description of the choices. However, BIRD64.2 does not give any machine readable information about the content of each package model choice (such as typ, min, max or even and odd mode). So the application would be set up on a part-by-part basis. A vote was called for BIRD64.2. During the vote, Mike LaBonte expressed some reservations on BIRD64.2 from the preceding discussion. He felt that the positioning should be different. After some more remarks, the vote was continued with three choices: Yes, No, or Defer for revision. The vote was 8 Defer, 1 Yes, and 1 Abstain. Mike will work on the text of the changes to be ready for the next IBIS meeting. AR - Mike LaBonte issue the changes as BIRD64.3 by Friday, November 3, 2000 to be considered for a vote on the November 17, 2000 meeting. BIRD65 - C_comp REFINEMENTS Not discussed. BIRD66 - [Model Spec] Vref ADDITION Michael Cohen called for a vote on BIRD66. Bob Ross scheduled the vote for the November 17, 2000 IBIS Meeting. Bob noted that some discussion items concerning it could be brought up then. D.C. Sessions commented that JEDEC technologies have reference voltages that change significantly with supply voltage changes. BIRD67 - Increase V-T Table 100 Point Limit Bob Ross and Ian Dodd co-authored BIRD67 in response to the AR from the October 6, 2000 meeting. Bob introduced BIRD67 by noting that it increased the allowable number of point in V-T tables to 1000 points. He stated that IBIS puts limits on all parameters. We do not want to have arbitrarily large files generated by model providers (just to be conservative), but we also do not want to put size constraints that compromise accuracy. The 100 point V-T limitation can sometimes cause accuracy limitations based on existing automated methods to generate IBIS buffer models. Bob stated that one commentor felt the limit should be 1001 points to allow equally spaced integral time values such as 0 nS to 10 nS in 10 pS steps. Several people commented that producing models with 1000 points is not encouraged. V-T files with only as many points as possible is still the preferred method. The group felt that setting the limit to 1001 points would encourage producing unnecessarily large files with 1001 points. Bob mentioned that Bob Haller sent a note to the IBIS reflector stating that that the 100 point limit on I-V tables should also be increased to 1000 points for the same reasons given for V-T tables. After some discussion, the committee felt that this additional increase in points should be considered in a separate BIRD. BIRD67 should only deal with V-T tables. Michael Cohen commented that the ANALYSIS .. section of BIRD67 discussed the ambiguity of whether NA lines were counted as points on for each V-T column. Michael stated that this should be made clear and resolve. Bob Ross felt that the Committee intended to use the most conservative interpretation consistent with ibischk3. This interpretation would interpret 1000 points as the number of time entries regardless of whether or not that line contained columns with NA entries. D.C. Sessions suggested changing the word "points" to "rows" to formally clarify this ambiguity. Bob agreed to make the change and issue BIRD67.1 in time for a vote at the November 17, 2000 meeting. AR - Bob Ross issue BIRD67.1 with the 1000 points clarified by 1000 rows. [Done] BIRD68 - Clarify that Rising and Falling Waveform Tables Should be Correlated Dave Lorang introduced the recently issued BIRD68 by stating the need to have both the [Rising Waveform] and [Falling Waveform] tables time correlated to each other in a manner that preserves any relative TCO delays for each edge. Dave stated that for correct intersymbol interference analysis the relative delays need to be preserved. If EDA tools need to remove initial "lead-in" time, they need to remove the same amount from both edges. Al Davis added [Rising Waveform] and [Falling Waveform] tables also need to be time correlated with each other for differential buffer modeling. Several other points were brought up. Stephen Peters noted that the time reference in BIRD68 needs to be clarified further. Some text refers to the input threshold trigger point. Also, we need to consider whether to use a sub-parameter to state that the model was produced with the [Rising Waveform] and [Falling Waveform] relative delays preserved. This would be applicable in the next version of IBIS and would be consistent with backwards compatibility. The discussion will continue at the next meeting. NEXT MEETING: The next teleconference meeting will be on Friday, November 17, 2000 from 8:00 AM to 10:00 AM. BIRD61.1, BIRD64.3, BIRD66, and BIRD67.1 are scheduled for a vote along with BUG47 message resolution. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Mike LaBonte (978) 262-6496, Fax: (978) 446-6798 mikelabonte@cadence.com Senior Technologist, Cadence Design Systems 270 Billerica Road Chelmsford, MA 01824 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 angulo@hyperlynx.com Development Engineer, HyperLynx, Inc. 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Oct 31 14:49:44 2000 Received: from odin.acuson.com (odin.acuson.com [157.226.230.71]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9VMnhX27558 for ; Tue, 31 Oct 2000 14:49:44 -0800 (PST) Received: from acuson.com ([157.226.45.34]) by odin.acuson.com (Netscape Messaging Server 3.54) with ESMTP id AAA255B for ; Tue, 31 Oct 2000 14:49:54 -0800 Sender: "Kim Helliwell" Message-ID: <39FF4B2D.D329D5CD@acuson.com> Date: Tue, 31 Oct 2000 14:43:57 -0800 From: Kim Helliwell Organization: Acuson X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: question about IBIS versions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a situation where an IBIS model that was made with s2ibis2, and is therefore ostensibly a Version 2.1 model, may need a model selector keyword. The question is: is changing the version to 3.x and adding the model selector sufficient, or are there actual changes in the syntax of stuff that's common between 2.1 and 3.x? Or are there any other pitfalls in what I'm attempting here? -- Kim Helliwell Senior CAE Engineer Acuson Corporation Phone: 650 694 5030 FAX: 650 943 7260 From owner-ibis Tue Oct 31 15:23:00 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e9VNMtX27663 for ; Tue, 31 Oct 2000 15:22:59 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA12098; Tue, 31 Oct 2000 15:19:42 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA13612; Tue, 31 Oct 2000 15:19:40 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <39FF538D.FB2A62C4@mentor.com> Date: Tue, 31 Oct 2000 15:19:41 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kim Helliwell CC: ibis@eda.org Subject: Re: question about IBIS versions References: <39FF4B2D.D329D5CD@acuson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kim: In general, the Version of IBIS needs to be brought up to the level of the highest version keyword or sub-parameter within the file. This will allow it to pass ibischk3 at the proper version level (which could be 1.1, 2.1 or 3.2). In your case, just changing the Version number to 3.2 should be sufficient when adding [Model Selector]. Because of the upward compatibility goal, no other changes are necessary. Bob Ross Mentor Graphics Kim Helliwell wrote: > > I have a situation where an IBIS model that was made with s2ibis2, and > is therefore ostensibly a Version 2.1 model, may need a model selector > keyword. > > The question is: is changing the version to 3.x and adding the model selector > sufficient, or are there actual changes in the syntax of stuff that's common > between 2.1 and 3.x? > > Or are there any other pitfalls in what I'm attempting here? > > -- > Kim Helliwell > Senior CAE Engineer > Acuson Corporation > Phone: 650 694 5030 FAX: 650 943 7260