Re: IBIS BIRD64.1 - Package Model Selector

To follow up on my comments on BIRD 64.1 at the IBIS forum
teleconference today, I would like to propose that:

1) The BIRD should declare scoping requirements
It is not stated where the [Package Model Selector] can appear
in an IBIS file, and to which [Component] it applies. We might
add a paragraph like:

#############################################################
Each [Package Model Selector] keyword specifies the set of
package models for only one component, which is given by
the previous [Component] keyword. The [Package Model Selector]
keyword may not appear before the first [Component] keyword
in an IBIS file.
#############################################################

2) [Package Model] and [Package Model Selector] are mutually exclusive
When [Package Model Selector] is used, [Package Model] makes
no sense. The [Package Model] keyword *could* give the name of
the default package model, but I agree with the idea of the
default as specified by the first [Package Model Selector] value.
We might add a paragraph like:

#############################################################
The appearance of the [Package Model Selector] keyword after
a [Component] keyword overrides any [Package Model] keyword
that may appear often the same [Component] keyword.
#############################################################

Concerning Roy Leventhal's comment on how [Package Model Selector]
might be used, I see 2 issues:

A) The assignable package models must have the same pinouts.
Although some die can be shipped in various packages, the physical
pin arrangements are often altered to accommodate each package.
The designs that incorporate these parts are routed differently.
A simulation tool might not be able to iterate through the
set of package models while maintaining consistency with the
design at hand. A part with both plastic and ceramic packages,
on the other hand, might be easily accommodated, assuming the
pinouts are the same.

B) A fully specified part name encompasses the package type.
Some companies may have model naming policies that require
model names to match manufacturer part numbers. But this
makes the model package-specific. A good example is ceramic
vs. plastic, where the manufacturer part numbers include
different package suffixes. In fact, the design environment
may count on package-specific model names, to assist with
associating parts with models. In this case, "radically"
different package models should not be assigned. But I don't
see this as a reason to not *allow* radically different package
models in a [Package Model Selector] list.

Mike LaBonte
Cadence Design Systems

