Re: Comments on IBIS BIRD64.3 - Alternate Package Models

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
 
Received on Fri Nov 3 03:53:07 2000