Re: IBIS BIRD64.1 - Package Model Selector

Roy,

Good point about the choice of package affecting die operation
due to different thermal characteristics. I'm convinced - we
probably should not encourage use of [Package Model Selector]
for uses other than to cover variations of the same package.

Mike

Roy Leventhal wrote:
>
> Mike,
>
> At today's speeds radically different packages and die will result in radically
> different SI and EMI behavior. As well, different die + package combinations
> will dissipate power generated heat radically differently. This will affect SI
> and EMI.
>
> I don't believe IBIS currently models this behavior. Nor are model providers
> competent or caring enough to include the necessary data and characterization to
> implement such modeling if IBIS provided for it. Further, SPICE itself is rarely
> implemented in a fashion that models such behavior correctly - all in one file.
>
> Thus, I believe that models should be package/die specific.
>
> But, based on evidence, you can certainly convince me otherwise.
>
> Best Regards,
>
> Roy
>
> Mike LaBonte <mikelabonte@cadence.com> on 10/06/2000 01:49:17 PM
>
> Sent by: Mike LaBonte <mikelabonte@cadence.com>
>
> To: Bob Ross <bob_ross@mentorg.com>
> cc: ibis@eda.org (Roy Leventhal/MW/US/3Com)
> Subject: Re: IBIS BIRD64.1 - Package Model Selector
>
> To follow up on my comments on BIRD 64.1 at the IBIS forum
> teleconference today, I would like to propose that:
>
> 1) The BIRD should declare scoping requirements
> It is not stated where the [Package Model Selector] can appear
> in an IBIS file, and to which [Component] it applies. We might
> add a paragraph like:
>
> #############################################################
> Each [Package Model Selector] keyword specifies the set of
> package models for only one component, which is given by
> the previous [Component] keyword. The [Package Model Selector]
> keyword may not appear before the first [Component] keyword
> in an IBIS file.
> #############################################################
>
> 2) [Package Model] and [Package Model Selector] are mutually exclusive
> When [Package Model Selector] is used, [Package Model] makes
> no sense. The [Package Model] keyword *could* give the name of
> the default package model, but I agree with the idea of the
> default as specified by the first [Package Model Selector] value.
> We might add a paragraph like:
>
> #############################################################
> The appearance of the [Package Model Selector] keyword after
> a [Component] keyword overrides any [Package Model] keyword
> that may appear often the same [Component] keyword.
> #############################################################
>
> Concerning Roy Leventhal's comment on how [Package Model Selector]
> might be used, I see 2 issues:
>
> A) The assignable package models must have the same pinouts.
> Although some die can be shipped in various packages, the physical
> pin arrangements are often altered to accommodate each package.
> The designs that incorporate these parts are routed differently.
> A simulation tool might not be able to iterate through the
> set of package models while maintaining consistency with the
> design at hand. A part with both plastic and ceramic packages,
> on the other hand, might be easily accommodated, assuming the
> pinouts are the same.
>
> B) A fully specified part name encompasses the package type.
> Some companies may have model naming policies that require
> model names to match manufacturer part numbers. But this
> makes the model package-specific. A good example is ceramic
> vs. plastic, where the manufacturer part numbers include
> different package suffixes. In fact, the design environment
> may count on package-specific model names, to assist with
> associating parts with models. In this case, "radically"
> different package models should not be assigned. But I don't
> see this as a reason to not *allow* radically different package
> models in a [Package Model Selector] list.
>
> Mike LaBonte
> Cadence Design Systems
>
> Bob Ross wrote:
> >
> > To IBIS Committee:
> >
> > Arpad Muranyi submitted BIRD 64.1 in response to a number of recent
> > comments including those made at the November 19, 1999 IBIS Meeting.
> > BIRD64.1 does not necessarily implement some of the comments. The
> > Analysis and Background sections have been expanded significantly and
> > contain some of the rationale for this revision. We expect more
> > discussion and debate.
> >
> > Bob Ross
> > Mentor Graphics
> >
> >
> *******************************************************************************
> >
> *******************************************************************************
> >
> > BIRD ID#: 64.1
> > ISSUE TITLE: Package Model Selector
> > REQUESTER: Arpad Muranyi, Intel
> > DATE SUBMITTED: 10-25-99, 11-19-99
> > DATE ACCEPTED BY IBIS OPEN FORUM: Pending
> >
> > ******************************************************************************
> > ******************************************************************************
> >
> > STATEMENT OF THE ISSUE:
> >
> > The current IBIS specification (3.2) does not provide a selection mechanism
> > for multiple package models. This may be necessary when a certain die is
> > shipped in various package styles, or when the corner cases of the package
> > are described with different package models.
> >
> > This BIRD is written to provide an easy solution to this deficiency. This
> > feature will allow simulator tools to implement a user friendly package
> > model selection interface and/or better automation for batch and sweep
> > simulations.
> >
> > ******************************************************************************
> >
> > STATEMENT OF THE RESOLVED SPECIFICATIONS:
> >
> > A new keyword shall be introduced in the IBIS specification to provide a user
> > friendly package model selection mechanism for components which use multiple
> > package models. The proposed keyword [Package Model Selector] shall contain a
> > list of all package model names that the simulator can pick from. The first
> > entry in the list is considered to be the default package model. The package
> > model names listed under the [Package Model Selector] must follow the rules
> > of the package model names associated with the [Package Model] keyword.
> >
> > To help the user of the simulator tool to make an intelligent choice, it is
> > highly recommended that a description be placed to the right of each package
> > model name in the list as a comment.
> >
> > |=============================================================================
> > | Keyword: [Package Model Selector]
> > | Required: No.
> > | Description: Used to select a package model from a list of package models.
> > | Sub-Params: None.
> > | Usage Rules: The [Package Model Selector] keyword can be used in place of
> > | the [Package Model] keyword. The only difference between the
> > | two keywords is that the [Package Model Selector] allows
> > | multiple package models to be listed. All package model names
> > | must appear below the [Package Model Selector] keyword.
> > |
> > | The package model names listed under the [Package Model
> > | Selector] must follow the rules of the package model names
> > | associated with the [Package Model] keyword.
> > |
> > | The first entry under the [Package Model selector] keyword
> > | shall be considered the default by the simulator tool.
> > |=============================================================================
> > |
> > [Package Model Selector]
> > |
> > 208-pin_plastic_PQFP_package-even_mode | What more can be said here?
> > 208-pin_plastic_PQFP_package-odd_mode | It's all in the name.
> > 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here.
> > 208-pin_ceramic_PQFP_package-odd_mode | And some more here too.
> > |
> > ******************************************************************************
> >
> > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
> >
> > Problem statement
> >
> > Some components are shipped in multiple package styles. Also, there are
> > situations when the corner cases of a package are modeled with multiple
> > package models. Currently, in these cases the user of the IBIS model has to
> > manually edit the IBIS file to change the package model name that is called by
> > the [Package Model] keyword in order to reference a different package model.
> > This makes automated simulations difficult, if not impossible.
> >
> > Possible solutions
> >
> > Add a new, simple keyword to the IBIS specification which works similar to the
> > already existing [Model Selector] keyword.
> >
> > ******************************************************************************
> >
> > ANY OTHER BACKGROUND INFORMATION:
> >
> > Several IBIS model users expressed their desire in private conversations and
> > IBIS meetings to have such a package model selection mechanism in the IBIS
> > specification to make their work easier.
> >
> > An alternate syntax was suggested by Bob Ross during an EMAIL and telephone
> > correspondence on 10/25/99. The suggested syntax is identical to the [Model
> > Selector] syntax, according to which the [Package Model Selector] would be
> > assigned a name that is called by the (higher level) [Package Model] keyword.
> > However, unlike in the [Model Selector] case, there is no need for calling the
> > [Package Model Selector] from a higher level. This BIRD favors the simpler
> > vs. the more consistent approach.
> >
> > Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ.,
> > min., and max. columns in the list of package models under the model selector
> > name to assist in automating the package model selection based on corner
> > cases. According to the exisiting rules this is not possible, becuase the
> > package model names are allowed to be up to 40 characters in length. Three
> > package model names on the same line could add up to 122 characters, which
> > violates the current 80 character per line rules of the IBIS specification.
> >
> > Further, package model names are allowed to include blank characters, which
> > requires a delimiter other than the space or tab character between the
> > typ., min., and max. columns. The usage of a new delimiter introduces another
> > inconsistency in the IBIS specification, since spaces and/or tab characters
> > are widely used as delimiters between columns in current IBIS versions.
> >
> > A technical dilemma regarding the automated selection of package models based
> > on typ., min., and max. qualifiers remains to be answered also. What do typ.,
> > min., and max. represent? Impedance, wave velocity, trace length, or perhaps
> > the amount of cross talk? Simulation tool users will most likely make their
> > choices based on individual preferences, possibly depending on project
> > requirements. For this reason it seems to make more sense to give only a list
> > that contains all of the package models without the typ., min., and max.
> > qualifiers. The selection and automated usage of the various package models
> > should then be done through a GUI or configuration mechanisms provided by the
> > tool.
> >
> > The differences between the model name and package model name restrictions
> > required a change even in this BIRD. The description field of the [Model
> > Selector] keyword is separated by one or more space or tab character(s) from
> > the model name. However, since package model names can contain blank
> > characters, space or tab characters will not work as delimiters for the
> > description field of the [Package Model Selector] keyword.
> >
> > Since the contents of the description field is only used for informational
> > purposes which does not effect the simulations I decided to use the comment
> > character (|) as the delimiter for now. This option was actually discussed
> > for the [Model Selector] also but voted down for the reason that tools reading
> > an IBIS model have all the rights to ignore all comments, therefore a GUI
> > would not know how to distinguish between a legitimate descrription and a
> > meaningless comment. Does anyone have a better suggestion?
> >
> > ******************************************************************************
 
Received on Sat Oct 7 19:58:40 2000