Bob Ross wrote:
>
> To IBIS Committee:
>
> Arpad Muranyi submitted BIRD 64.1 in response to a number of recent
> comments including those made at the November 19, 1999 IBIS Meeting.
> BIRD64.1 does not necessarily implement some of the comments. The
> Analysis and Background sections have been expanded significantly and
> contain some of the rationale for this revision. We expect more
> discussion and debate.
>
> Bob Ross
> Mentor Graphics
>
> *******************************************************************************
> *******************************************************************************
>
> BIRD ID#: 64.1
> ISSUE TITLE: Package Model Selector
> REQUESTER: Arpad Muranyi, Intel
> DATE SUBMITTED: 10-25-99, 11-19-99
> DATE ACCEPTED BY IBIS OPEN FORUM: Pending
>
> ******************************************************************************
> ******************************************************************************
>
> STATEMENT OF THE ISSUE:
>
> The current IBIS specification (3.2) does not provide a selection mechanism
> for multiple package models. This may be necessary when a certain die is
> shipped in various package styles, or when the corner cases of the package
> are described with different package models.
>
> This BIRD is written to provide an easy solution to this deficiency. This
> feature will allow simulator tools to implement a user friendly package
> model selection interface and/or better automation for batch and sweep
> simulations.
>
> ******************************************************************************
>
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
>
> A new keyword shall be introduced in the IBIS specification to provide a user
> friendly package model selection mechanism for components which use multiple
> package models. The proposed keyword [Package Model Selector] shall contain a
> list of all package model names that the simulator can pick from. The first
> entry in the list is considered to be the default package model. The package
> model names listed under the [Package Model Selector] must follow the rules
> of the package model names associated with the [Package Model] keyword.
>
> To help the user of the simulator tool to make an intelligent choice, it is
> highly recommended that a description be placed to the right of each package
> model name in the list as a comment.
>
> |=============================================================================
> | Keyword: [Package Model Selector]
> | Required: No.
> | Description: Used to select a package model from a list of package models.
> | Sub-Params: None.
> | Usage Rules: The [Package Model Selector] keyword can be used in place of
> | the [Package Model] keyword. The only difference between the
> | two keywords is that the [Package Model Selector] allows
> | multiple package models to be listed. All package model names
> | must appear below the [Package Model Selector] keyword.
> |
> | The package model names listed under the [Package Model
> | Selector] must follow the rules of the package model names
> | associated with the [Package Model] keyword.
> |
> | The first entry under the [Package Model selector] keyword
> | shall be considered the default by the simulator tool.
> |=============================================================================
> |
> [Package Model Selector]
> |
> 208-pin_plastic_PQFP_package-even_mode | What more can be said here?
> 208-pin_plastic_PQFP_package-odd_mode | It's all in the name.
> 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here.
> 208-pin_ceramic_PQFP_package-odd_mode | And some more here too.
> |
> ******************************************************************************
>
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
>
> Problem statement
>
> Some components are shipped in multiple package styles. Also, there are
> situations when the corner cases of a package are modeled with multiple
> package models. Currently, in these cases the user of the IBIS model has to
> manually edit the IBIS file to change the package model name that is called by
> the [Package Model] keyword in order to reference a different package model.
> This makes automated simulations difficult, if not impossible.
>
> Possible solutions
>
> Add a new, simple keyword to the IBIS specification which works similar to the
> already existing [Model Selector] keyword.
>
> ******************************************************************************
>
> ANY OTHER BACKGROUND INFORMATION:
>
> Several IBIS model users expressed their desire in private conversations and
> IBIS meetings to have such a package model selection mechanism in the IBIS
> specification to make their work easier.
>
> An alternate syntax was suggested by Bob Ross during an EMAIL and telephone
> correspondence on 10/25/99. The suggested syntax is identical to the [Model
> Selector] syntax, according to which the [Package Model Selector] would be
> assigned a name that is called by the (higher level) [Package Model] keyword.
> However, unlike in the [Model Selector] case, there is no need for calling the
> [Package Model Selector] from a higher level. This BIRD favors the simpler
> vs. the more consistent approach.
>
> Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ.,
> min., and max. columns in the list of package models under the model selector
> name to assist in automating the package model selection based on corner
> cases. According to the exisiting rules this is not possible, becuase the
> package model names are allowed to be up to 40 characters in length. Three
> package model names on the same line could add up to 122 characters, which
> violates the current 80 character per line rules of the IBIS specification.
>
> Further, package model names are allowed to include blank characters, which
> requires a delimiter other than the space or tab character between the
> typ., min., and max. columns. The usage of a new delimiter introduces another
> inconsistency in the IBIS specification, since spaces and/or tab characters
> are widely used as delimiters between columns in current IBIS versions.
>
> A technical dilemma regarding the automated selection of package models based
> on typ., min., and max. qualifiers remains to be answered also. What do typ.,
> min., and max. represent? Impedance, wave velocity, trace length, or perhaps
> the amount of cross talk? Simulation tool users will most likely make their
> choices based on individual preferences, possibly depending on project
> requirements. For this reason it seems to make more sense to give only a list
> that contains all of the package models without the typ., min., and max.
> qualifiers. The selection and automated usage of the various package models
> should then be done through a GUI or configuration mechanisms provided by the
> tool.
>
> The differences between the model name and package model name restrictions
> required a change even in this BIRD. The description field of the [Model
> Selector] keyword is separated by one or more space or tab character(s) from
> the model name. However, since package model names can contain blank
> characters, space or tab characters will not work as delimiters for the
> description field of the [Package Model Selector] keyword.
>
> Since the contents of the description field is only used for informational
> purposes which does not effect the simulations I decided to use the comment
> character (|) as the delimiter for now. This option was actually discussed
> for the [Model Selector] also but voted down for the reason that tools reading
> an IBIS model have all the rights to ignore all comments, therefore a GUI
> would not know how to distinguish between a legitimate descrription and a
> meaningless comment. Does anyone have a better suggestion?
>
> ******************************************************************************
 
Received on Fri Oct 6 11:52:20 2000