From owner-ibis Wed Nov 1 10:17:11 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 eA1IH8X04246 for ; Wed, 1 Nov 2000 10:17:10 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA13538; Wed, 1 Nov 2000 10:13:57 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA20215; Wed, 1 Nov 2000 10:13:55 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A005D62.DFABF07B@mentor.com> Date: Wed, 01 Nov 2000 10:13:54 -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: ibis@eda.org Subject: IBIS BIRD64.3 - Alternate Package Models Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: In response to some comments at the October 27, 2000 IBIS Meeting BIRD64.3 is Issued. The title has been changed from Package Model Selector to Alternate Package Models. Discussion on BIRD64.3 can be done on the IBIS reflector. Bob Ross Mentor Graphics ******************************************************************************* ******************************************************************************* BIRD ID#: 64.3 ISSUE TITLE: Alternate Package Models REQUESTER: Arpad Muranyi, Intel; Mike LaBonte, Cadence DATE SUBMITTED: 10-25-99, 11-19-99, 10-8-2000, 11-1-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 [Alternate Package Models] shall contain a list of package model names that the simulator can pick from, in addition to the default package model name given by the [Package Model] keyword. The package model names listed under the [Alternate Package Models] 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: [Alternate Package Models] [End Alternate Package Models] | Required: No. | Description: Used to select a package model from a list of package models. | Sub-Params: None. | Usage Rules: The [Alternate Package Models] keyword can be used in addition | to the [Package Model] keyword. [Alternate Package Models] | may be used only for components that use the [Package Model] | keyword. | | Each [Alternate Package Models] keyword specifies a set of | alternate package model names for only one component, which | is given by the previous [Component] keyword. The [Alternate | Package Models] keyword may not appear before the first | [Component] keyword in an IBIS file. The [Alternate Package | Models] keyword, when used, must follow the [Package Model] | keyword within the same [Component] section, and must be | followed by an [End Alternate Package Models] keyword.. | | All alternate package model names must appear below the | [Alternate Package Models] keyword, and above the following | [End Alternate Package Models] keyword. The package model names | listed under the [Alternate Package Models] must follow the | rules of the package model names associated with the | [Package Model] keyword. The package model names correspond | to the names of package models defined by [Define Package | Model] keywords. Simulation tools may offer users a facility | for choosing between the default package model and any of the | alternate package models, when analyzing occurances of the | [Component]. |============================================================================= | [Alternate Package Models] | 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. [End Alternate Package Models] | ****************************************************************************** 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. This was proposed in the original BIRD. Add a secondary keyword to list package models that are alternates to the default package model given by [Package Model]. This is the currently proposed solution. ****************************************************************************** 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 existing rules this is not possible, because 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 [Alternate Package Models] 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 description 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 [Alternate Package Models] should be used to specify 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 [Alternate Package Models] list, since these variations would normally require changes to other elements of the component model. Revision 64.3 changes 10-31-2000, Mike LaBonte: At the 10-27-2000 IBIS forum meeting it was pointed out that the original [Package Model Selector] keyword proposal was inconsistent in usage with the [Model Selector] keyword. A key point is that each [Model Selector] has a name that can be referred to in the [Pin] section as if it were the name of a [Model]. The [Package Model Selector] keyword, as proposed, had no name. This was ponted out earlier by Bob Ross. The [Alternate Package Models] proposal avoids the use of a named selector, and retains the usefulness of the existing [Package Model] keyword. At this time an [End Alternate Package Models] keyword is introduced, to reduce potential parsing ambiguity for the list of alternate package model names. Along with this change the title of the BIRD changes from "Package Model Selector" to "Alternate Package Models". A usage note explaining that the name values in the list refer to [Define Package Model] names is also added. ****************************************************************************** From owner-ibis Thu Nov 2 13:14:42 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 eA2LEdX10692 for ; Thu, 2 Nov 2000 13:14:41 -0800 (PST) Received: from acuson.com ([157.226.45.34]) by odin.acuson.com (Netscape Messaging Server 3.54) with ESMTP id AAA40F3 for ; Thu, 2 Nov 2000 13:14:47 -0800 Sender: "Kim Helliwell" Message-ID: <3A01D7DF.AB60200C@acuson.com> Date: Thu, 02 Nov 2000 13:08:47 -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: Can IBIS model CML buffers? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't see how, but if there's a way, I'd like to know about it. -- Kim Helliwell Senior CAE Engineer Acuson Corporation Phone: 650 694 5030 FAX: 650 943 7260 From owner-ibis Thu Nov 2 13:31:09 2000 Received: from mail03-oak.pilot.net (mail-oak-3.pilot.net [198.232.147.18]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA2LV3X10736 for ; Thu, 2 Nov 2000 13:31:08 -0800 (PST) Received: from Altera.COM (altera.com [137.57.1.1] (may be forged)) by mail03-oak.pilot.net with ESMTP id NAA05622 for ; Thu, 2 Nov 2000 13:27:55 -0800 (PST) Received: from sj-gw01.altera.com by Altera.COM (8.8.8+Sun/SMI-4.1) id NAA25715; Thu, 2 Nov 2000 13:29:43 -0800 (PST) Received: by sj-gw01.altera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 13:30:31 -0800 Message-ID: <3988F0001E0BD31192180090274077D00637056F@sj-msg01.altera.com> From: Bruce Motavaf To: ibis@eda.org Subject: RE: Can IBIS model CML buffers? Date: Thu, 2 Nov 2000 13:29:30 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Does anyone know where I can get IBIS model for a LVPECL buffer ? Thx From owner-ibis Thu Nov 2 15:57:13 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 eA2NvBX11578 for ; Thu, 2 Nov 2000 15:57:12 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA01277; Thu, 2 Nov 2000 15:53:58 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA07150; Thu, 2 Nov 2000 15:53:55 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A01FE93.45C31BBF@mentor.com> Date: Thu, 02 Nov 2000 15:53:55 -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: ibis@eda.org Subject: Comments on IBIS BIRD64.3 - Alternate Package Models References: <3A005D62.DFABF07B@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: I had some comments for Mike LaBonte, but we decided to carry on the discussion on the IBIS reflector for more input. 1. The content of [Alternate Package Models] .. [End Alternate Package Models] are all the ADDITIONAL package models. The default package model is still called by the [Package Model] keyword. (a) What happens if [Package Model] is not defined? Error? Different default (e.g., the [Pin] or [Package] entries? The first entry of [Alternate Package Models] is the default? (b) Can the [Package Model] selection be listed in the [Alternate Package Models] list? (This might occur when editing a different default.) Yes No, Error Yes, Warning 2. My preference would be to change the keyword to [Package Model Options] or something else (but changed from [Package Model Selector] to avoid confusion with some different rules for [Model Selector] and make it function independent from any other keyword. It would have the highest priority. Similar to [Model Selector] the default would always be the first entry in the list. (a) Would this structure be better for EDA tools that might want to create a GUI (the list is in one keyword, not two keyword)? (a) Similarly, is this better for scripting (the language may reference the contents of one keyword, not two keywords? 3. Are there any better names than [Alternate Package Model]? Bob Bob Ross wrote: > > To All: > > In response to some comments at the October 27, 2000 IBIS Meeting > BIRD64.3 is Issued. The title has been changed from Package > Model Selector to Alternate Package Models. > > Discussion on BIRD64.3 can be done on the IBIS reflector. > > Bob Ross > Mentor Graphics > > ******************************************************************************* > ******************************************************************************* > > BIRD ID#: 64.3 > ISSUE TITLE: Alternate Package Models > REQUESTER: Arpad Muranyi, Intel; Mike LaBonte, Cadence > DATE SUBMITTED: 10-25-99, 11-19-99, 10-8-2000, 11-1-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 [Alternate Package Models] shall contain > a list of package model names that the simulator can pick from, in addition to > the default package model name given by the [Package Model] keyword. The > package model names listed under the [Alternate Package Models] 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: [Alternate Package Models] [End Alternate Package Models] > | Required: No. > | Description: Used to select a package model from a list of package models. > | Sub-Params: None. > | Usage Rules: The [Alternate Package Models] keyword can be used in addition > | to the [Package Model] keyword. [Alternate Package Models] > | may be used only for components that use the [Package Model] > | keyword. > | > | Each [Alternate Package Models] keyword specifies a set of > | alternate package model names for only one component, which > | is given by the previous [Component] keyword. The [Alternate > | Package Models] keyword may not appear before the first > | [Component] keyword in an IBIS file. The [Alternate Package > | Models] keyword, when used, must follow the [Package Model] > | keyword within the same [Component] section, and must be > | followed by an [End Alternate Package Models] keyword.. > | > | All alternate package model names must appear below the > | [Alternate Package Models] keyword, and above the following > | [End Alternate Package Models] keyword. The package model names > | listed under the [Alternate Package Models] must follow the > | rules of the package model names associated with the > | [Package Model] keyword. The package model names correspond > | to the names of package models defined by [Define Package > | Model] keywords. Simulation tools may offer users a facility > | for choosing between the default package model and any of the > | alternate package models, when analyzing occurances of the > | [Component]. > |============================================================================= > | > [Alternate Package Models] > | > 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. > [End Alternate Package Models] > | > ****************************************************************************** > > 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. This was proposed in the original > BIRD. > > Add a secondary keyword to list package models that are alternates to the > default package model given by [Package Model]. This is the currently > proposed solution. > > ****************************************************************************** > > 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 existing rules this is not possible, because 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 [Alternate Package Models] 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 description 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 [Alternate Package Models] should be used to specify 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 [Alternate Package Models] list, since > these variations would normally require changes to other elements of the > component model. > > Revision 64.3 changes 10-31-2000, Mike LaBonte: > > At the 10-27-2000 IBIS forum meeting it was pointed out that the original > [Package Model Selector] keyword proposal was inconsistent in usage with the > [Model Selector] keyword. A key point is that each [Model Selector] has a > name that can be referred to in the [Pin] section as if it were the name of a > [Model]. The [Package Model Selector] keyword, as proposed, had no name. > This was ponted out earlier by Bob Ross. The [Alternate Package Models] > proposal avoids the use of a named selector, and retains the usefulness of the > existing [Package Model] keyword. At this time an [End Alternate Package > Models] keyword is introduced, to reduce potential parsing ambiguity for the > list of alternate package model names. > > Along with this change the title of the BIRD changes from "Package Model > Selector" to "Alternate Package Models". A usage note explaining that > the name values in the list refer to [Define Package Model] names is also > added. > > ****************************************************************************** From owner-ibis Fri Nov 3 03:53:07 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 eA3Br5X16349 for ; Fri, 3 Nov 2000 03:53:06 -0800 (PST) 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 DAA15321 for ; Fri, 3 Nov 2000 03:48:57 -0800 (PST) Received: from cadence.com (d158140105142 [158.140.105.142]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id GAA18720 for ; Fri, 3 Nov 2000 06:48:57 -0500 (EST) Message-ID: <3A02A626.10AA1624@cadence.com> Date: Fri, 03 Nov 2000 06:48:54 -0500 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: Re: Comments on IBIS BIRD64.3 - Alternate Package Models References: <3A005D62.DFABF07B@mentor.com> <3A01FE93.45C31BBF@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as DAA15321 at Fri Nov 3 03:48:57 2000 Bob has some good questions. By the guidelines we set at the last forum meeting, if a BIRD64.4 will be posted it should be today, to be considered for a vote at the next meeting. So hopefully we will see some discussion of this ASAP. My responses to Bob's points: 1a) What happens if [Package Model] is not defined? The BIRD explicitly requires it: | Usage Rules: The [Alternate Package Models] keyword can be used in addition | to the [Package Model] keyword. [Alternate Package Models] | may be used only for components that use the [Package Model] | keyword. 1b) Can the [Package Model] selection be listed in the [Alternate Package Models] list? When Bob brought this up it occurred to me that we have no requirements regarding duplicate model names within the [Alternate Package Models] list. We could add a "no duplicates" policy. But as an EDA vendor I am OK with having my software simply filter out the 2nd occurrence of a name, and any others. Since [Package Model] must appear before [Alternate Package Models], a duplicate between these two would result in removal of the one in the [Alternate Package Models] list. We already have to handle the same type of ambiguity elsewhere in IBIS. 2) Bob would like a list keyword that replaces [Package Model]. The proposal from Bob is more faithful to Arpad's original BIRD, where the [Package Model] keyword is ignored if the list keyword (whatever we call it) is present, and the first package model name is the default. However, in the spirit of backward compatibility my proposal might allow a single IBIS file to be used by tools that do understand the new keyword, and those that do not. A tool that does not yet handle the list keyword would find the [Package Model] keyword and use it. The file with only the list keyword would result in an older tool using no package model at all. I am assuming that tools have a way to use IBIS files that contain unrecognized content, possibly a bad assumption. 3) Are there any better names than [Alternate Package Models]? If we go with Bob's #2 idea, I would suggest [Package Model List]. If Arpad is watching this thread he is probably singing, "Look what they've done to my BIRD, Ma!". OK, I'm showing my age... Mike Bob Ross wrote: > > To All: > > I had some comments for Mike LaBonte, but we decided to carry on the > discussion on the IBIS reflector for more input. > > 1. The content of [Alternate Package Models] .. [End Alternate Package > Models] are all the ADDITIONAL package models. The default package > model is still called by the [Package Model] keyword. > > (a) What happens if [Package Model] is not defined? > > Error? > Different default (e.g., the [Pin] or [Package] entries? > The first entry of [Alternate Package Models] is the default? > > (b) Can the [Package Model] selection be listed in the [Alternate Package > Models] > list? (This might occur when editing a different default.) > > Yes > No, Error > Yes, Warning > > 2. My preference would be to change the keyword to [Package Model Options] or > something else (but changed from [Package Model Selector] to avoid confusion > with some different rules for [Model Selector] and make it function independent > from any other keyword. It would have the highest priority. Similar to [Model > Selector] > the default would always be the first entry in the list. > > (a) Would this structure be better for EDA tools that might want to create a GUI > (the list is in one keyword, not two keyword)? > > (a) Similarly, is this better for scripting (the language may reference the > contents > of one keyword, not two keywords? > > 3. Are there any better names than [Alternate Package Model]? > > Bob From owner-ibis Fri Nov 3 05:59:45 2000 Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA3DxhX16931 for ; Fri, 3 Nov 2000 05:59:44 -0800 (PST) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 09:02:10 -0500 Message-ID: <276737EB1EC5D311AB950090273BEFDD01EC95D2@elway.lss.emc.com> From: "zanella, fabrizio" To: "'Bruce Motavaf'" , ibis@eda.org Subject: RE: Can IBIS model CML buffers? Date: Fri, 3 Nov 2000 08:50:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Bruce, On Semiconductor recently supplied us IBIS models for LVPECL clock buffers, the models are not on the web page, though, you need to call them. Regards, Fabrizio Zanella EMC Corporation Hopkinton MA 01748 fzanella@emc.com -----Original Message----- From: Bruce Motavaf [mailto:bmotavaf@altera.com] Sent: Thursday, November 02, 2000 4:30 PM To: ibis@eda.org Subject: RE: Can IBIS model CML buffers? Does anyone know where I can get IBIS model for a LVPECL buffer ? Thx From owner-ibis Fri Nov 3 13:03:33 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA3L3NX18681 for ; Fri, 3 Nov 2000 13:03:32 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id NAA15559; Fri, 3 Nov 2000 13:00:14 -0800 (PST) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 3 Nov 2000 20:58:58 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA18248; Fri, 3 Nov 2000 13:00:09 -0800 Message-ID: <00a001c045d9$1d0b1820$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: "Bob Ross" , Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 3 Nov 2000 20:58:58 UT References: <3A005D62.DFABF07B@mentor.com> Subject: Re: IBIS BIRD64.3 - Alternate Package Models Date: Fri, 3 Nov 2000 13:00:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Bob, I am a bit concerned about giving comments special meaning. If we want to allow a description to follow each entry in the package model list, then let's define a syntax. I am perfectly happy for the [Alternate Package Model] (or whatever it ends up being called) to have different syntax rules that [Package Model]. My point is that you can simply disallow spaces in the package model names under this keyword and then say that anything following the name is an optional description that may be shown to the user. This would be less confusion if we treat the [Alternate Package Model] as a keyword that works independent from the [Package Model] keyword. In other words, a [Component] might be allowed one of the two keywords, but not both. Don't worry too much about EDA tools not supporting models with the new keyword, we already took that plunge when many of the 3.0 keywords were added (e.g EBD). Regards, Matthew Flora Innoveda ----- Original Message ----- From: "Bob Ross" To: Sent: Wednesday, November 01, 2000 10:13 AM Subject: IBIS BIRD64.3 - Alternate Package Models > To All: > > In response to some comments at the October 27, 2000 IBIS Meeting > BIRD64.3 is Issued. The title has been changed from Package > Model Selector to Alternate Package Models. > > Discussion on BIRD64.3 can be done on the IBIS reflector. > > Bob Ross > Mentor Graphics > > ****************************************************************************** * > ****************************************************************************** * > > BIRD ID#: 64.3 > ISSUE TITLE: Alternate Package Models > REQUESTER: Arpad Muranyi, Intel; Mike LaBonte, Cadence > DATE SUBMITTED: 10-25-99, 11-19-99, 10-8-2000, 11-1-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 [Alternate Package Models] shall contain > a list of package model names that the simulator can pick from, in addition to > the default package model name given by the [Package Model] keyword. The > package model names listed under the [Alternate Package Models] 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: [Alternate Package Models] [End Alternate Package Models] > | Required: No. > | Description: Used to select a package model from a list of package models. > | Sub-Params: None. > | Usage Rules: The [Alternate Package Models] keyword can be used in addition > | to the [Package Model] keyword. [Alternate Package Models] > | may be used only for components that use the [Package Model] > | keyword. > | > | Each [Alternate Package Models] keyword specifies a set of > | alternate package model names for only one component, which > | is given by the previous [Component] keyword. The [Alternate > | Package Models] keyword may not appear before the first > | [Component] keyword in an IBIS file. The [Alternate Package > | Models] keyword, when used, must follow the [Package Model] > | keyword within the same [Component] section, and must be > | followed by an [End Alternate Package Models] keyword.. > | > | All alternate package model names must appear below the > | [Alternate Package Models] keyword, and above the following > | [End Alternate Package Models] keyword. The package model names > | listed under the [Alternate Package Models] must follow the > | rules of the package model names associated with the > | [Package Model] keyword. The package model names correspond > | to the names of package models defined by [Define Package > | Model] keywords. Simulation tools may offer users a facility > | for choosing between the default package model and any of the > | alternate package models, when analyzing occurances of the > | [Component]. > |============================================================================= > | > [Alternate Package Models] > | > 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. > [End Alternate Package Models] > | > ****************************************************************************** > > 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. This was proposed in the original > BIRD. > > Add a secondary keyword to list package models that are alternates to the > default package model given by [Package Model]. This is the currently > proposed solution. > > ****************************************************************************** > > 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 existing rules this is not possible, because 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 [Alternate Package Models] 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 description 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 [Alternate Package Models] should be used to specify 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 [Alternate Package Models] list, since > these variations would normally require changes to other elements of the > component model. > > Revision 64.3 changes 10-31-2000, Mike LaBonte: > > At the 10-27-2000 IBIS forum meeting it was pointed out that the original > [Package Model Selector] keyword proposal was inconsistent in usage with the > [Model Selector] keyword. A key point is that each [Model Selector] has a > name that can be referred to in the [Pin] section as if it were the name of a > [Model]. The [Package Model Selector] keyword, as proposed, had no name. > This was ponted out earlier by Bob Ross. The [Alternate Package Models] > proposal avoids the use of a named selector, and retains the usefulness of the > existing [Package Model] keyword. At this time an [End Alternate Package > Models] keyword is introduced, to reduce potential parsing ambiguity for the > list of alternate package model names. > > Along with this change the title of the BIRD changes from "Package Model > Selector" to "Alternate Package Models". A usage note explaining that > the name values in the list refer to [Define Package Model] names is also > added. > > ****************************************************************************** > From owner-ibis Fri Nov 3 13:08:51 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA3L8nX18709 for ; Fri, 3 Nov 2000 13:08:50 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id NAA22011 for ; Fri, 3 Nov 2000 13:05:41 -0800 (PST) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 3 Nov 2000 21:04:26 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA18306 for ; Fri, 3 Nov 2000 13:05:37 -0800 Message-ID: <00a501c045d9$e07cd0f0$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 3 Nov 2000 21:04:26 UT References: <39F5F720.17A3A450@mentor.com> Subject: Re: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated Date: Fri, 3 Nov 2000 13:06:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 All, I'm concerned about using older models where the [Rising Waveform]'s within a [Model] are time correlated to each other and the [Falling Waveform]'s within that [Model] are time correlated to each other, but no time correlation exists between the [Rising waveform]'s and the [Falling Waveform]'s. How is the simulator to recognize one of these models made prior to the clarification and a model made after the clarification? Would it be based upon the [IBIS_ver] value? Regards, Matthew Flora Innoveda ----- Original Message ----- From: "Bob Ross" To: Sent: Tuesday, October 24, 2000 12:54 PM Subject: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated > 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 Fri Nov 3 13:14:01 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA3LDrX18739 for ; Fri, 3 Nov 2000 13:14:00 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id NAA28131 for ; Fri, 3 Nov 2000 13:10:45 -0800 (PST) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 3 Nov 2000 21:09:30 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA18360 for ; Fri, 3 Nov 2000 13:10:40 -0800 Message-ID: <00b701c045da$953af530$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 3 Nov 2000 21:09:29 UT References: <39FA1D37.D1AD6D14@mentor.com> Subject: Re: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit Date: Fri, 3 Nov 2000 13:11:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Bob, Will this increase to the data point quantity limit be retroactive to IBIS 3.0, 3.1, 3.2, or does it only apply to 3.3 and later? I ask because I want to make sure that IBISCHK will make the distinction. Thanks, Matthew Flora Innoveda ----- Original Message ----- From: "Bob Ross" To: Sent: Friday, October 27, 2000 4:26 PM Subject: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit > 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 Fri Nov 3 13:53:25 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 eA3LrMX18865 for ; Fri, 3 Nov 2000 13:53:24 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA19794; Fri, 3 Nov 2000 13:50:09 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA02376; Fri, 3 Nov 2000 13:50:08 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A03330E.DB7E73F@mentor.com> Date: Fri, 03 Nov 2000 13:50:06 -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: Matthew Flora CC: ibis@eda.org Subject: Re: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit References: <39FA1D37.D1AD6D14@mentor.com> <00b701c045da$953af530$9594a8c0@hyperlynx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew: BIRD67.1 would not apply to any existing release. The Version number would have to be increased to 3.3 or some other number for ibischk to make the distinction. Bob Ross Mentor Graphics Matthew Flora wrote: > > Bob, > > Will this increase to the data point quantity limit be retroactive to IBIS > 3.0, 3.1, 3.2, or does it only apply to 3.3 and later? I ask because I want > to make sure that IBISCHK will make the distinction. > > Thanks, > Matthew Flora > Innoveda > From owner-ibis Fri Nov 3 14:03:45 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 eA3M3gX18911 for ; Fri, 3 Nov 2000 14:03:43 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA20956; Fri, 3 Nov 2000 14:00:30 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA03862; Fri, 3 Nov 2000 14:00:29 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A03357B.55B1487B@mentor.com> Date: Fri, 03 Nov 2000 14:00:27 -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: Matthew Flora , ibis@eda.org Subject: Re: IBIS BIRD64.3 - Alternate Package Models References: <3A005D62.DFABF07B@mentor.com> <00a001c045d9$1d0b1820$9594a8c0@hyperlynx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew: In BIRD64.3 comments have no special meaning. As I understand it, the basis of your suggestion is to prohibit spaces in package names if they are to be used with [Alternate Package Models]. That way the second and subsequent strings can be interpreted as the description in a similar manner as in [Model Selector]. I agree that this would be a practical limitation to bring the package model selection operation closer to [Model Selector]. However, at this time, I do not favor making this change over what is currently proposed. The only potential issues remaining are just syntax details and preferences. All of the suggestions appear to support the same functionality. Bob Ross Mentor Graphics Matthew Flora wrote: > > Bob, > > I am a bit concerned about giving comments special meaning. If we want to > allow a description to follow each entry in the package model list, then let's > define a syntax. > > I am perfectly happy for the [Alternate Package Model] (or whatever it ends up > being called) to have different syntax rules that [Package Model]. My point > is that you can simply disallow spaces in the package model names under this > keyword and then say that anything following the name is an optional > description that may be shown to the user. This would be less confusion if we > treat the [Alternate Package Model] as a keyword that works independent from > the [Package Model] keyword. In other words, a [Component] might be allowed > one of the two keywords, but not both. Don't worry too much about EDA tools > not supporting models with the new keyword, we already took that plunge when > many of the 3.0 keywords were added (e.g EBD). > > Regards, > Matthew Flora > Innoveda > From owner-ibis Fri Nov 3 14:59:10 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA3Mx8X19116 for ; Fri, 3 Nov 2000 14:59:09 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id WAA14749; Fri, 3 Nov 2000 22:57:14 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 03 Nov 2000 22:55:57 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 14:55:55 -0800 Message-ID: From: "Lorang, David D" To: "'Matthew Flora'" Cc: ibis@eda.org Subject: RE: IBIS BIRD68 - Clarify that Rising and Falling Waveforms Shoul d be Correlated Date: Fri, 3 Nov 2000 14:55:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Matthew, That's an interesting point. Here is what I am thinking should happen. When the simulator vendors see the clarified spec, they should modify their simulators so that if the simulator truncates any time from the front part of a waveform, it will truncate the same amount of time from all of the waveforms. (I'm assuming that they would not remove any part of an active transition, so the earliest waveform would control how much time might be truncated.) Then if an earlier model (that may not have waveforms correlated) is used on a newer simulator, the duty cycle will be still be in error, (but the simulation should run OK.) The older simulation duty cycle would have been erroneous anyway, because the waveforms were not correlated in the first place. Best regards, David Lorang Intel, Chandler david.d.lorang@intel.com (480)554-7891 -----Original Message----- From: Matthew Flora [mailto:mbflora@mail.hyperlynx.com] Sent: Friday, November 03, 2000 2:06 PM To: ibis@eda.org Subject: Re: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated All, I'm concerned about using older models where the [Rising Waveform]'s within a [Model] are time correlated to each other and the [Falling Waveform]'s within that [Model] are time correlated to each other, but no time correlation exists between the [Rising waveform]'s and the [Falling Waveform]'s. How is the simulator to recognize one of these models made prior to the clarification and a model made after the clarification? Would it be based upon the [IBIS_ver] value? Regards, Matthew Flora Innoveda ----- Original Message ----- From: "Bob Ross" To: Sent: Tuesday, October 24, 2000 12:54 PM Subject: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated > 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 Fri Nov 3 17:20:06 2000 Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA41K2X21848 for ; Fri, 3 Nov 2000 17:20:05 -0800 (PST) Received: from spiff.al.dynip.com (dialup-63.214.9.80.Seattle1.Level3.net [63.214.9.80]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id RAA00513; Fri, 3 Nov 2000 17:16:52 -0800 (PST) From: Al Davis To: "Matthew Flora" , Subject: Re: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit Date: Fri, 3 Nov 2000 15:12:01 -0800 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <39FA1D37.D1AD6D14@mentor.com> <00b701c045da$953af530$9594a8c0@hyperlynx.com> In-Reply-To: <00b701c045da$953af530$9594a8c0@hyperlynx.com> MIME-Version: 1.0 Message-Id: <00110315320703.02402@spiff.al.dynip.com> Content-Transfer-Encoding: 8bit On Fri, 03 Nov 2000, Matthew Flora wrote: > Will this increase to the data point quantity limit be retroactive to IBIS > 3.0, 3.1, 3.2, or does it only apply to 3.3 and later? I ask because I want > to make sure that IBISCHK will make the distinction. It seems to me that obviously it can only apply to future versions, because we cannot change products that have already been shipped to customers. I do not oppose an increase in the table size to something arbitrarily large, like 1000 points. Most tools use dynamic allocation anyway, and for those that don't it is usually just changing the subscript on an array. The only reason I see to not make it completely unlimited is to not require a major rewrite for simulators that use fixed allocation. I agree with the increase, because most is not all, and the standard should not arbitrarily prohibit the few cases where the increase in points is truly needed. However, in most cases the existing 100, or even 30, is plenty of points. Accuracy is limited elsewhere. Many models have only one waveform of each type, which is measured with a particular load. Even if the measurement is highly accurate with that load, the waveform is only a guess with any other load. Therefore, accuracy can be better by supplying additional waveforms with diffrerent loads, or loads to different reference voltages. This is true in the extreme with differential drivers, where the only correct load is the differential one, with the other end connected to the other side's driver. Another issue is proper choice of the time points. Many have 100 points, but all of the action is in 3 points. First, there are too few points in the action region. Second, and as important, data in the nearly steady region is often contaminated by noise or limited by numeric granularity. Consider ...... 0 0.22 1n 0.22 2n 0.22 3n 0.22 4n 0.23 5n 0.23 6n 0.23 7n 0.23 8n 0.24 9n 0.24 You might naively interpret this to mean the voltage is increasing slowly. What the data says is that it remains constant until 4ns, then jumps , remaining constant again until 8ns, jumping again. If this is driving a capacitor, you get a current spike at 4ns and 8ns, with no current elsewhere. But, likely the intent is that the voltage is increasing slowly. Accuracy is actually improved by removing points, in this case giving only 0, 4n, and 8n. From owner-ibis Fri Nov 3 17:20:04 2000 Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eA41JxX21846 for ; Fri, 3 Nov 2000 17:20:03 -0800 (PST) Received: from spiff.al.dynip.com (dialup-63.214.9.80.Seattle1.Level3.net [63.214.9.80]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id RAA00283; Fri, 3 Nov 2000 17:16:48 -0800 (PST) From: Al Davis To: "Matthew Flora" , Subject: Re: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated Date: Fri, 3 Nov 2000 14:30:52 -0800 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <39F5F720.17A3A450@mentor.com> <00a501c045d9$e07cd0f0$9594a8c0@hyperlynx.com> In-Reply-To: <00a501c045d9$e07cd0f0$9594a8c0@hyperlynx.com> MIME-Version: 1.0 Message-Id: <00110315042101.02402@spiff.al.dynip.com> Content-Transfer-Encoding: 8bit On Fri, 03 Nov 2000, Matthew Flora wrote: > I'm concerned about using older models where the [Rising Waveform]'s within a > [Model] are time correlated to each other and the [Falling Waveform]'s within > that [Model] are time correlated to each other, but no time correlation exists > between the [Rising waveform]'s and the [Falling Waveform]'s. How is the > simulator to recognize one of these models made prior to the clarification and > a model made after the clarification? Would it be based upon the [IBIS_ver] > value? It doesn't matter. With IBIS as it has been, this correlation is undefined. A simulator must create its own correlation, because without it it would be impossible to support diffrerential drivers or driver schedule, and and it would be difficult to do periodic signals. There is no basis to say that any other method might be superior to this one. Therefore, some of the existing simulators already do it this way, so are already in conformance with no changes. Others that used a different method of establishing correlation would have a choice. They could key off [IBIS_ver], or they could apply the Bird68 method everywhere. Simulations will be more consistent vendor to vendor if the Bird68 method is applied everywhere. For simulators that did it a different way, the method required here is usually a simplification. Models that assumed a different correlation have always simulated different on different simulators, with some matching what the creator hoped for, and some not. This Bird does not cause anything to break that wasn't broken already, and it makes an important clarification. I am guessing that the reason for proposing this is the author's frustration with the arbitrary differences caused by the fact that this is not defined. It is frustrating for simulator developers and modelers, too. Bird68 should be approved. Open question for simulator vendors: 1. Is yours already in conformance? 2. If not, how do you do it? As a member of the IBIS futures subcommittee, I would appreciate knowing this. You can reply privately if you don't want the world to know. From owner-ibis Fri Nov 10 12:08:26 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 eAAK8IX28793 for ; Fri, 10 Nov 2000 12:08:25 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA09781; Fri, 10 Nov 2000 12:05:01 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id MAA09077; Fri, 10 Nov 2000 12:04:58 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A0C54EB.DF24E5A9@mentor.com> Date: Fri, 10 Nov 2000 12:04:59 -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: ibis@eda.org Subject: IBIS Agenda 11/17/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 11/17/00 Bridge Number Reservation # Passcode (916) 356-9200 8-160063 1329512 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 - Status, BUG46 - BUG47 Change Waveform Mismatch Warning to Error LaBonte and Warning (Vote) - BUG48 Warning Message for Vref, Cref, Rref, Vmeas Ross/Mirmak in Wrong Models - BUG49 Warning Message for Unreferenced Models, Ross/Mirmak Submodels - BUG50 Error Message for Out of Order C_comp Values Ross/Mirmak BIRD61.1 - Enhanced Characterization of Receivers Ross (Vote) BIRD64.3 - Alternate Package Models Selector (Vote) LaBonte/Cohen BIRD65 - C_comp Refinements Ross BIRD66 - [Model Spec] Vref Addition (Vote) Ross BIRD67.1 - Increase V-T Table 100 Point Limit (Vote) Ross/Dodd (Vote) BIRD68 - Clarify that Rising and Falling Waveform Larang Tables Should be Correlated New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Wed Nov 15 11:54:49 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 eAFJsjX26908 for ; Wed, 15 Nov 2000 11:54:48 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA23991; Wed, 15 Nov 2000 11:51:22 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA02523; Wed, 15 Nov 2000 11:51:19 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3A12E937.A25158BA@mentor.com> Date: Wed, 15 Nov 2000 11:51:19 -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: ibis@eda.org Subject: IBIS Meeting Friday 11/17/00 Discussions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: This is a reminder that for the IBIS meeting Friday we will be considering and voting on 4 BIRDs (BIRD61.1, BIRD64.3, BIRD66, and BIRD67.1). They can be reviewed at: http://eda.org/pub/ibis/birds/index.html Also, we will be resolving BUG47 and classifying new BUGS BUG48, BUG49, and BUG50. They can be reviewed at: http://eda.org/pub/ibis/bugs/ibischk/ Bob Ross Mentor Graphics From owner-ibis Thu Nov 16 11:44:28 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 eAGJiOX06640 for ; Thu, 16 Nov 2000 11:44:27 -0800 (PST) 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 LAA21591 for ; Thu, 16 Nov 2000 11:41:08 -0800 (PST) Received: from cadence.com (d158140105142 [158.140.105.142]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id OAA03377 for ; Thu, 16 Nov 2000 14:41:08 -0500 (EST) Message-ID: <3A143852.EAB2FB1E@cadence.com> Date: Thu, 16 Nov 2000 14:41:06 -0500 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: IBIS Models web page updated Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as LAA21591 at Thu Nov 16 11:41:08 2000 The IBIS Models web page at http://www.eigroup.org/ibis/models.htm has been updated. This includes new links listed during the last IBIS open forum meeting: ************************************************************** ... 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 ... ************************************************************** Any suggestions for corrections, additions, or enhancements to this web page are welcome. Please send them to me (as IBIS Librarian). Mike LaBonte Cadence Design Systems From owner-ibis Fri Nov 17 05:34:40 2000 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eAHDYbX11176 for ; Fri, 17 Nov 2000 05:34:39 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA15132 for ; Fri, 17 Nov 2000 06:31:23 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA09533 for ; Fri, 17 Nov 2000 06:31:23 -0700 (MST)] Received: from mtcux01.mttc.corp.mot.com by m-il06-r1.mot.com with ESMTP for ibis@eda.org; Fri, 17 Nov 2000 06:31:22 -0700 Received: from mtc44 (mtc44.mttc.corp.mot.com [175.57.1.144]) by mtcux01.mttc.corp.mot.com (8.9.3+Sun/8.9.1) with SMTP id OAA09400 for ; Fri, 17 Nov 2000 14:27:41 -0100 (GMT) Reply-To: Razvan Ene-ARE007 From: "Razvan A Ene" To: Subject: Unsubscribe Date: Fri, 17 Nov 2000 14:27:57 +0100 Message-Id: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C050A2.94716F80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-MS-TNEF-Correlator: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C050A2.94716F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Unsubscribe ------=_NextPart_000_0014_01C050A2.94716F80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjkNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCwARAA4AGwAAAAUAIQEB A5AGAIQKAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADAAAAFVuc3Vic2NyaWJlAAIBcQABAAAAFgAAAAHAUJoynCSZ12K8YRHUsGkAsNAV3NwAAAIB HQwBAAAAGgAAAFNNVFA6QVJFMDA3QEVNQUlMLk1PVC5DT00AAAALAAEOAAAAAEAABg4AqpgQmlDA AQIBCg4BAAAAGAAAAAAAAAA6tLXhLTXUEa/4ALDQFdzcwoAAAAsAHw4BAAAAAgEJEAEAAACLBgAA hwYAAHcQAABMWkZ161pxXgMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKk A2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQ A9T7Ef8TC2IT4RRQE7IY9BTQEwcTAoMzNBGOMjM4RRdUIAdtIENFGgQ1Txp/FEAbrxy1eXIaBDe5 EY4xNhYxHv8DgkcJ0X5rGgQbkSEODlAiLwNzVOsIcBoEOSRPNyDRJZ8DgpAoSGViCXB3KQKD+xRQ J483G58ptgcQAaAN4GcqlRYxIQ04NixPHLRC/QdAdA3gKqQlYRZsG3gHE30dBjQPwDIuHrcztSBV NN8dkRZsIegztCOINC/BN273JWYztCbmNCDRN20olzO0/yosLDE8zjM8LbwncTdtL7evM7QxRgKR COY7CW8wRb/6ZQ4wNUbqSAFHv0jJRtT/SPJHX0svSu1Kb0ifRu8QYPwyOFC6UdFRj1KZRtRSwr9R L1T/VL1UP1JvVjQ5DlAfWYRa4VMDWuACgnN0eapsB5BoCeB0AABxAyE8bGkBQAUQAUAD8GRj7HRs CrEAYHMKsF4gFuARXmJudW0CAGFhdcR0bwBgZGp1XFAFEHhnaHRdgQoBXVAKAWn5AZBwMAMxFjIM AQ9XEBjPCNAJwF3gYiNucGJ5ZBThAzBzbmV4FzAHsAWw5wDAAnMTEGNzD5ADMF/g0mRhQGl2E4BE ARBfkGkxYCBQCsBhCcBhYGhsIEYCIVwTMR2QXRJm9GktD5A4YNJp012cKlC8ZHIJUGtyFqBrcnc3 If8qUF6AAdBm0V6PX59gpmnT72FPYl9jb2R+Ym0wCYACIJ9wcWVjaTBn8GChdC1okBUDYTowMG92 MFN1YgpqBZB0djBEYXRl/jpo5C/AaW9qf2uPbJ9tr/9uv2/MXKB9MAuADhJwcQwwf3CkDlBxL3I/ c090X3VnUvZlZ1AXASAqMH0wBJBo5P8g0Hf/eQ96H3svfD4IYF4Q7QuAZVyAZ1BsAUB9P35PLX9U MI9wCNBiCrB0OPt/6HEGMhpgEBaRMYHkE1DxF3Bvb2aCP4NPhFeQAPOFcAtQeS9ooInQCxGF5f5z aOQsMIbfh++I/4oPfD//jQ9vz3DfgW+TL5Q/lU+WUv92UnX0dykncF0fXi+cH2BP+55kj7M5nq+f v6DPod+ESHGq4ERvY6ggCfAFQE3fnnBmNpsTZwarB2MAQK6of2ayp2CFoQIgM+FcQAWgbdpwE2JF AMADEFNcYgHQ/VwTMgBQpf+nD6gfqS+eb7+rz6zfre+EC7XwtNAttPLXBgC5YLQAdAhwZUTjExAF RdB2AlEge1VuaxUTUHcV0X0AsXJnbOwxMRpRwkJywpch0C6A+yDQwkJiwpIDMLbhwdC3EPuZwQGA bnawAGAJ8GcAsABNkmF4C2ACQG95CfBc/WWAcFygACALkBNQZ8GZwJ+3kADhAjACYACAYmQMMPsT UQqwYwEQBbBnwAIBZfBRfzJlXGgFsHrGEmTuZ8JCC4HK8GjJIy+gAUE8Z3bLucpxuWCd4Tcw5wBQ zEHNNTk4GmDLgspw/nfNw870dsDHIABwCzDGEZdcYLOwDlB2CJB3awuA/mQaYNDyBPAHQBBhAUAO AN+ZklywuPDSVQIQb7mQt5D9leB0weCMUcVi0+e5gADA/7iwt5CSYciQuYC48QkyuSD/jHACUAdA C5DW8QJR0UG2UO/T8NHhtxACYHfXswJRACDnCcC2UMWQcmvJkbHiFyEfEvJ3QLSAxoETgEM6XOpc dYBvaEFtaJADEAeQPdswTQ3gA2Cz4AGAIE/3ASAN4MpQXNzmD5PHALTy+i6EIHTCIBcQtxCWcLny /2WAAUDF4dXwBJDKUN7yjELdvJIzE/De5GeUY8FhEwLzAIAFkGx2woDicQ5wZfD/4nIBkAAg4wLR QbBBAcHicT8W4A9wAAC4MAzQAZAgLv/AtOKGDlDjIsfR44/kn+WvfmwPwLgwBYHnX+hv6X9svxpg uDDYIOcv6+/s9Cnl7O8dkOq/75/s1GIqEAKR8L//4rMvwO5v8y/0P/VP4uAg0P/2kuNv9//5D+Xs LDD2n/wf//0v/j/i4Cdw+x8ArwG/AsT/Cvm2QLYvtz+4T7lfum+7f9+8j72bRRGyVsGQc3agtFCh C5BiZQ0KB5IgEgwnRQKyoRLmfQAUYAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA A4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA ACdqAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAA wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB AAAAAQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAgg BgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAOrS14S011BGv+ACw0BXc3AIB+g8BAAAAEAAAADq0 teEtNdQRr/gAsNAV3NwCAfsPAQAAAI8AAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRM TAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xtdGM1OVxMb2NhbCBT ZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAD AP4PBQAAAAMADTT9NwAAAgF/AAEAAAA0AAAAPE5FQkJLUFBJREtBRUdGUEVQQk9KRUVERENGQUEu YXJlMDA3QGVtYWlsLm1vdC5jb20+AAMABhAKE+hDAwAHEAsAAAADABAQAAAAAAMAERAAAAAAHgAI EAEAAAAMAAAAVU5TVUJTQ1JJQkUANlk= ------=_NextPart_000_0014_01C050A2.94716F80-- From owner-ibis Fri Nov 17 10:40:41 2000 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eAHIeaX13343 for ; Fri, 17 Nov 2000 10:40:40 -0800 (PST) Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id SAA24787 for ; Fri, 17 Nov 2000 18:37:16 GMT Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 10:37:16 -0800 Message-ID: From: "Mirmak, Michael" To: "'ibis@eda.org'" Subject: Proposed revisions to BUG49; comments? Date: Fri, 17 Nov 2000 10:37:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" IBIS folks, In today's IBIS Open Forum Meeting, several people made very useful suggestions regarding IBISCHK BUG49; thanks to everyone who participated. To address these comments, I have added a section called "ADDITIONAL NOTES" to the original BUG49 proposal. The updated text is shown below. Discussion is welcome. If the additions resolve the Forum members' concerns, I will file the updated text with Bob Ross for discussion and a vote at the next Open Forum meeting. Thanks again! - Michael Mirmak, Intel Corp. michael.mirmak@intel.com **************************************************************************** ** ********************* IBIS GOLDEN PARSER BUG REPORT FORM ********************* **************************************************************************** ** INSTRUCTIONS To report a bug in the IBIS golden parser. Please fill out the top part of the following form and send the complete form to ibischk-bug@vhdl.org. A list of reported bugs will be maintained on vhdl.org. **************************************************************************** ** PARSER VERSION NUMBER: 3.2.5 PLATFORM (SPARC, HP700, PC, etc.): HP OS AND VERSION: HP_UX (B.10.20) REPORTED BY: Michael Mirmak, Intel Corp. DATE: November 2, 2000 REVISED: November 17, 2000 DESCRIPTION OF BUG: "Dangling" models, present but not referenced or used in the file, are not flagged to the user. These include [Model]s which are not described in [Pin], [Model Selector] or [Driver Schedule] sections and also [Submodel]s which are not referenced by any [Add Submodel] declaration. Some indication -- most appropriately, a warning -- should be made of the lack of reference for these models and model fragments. An example: WARNING (line xxx) - Model xxx not referenced in [Pin], [Model Selector] or [Driver Schedule] sections. For Submodels: WARNING (line xxx) - Submodel xxx not referenced by [Add Submodel] keyword. This bug also applies to DOS32 IBISCHK3 v3.2.5. ADDITIONAL NOTES: As pointed out by Mike LaBonte of Cadence, this BUG should also apply to [Model]s which are not referenced in a [Series Pin Mapping] section. Therefore, a "dangling" [Model] is one which, while syntactically correct, is not referenced in [Pin], [Model Selector], [Driver Schedule] or [Series Pin Mapping] sections. Ian Dodd of Cadence raised the point that, for devices such as an FPGA, an unreferenced [Model] may be desirable in a user-ready model (such a [Model] might represent a available programming option which may or may not be implemented after the user configures the device). In addition, generating a message for every instance of an unreferenced [Model] may be unnecessarily confusing to the user. To address the above, the following changed messages are proposed: For one or more instances of an unreferenced [Model]: WARNING (line xxx) - [Model] zzz not referenced in [Pin], [Model Selector], [Driver Schedule] or [Series Pin Mapping] sections. Only one instance of the above warning message should be generated, for the first unreferenced [Model] in the file. Multiple unreferenced [Model]s in an IBIS file should NOT generate multiple warning messages. For Submodels: WARNING (line xxx) - [Submodel] zzz not referenced by [Add Submodel] keyword. As [Submodel]s should not exist independently of a referencing [Add Submodel] keyword, the above message should be generated for EVERY instance of an unreferenced [Submodel]. INSERT IBIS FILE DEMONSTRATING THE BUG: |*********************************************************************** | [IBIS Ver] 3.2 [File Name] bug49tst.ibs [File Rev] 0.0 [Date] 02-November-2000 [Source] File created from specification | [Disclaimer] (C) Copyright 2000 Intel Corp. All rights reserved This model is for demonstration purposes only. | | [Component] GENERIC_IBIS [Manufacturer] Intel Corp. | [Package] | typ min max R_pkg 6.0mO 5.0mO 7.0mO L_pkg 5.0nH 2.0nH 8.0nH C_pkg 1.0pF 0.5pF 1.5pF | | [Pin] signal_name model_name R_pin L_pin C_pin A1 TestSignal1 TestModel A2 TestSignal2 TestModel | |************************************************************************ | [Model] TestModel Model_type Output Polarity Non-Inverting Cref = 10.0pF C_comp 5.00pF 4.00pF 6.00pF | | [Temperature Range] 27.00 100.00 0.00 [Voltage Range] 3.30V 3.00V 3.60V [Pulldown] | voltage I(typ) I(min) I(max) | -3.3000 -20.0A -25.00A -15.00A 0.0000 0.0A -5.00nA 5.00nA 3.3000 40.00mA 32.00mA 48.00mA 6.6000 10.0A 12.0A 8.00A | [Pullup] | voltage I(typ) I(min) I(max) | -3.3000 10.00A 12.00A 8.00A 0.0000 0.0uA -0.30uA 0.30uA 3.3000 -65.00mA -40.00mA -80.00mA 6.6000 -22.00A -25.00A -19.00A | [Ramp] | variable typ min max dV/dt_r 0.35/1.6n 0.25/1.8n 0.45/1.5n dV/dt_f 0.35/1.6n 0.25/1.8n 0.45/1.5n R_load = 50.000 | |*************************************************************************** | [Model] TestModel2 Model_type Output Polarity Non-Inverting Cref = 10.0pF C_comp 5.00pF 4.00pF 6.00pF | | [Temperature Range] 27.00 100.00 0.00 [Voltage Range] 3.30V 3.00V 3.60V [Pulldown] | voltage I(typ) I(min) I(max) | -3.3000 -20.0A -25.00A -15.00A 0.0000 0.0A -5.00nA 5.00nA 3.3000 40.00mA 32.00mA 48.00mA 6.6000 10.0A 12.0A 8.00A | [Pullup] | voltage I(typ) I(min) I(max) | -3.3000 10.00A 12.00A 8.00A 0.0000 0.0uA -0.30uA 0.30uA 3.3000 -65.00mA -40.00mA -80.00mA 6.6000 -22.00A -25.00A -19.00A | [Ramp] | variable typ min max dV/dt_r 0.35/1.6n 0.25/1.8n 0.45/1.5n dV/dt_f 0.35/1.6n 0.25/1.8n 0.45/1.5n R_load = 50.000 | |*************************************************************************** [Submodel] Submodel Submodel_type Dynamic_clamp | [Power Clamp] | voltage I(typ) I(min) I(max) | -3.3000 10.00A 12.00A 8.00A 0.0000 0.0A 0.30A 0.30A 3.3000 0.00A 0.00A 0.00A 6.6000 0.00A 0.00A 0.00A |*************************************************************************** | [End] | | |Parser 3.2.5 responds with | |IBISCHK3 V3.2.5 | |Checking bug49tst.ibs for IBIS 3.2 Compatibility... | |Errors : 0 | |File Passed | **************************************************************************** ** ******************** BELOW FOR ADMINISTRATION AND TRACKING ******************* **************************************************************************** ** BUG NUMBER: 49 SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] PRIORITY: [HIGH, MEDIUM, LOW] STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG] FIXED VERSION: FIXED DATE: NOTES ON BUG FIX: **************************************************************************** ** **************************************************************************** ** From owner-ibis Fri Nov 17 17:37:20 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eAI1bIX14714 for ; Fri, 17 Nov 2000 17:37:19 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id BAA01749 for ; Sat, 18 Nov 2000 01:35:22 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 18 Nov 2000 01:34:04 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 17:34:03 -0800 Message-ID: From: "Nelson, Jeffrey T" To: ibis@eda.org Cc: "Nelson, Jeffrey T" Subject: Unsubscribe Date: Fri, 17 Nov 2000 17:34:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > Unsubscribe > > > From owner-ibis Sun Nov 19 18:40:28 2000 Received: from tiger1.nownuri.net (tiger1.nownuri.net [203.238.128.52]) by server.eda.org (8.11.0/8.11.0) with ESMTP id eAK2eQX22797 for ; Sun, 19 Nov 2000 18:40:27 -0800 (PST) Received: (from k3@localhost) by tiger1.nownuri.net (8.9.0/H/8.9.0) id LAA25802; Mon, 20 Nov 2000 11:36:53 +0900 (KST) Date: Mon, 20 Nov 2000 11:36:53 +0900 (KST) From: ÀÌÁ¾¼® Message-Id: <200011200236.LAA25802@tiger1.nownuri.net> To: ibis@eda.org Subject: I want to join IBIS Open Forum MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR I work for Hyundai Electronics Inc. My department is Memory application test ... My speciality is system-level verification... --MIME Multi-part separator-- From owner-ibis Tue Nov 21 10:38:44 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 eALIceX05635 for ; Tue, 21 Nov 2000 10:38:42 -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 NAA16241 for ; Tue, 21 Nov 2000 13:35:17 -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 NAA20567 for ; Tue, 21 Nov 2000 13:35:12 -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 KAA11873 for ; Tue, 21 Nov 2000 10:33:19 -0800 (PST) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id KAA14906; Tue, 21 Nov 2000 10:34:52 -0800 Date: Tue, 21 Nov 2000 10:34:52 -0800 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200011211834.KAA14906@f22.innoveda.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes (11/17/00) Date: 11/21/00 SUBJECT: 11/17/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*, Michael Mirmak* 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, Yong Phan* 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 December 8, 2000 (916) 356-9200 8-177128 7335175 December 22, 2000 (916) 356-9200 8-177130 3124243 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 Michael Mirmak joined from Intel. Michael has been involved in modeling for about four years and works closely with Arpad Muranyi. Yong Phan of Micron Technology is a new member of a signal integrity group. He has previously done memory design. Yong's interest in IBIS is related to signal integrity issues. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that Philips Semiconductor has purchased an ibischk3 parser source code license. Cecilia Fleming reported that she will be sending out invoices for IBIS Open Forum Year 2001 membership in the beginning of December 2000 so that members can choose to use the remainder of the 2000 budget, if needed. Guy de Burgh has some updated contact information. Bob asked Guy to send to Cecilia his current list. REVIEW OF MINUTES AND AR'S The October 27, 2000 IBIS Minutes were approved with the following changes: Greg Ledenbach's position was changed from Secretary to International Secretary of IEC TC93. The EIA IBIS Open Forum official web site at the end of the minutes needs .org added. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported that Syed Huq got several responses regarding updating the Roster. Bob Ross reported that two more academic papers now exist at the link: http://www.eln.polito.it/Ricerca/emc/papers.html The first one is: I.S.Stievano, I.A.Maio, "Behavioral Models of Digital IC Ports from Measured Transient Waveforms," Proceedings of the 9th Topical Meeting on Electrical Performance of Electric Packaging (EPEP2000), Scottsdale-Phoenix, Arizona, October 2000. The second is: F.G.Canavero, I.A.Maio, I.S.Stievano, "Black-box Identification of Digital Devices for Radiation Prediction," Proceedings of the 4th European Symposium on Electromagnetic Compatibility, Brugge Belgium, September 2000. Presentations are given for both papers. Both of these papers along with another previously reported paper mention IBIS. However they suggest a more general behavioral black-box approach. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob found some more Motorola links for clock drivers, http://www.mot-sps.com/clocks/dtools/designtools.html Mike LaBonte reported that he has updated the Models link of the IBIS Home page. OPENS FOR NEW ISSUES None. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming stated that the header information reported previously has been forwarded to IEC. She will get some further status from Greg Ledenbach, International Secretary of IEC TC-93. - 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) - Jean-Claude Perrin stated that the proposed new document has been approved by IEC TC93 as a new CDV. Upon approval, the document will be issued as a public report for other committees including the IBIS Open Forum to consider. Jean-Claude plans to present the document at the European IBIS Summit Meeting scheduled in March 2001. - JEDEC JC-16 - Modeling and Testing - Bob Ross stated, as previously reported, that 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. Mike LaBonte plans to attend. FUTURE SUMMIT PLANNING Bob Ross stated that 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 is planning for 50 lunches. Milt commented later that all the arrangements have been made. 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. Bob stated that he expects to get the first notice out in early December. Bob also stated that early plans have been made 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 indicated that four companies are now planning to co-sponsor the meeting: Cadence, Innoveda, Mentor Graphics and Zuken (Incases). Information on these events exists at the Upcoming Events Links of the IBIS Home Page. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo reported no further activity on a previously reported model. CONNECTOR PROPOSAL REVIEW Ian Dodd reported that the Connector Working group is developing proposals to automatically name pins. It is meeting weekly. More members are welcome. Bob Ross noted that Meetings were held October 31, November 9 and November 14, 2000 and the next one is scheduled November 21, 2000. IBIS FUTURES (IBIS-X, API, BIRDxx) Mike LaBonte reported good progress on the last meeting held November 7, 2000, which now meets about every two weeks. Stephen Peters has volunteered to develop a top-level specification document. The Working Group has been focused on the internal details of the macro language and needs a more general document. Mike also stated that new members are welcome, particularly anyone interested in writing documents. The next meeting is scheduled for November 21, 2000. IBISCHK3 BUG TRACKING Bob Ross gave the current status of the ibischk3 bug fixes being done by Atul Agarwal. BUGs 36 - 46 have been fixed. BUG34 is still pending along with final resolution of BUG47. Bob indicated that Atul had questioned what was intended regarding BUG46. Specifically, it stated that certain min-typ-max values should be entered so that the min values are less than or equal to the typ value, and the max value is greater or equal to the typ value. An older fix for BUG19 just reported if the typ value was outside of the min-max range and did not test if whether the min column was numerically smaller than the max column. It is sometimes not clear when to apply the more stringent test. For example, the voltage range and voltage reference values could have negative values with the max voltage larger in magnitude, but more negative than the other voltages. The resolution was to apply BUG46 to just the [Package] entries L_pkg, R_pkg, and C_pkg. That was the concern that caused BIRD46 to be initiated. - BUG47 - Change Waveform Mismatch Warning to Error and Warning Bob introduced BUG47 by noting the updates by Matthew Flora per the AR of the October 27, 2000 meeting. The updates clarified that proposed message applied for both Error and Warning messages. Also the message will state V_fixture_min and V_fixture_max if these values are selected instead of V_fixture for the end point test between V-T data and V-I data. The group approved BUG47 and scheduling to fix it in a future ibischk3 release. - BUG48 - Warning Message for Vref, Cref, Rref, Vmeas in Wrong Models Bob introduced BUG48 authored by Michael Mirmak. There are two problems. No Warning is issued when Vmeas, Vref, Cref, and Rref are included in models such as Input or Terminator models which cannot be outputs. Also, a misleading Warning is issued based on the output not passing through the Vmeas thresholds for Input models. Such a Warning is inappropriate because it implies configuring the model as an output. Michael added that BUG48 is similar to the test in BUG42 which issues warnings when input thresholds exist on models without any input mode. After some discussion, BUG48 was classified as ANNOYING (because of the inappropriate Warning), LOW, and OPEN. It will be scheduled to be fixed in a future ibischk3 release. - BUG49 - Warning Message for Unreferenced Models, Submodels Michael introduced BUG49 which deals with unreferenced or dangling models within IBIS files. Michael indicated that an unreferenced model may be produced by a model developer putting in a similar, but wrong name somewhere else. There is no Warning for such a mistake. Ian Dodd stated that for FPGA models, the developer might want to list a set of models that are available. In this case another Warning message would just add to the clutter of Warning messages that a user needs to go through to find the significant messages. The model developer might find some messages useful, but the model user might want a more limited set. Ian suggested that we might want to consider an optional command line to specify what messages to issue. Bob Ross objected to this approach because all messages would have to be reviewed. Michael suggested that Submodels might be treated differently than models. Submodels are not used for FPGAs. Someone mentioned that the message did not discuss models issued by the [Series Pin Mapping] keyword. Bob stated that we need more time to consider BUG49. Comments can be made on the IBIS reflector. BUG49 was classified as ENHANCEMENT, LOW, and OPEN. More discussion is planned at the next meeting to decide on how to resolve BUG49. - BUG50 - Error Message for Out of Order C_comp Values Michael introduced BUG50 to report an Error if the C_comp values were not positioned by value appropriately in min, typ, and max columns. Michael noted that the positioning of the values was specified in IBIS in the Notes on Data Derivation Section. Bob suggested a Warning message be issued since there might be some legacy models with incorrectly positioned values. Michael pointed out that at least one EDA tool issued an Error if the C_comp values were not in the correct positions. Michael encountered this problem while working with real models. Roy Leventhal added that IBIS model development discipline needs to be enforced. Bob agreed to accept BUG50 issuing an Error message. BUG50 was classified as ANNOYING, LOW, and OPEN. After future discussion, the group approved scheduling BUG50 to be fixed in a future ibischk3 release. Bob stated that the ibischk3 release process involves checking the test cases and building executables for several operating systems. Matthew normally builds the Windows executable. Syed Huq normally builds the Linux executables. Guy de Burgh will build the remaining executables for various Unix operation systems (a job Chris Rokusek has done in the past). Bob would like a release this year so that one or two important fixes that make ibischk3 consistent with the IBIS Specification are distributed. Based on the discussion Bob will communicate with Atul regarding what is needed for a quick release of ibischk3. Bob will ask if BUG47 and BUG34 can be included in the current release in a timely manner. Otherwise the fixes to BUG34 and possibly BUG47 will be deferred. The additional BUGs after BUG47 will be not be included in the current release. BIRD61.1 - ENHANCED CHARACTERIZATION OF RECEIVERS Bob Ross stated that the committee resolution for the BIRDs could be Yes, No, Abstain, or Defer. Unlike some administrative decisions, the IBIS Open Forum would like to achieve at least nearly unanimous consensus on technical issues rather than rely on legal, majority approval. A BIRD approval is just the first step. The actual document needs to be approved by at least an 80 percent vote to show industry support and consensus. So one can vote to Defer in order to spend more time on details to avoid future issues. Bob briefly introduced BIRD61.1. It was originally introduced in August 1999. BIRD61.1 introduces for Input models the keyword [Receiver Delay] and provides subparameters Start_point, End_point, and Slope to describe input test waveforms. Tables of delays in terms of these parameters are proposed and the EDA tools are supposed to build an internal models. These models would capture the delay variations seen by the actual input signal. Stephen Peters, a co-author, stated that BIRD61.1 seems to lack support. Some people felt that such variations would be better handled in the IBIS-X approach which actually specifies the building an internal model. BIRD61.1 just gives the external, test information from a black-box point of view. So the committee did not make any progress with BIRD61.1. Ian Dodd and Bob both indicated that they did not know how to use the information given in BIRD61.1 to create models. Bob added that it had not been prototyped as suggested. Bob did not even know how much data is needed. Bob also mentioned that Al Davis was going to contact D.C. Sessions to find out more details, but Bob thought the intent was related to how the functions might be implemented in IBIS-X. Bob called for a vote. BIRD61.1 was rejected by a 1 YES (by mail), 7 NO votes. BIRD64.3 - ALTERNATE PACKAGE MODELS Mike LaBonte introduced BIRD64.3 by indicating that the functional intent of BIRD64.3 for different package models was similar to the [Model Selector] for models. However, there were some differences. Mike issued BIRD64.3 to deal with some discussion and concerns expressed at the October 27, 2000 meeting and some IBIS reflector discussions. Bob Ross stressed that the functional details had not changed. The current changes were really based on syntax preferences and conventions. Bob still had a few details to consider. We have decided not to follow the same conventions as in [Model Specification] and have even made changes to reinforce the differences. Mike indicated that the [Model Selector] uses the first model as the default, whereas in [Alternate Package Models] the default package model is still given by [Package Model] keyword. In response to a question, Bob stated that we could approve BIRDs with small, minor changes agreed upon at the IBIS meeting. We would issue the new BIRD with minor revisions after the meeting. However, if the changes were substantial and changed the functionality, a new BIRD would need to be issued and remain stable for two weeks before voting to provide the opportunity for adequate review. Roy Leventhal asked if BIRD64.3 could handle devices with package variations based on thermal effects. Mike stated that package model list could be based on any effects. Bob wanted "may" to be changed to "shall" in two locations to conform to some grammatical guidelines for standards. "May" indicates permission or choice. Bob questioned the meaning that [Alternate Package Models] follow [Package Model]. Does this mean somewhere after or immediately after. While the [Alternate Package Models] would normally be positioned immediately after the [Package Model] keyword, there is no technical reason to restrict its location under [Component]. Most keywords do not have a location restriction. Mike LaBonte did not see any reason to restrict the location. So the Usage rules sentence should be changed to remove the "follows" restrictions. The only restriction remains that [Package Model] needs to exist for [Alternate Package Models] to be syntactically correct. Bob also wanted a clarification note that the package model named in [Package Model] can be repeated in the list of models under [Alternate Package Models]. Bob felt that a user might change the default, but would not also want to remove or add an entry into the [Alternate Package Models] list. Mike agreed to this addition. Finally, Bob stated he preferred a different name such as [Additional Package Models] or [Package Model List]. No one supported this at this time, so Bob will accept the existing [Alternate Package Models] name. Because we were running out of time, Bob deferred having a quick vote (and possibly being cut off at mid-vote. This will give an opportunity to issue BIRD64.4 with the editorial changes. The vote on BIRD64.4 is scheduled for the next meeting. AR - Bob Ross work with Mike LaBonte to issue BIRD64.4 with the editorial changes agreed upon at this meeting. BIRD65 - C_comp REFINEMENTS Not discussed. BIRD66 - [Model Spec] Vref ADDITION Scheduled for a vote, but not discussed. BIRD67.1 - INCREASE V-T TABLE 100 POINT LIMIT Scheduled for a vote, but not discussed. BIRD68 - CLARIFY THAT RISING AND FALLING WAVEFORM TABLES SHOULD BE CORRELATED Not discussed. NEXT MEETING: The next teleconference meeting will be on Friday, December 8, 2000 from 8:00 AM to 10:00 AM. BIRD64.4, BIRD66, and BIRD67.1 are 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.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Nov 21 13:29:16 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 eALLTDX06373 for ; Tue, 21 Nov 2000 13:29:14 -0800 (PST) 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 NAA07925 for ; Tue, 21 Nov 2000 13:25:56 -0800 (PST) Received: (from mrl@localhost) by zip.Cadence.COM (8.9.3/8.8.5) id QAA04464; Tue, 21 Nov 2000 16:25:55 -0500 (EST) Date: Tue, 21 Nov 2000 16:25:55 -0500 (EST) From: Mike LaBonte Message-Id: <200011212125.QAA04464@zip.Cadence.COM> To: ibis@eda.org Subject: BIRD 64.4 - Alternate Package Models X-Received: By mailgate2.Cadence.COM as NAA07925 at Tue Nov 21 13:25:56 2000 Here is BIRD 64.4, with rewording by Bob Ross to implement the comments from the last IBIS open forum meeting. We were pretty close to voting on it last time, so hopefully it is now ready. The last paragraph describes the changes made. Mike LaBonte Cadence Design Systems ******************************************************************************* ******************************************************************************* BIRD ID#: 64.4 ISSUE TITLE: Alternate Package Models REQUESTER: Arpad Muranyi, Intel; Mike LaBonte, Cadence DATE SUBMITTED: 10-25-99, 11-19-99, 10-8-2000, 11-1-2000, 11-20-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 [Alternate Package Models] shall contain a list of package model names that the simulator can pick from, in addition to the default package model name given by the [Package Model] keyword. The package model names listed under the [Alternate Package Models] 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: [Alternate Package Models] [End Alternate Package Models] | Required: No. | Description: Used to select a package model from a list of package models. | Sub-Params: None. | Usage Rules: The [Alternate Package Models] keyword can be used in addition | to the [Package Model] keyword. [Alternate Package Models] |* shall be used only for components that use the [Package Model] | keyword. | | Each [Alternate Package Models] keyword specifies a set of | alternate package model names for only one component, which | is given by the previous [Component] keyword. The [Alternate |* Package Models] keyword shall not appear before the first | [Component] keyword in an IBIS file. The [Alternate Package |* Models] keyword, when used, is in the same [Component] |* section, and must be followed by an [End Alternate Package |* Models] keyword. | | All alternate package model names must appear below the | [Alternate Package Models] keyword, and above the following | [End Alternate Package Models] keyword. The package model | names listed under the [Alternate Package Models] must follow | the rules of the package model names associated with the | [Package Model] keyword. The package model names correspond | to the names of package models defined by [Define Package | Model] keywords. Simulation tools may offer users a facility | for choosing between the default package model and any of the | alternate package models, when analyzing occurances of the | [Component]. |* |* The package model named by [Package Model] can be optionally |* repeated in the [Alternate Package Models] list of names. |============================================================================= | [Alternate Package Models] | 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. [End Alternate Package Models] | ****************************************************************************** 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. This was proposed in the original BIRD. Add a secondary keyword to list package models that are alternates to the default package model given by [Package Model]. This is the currently proposed solution. ****************************************************************************** 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 existing rules this is not possible, because 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 [Alternate Package Models] 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 description 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 [Alternate Package Models] should be used to specify 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 [Alternate Package Models] list, since these variations would normally require changes to other elements of the component model. Revision 64.3 changes 10-31-2000, Mike LaBonte: At the 10-27-2000 IBIS forum meeting it was pointed out that the original [Package Model Selector] keyword proposal was inconsistent in usage with the [Model Selector] keyword. A key point is that each [Model Selector] has a name that can be referred to in the [Pin] section as if it were the name of a [Model]. The [Package Model Selector] keyword, as proposed, had no name. This was ponted out earlier by Bob Ross. The [Alternate Package Models] proposal avoids the use of a named selector, and retains the usefulness of the existing [Package Model] keyword. At this time an [End Alternate Package Models] keyword is introduced, to reduce potential parsing ambiguity for the list of alternate package model names. Along with this change the title of the BIRD changes from "Package Model Selector" to "Alternate Package Models". A usage note explaining that the name values in the list refer to [Define Package Model] names is also added. BIRD64.4 is issued to deal with comments made at the November 17, 2000 IBIS Meeting. The verb "may" was changed to "shall" to conform with grammar guidelines for standards documents. A sentence was revised to remove an ambiguous reference that [Alternate Package Models] follows [Package Model]. Finally, a statement is added to clarify that the [Alternate Package Models] list can contain the default package model that is named in [Package Model]. EDA tools can easily detect duplicate names, and during the process of changing the default through editing, the user would not have to change the list under [Alternate Package Models]. ******************************************************************************