Arpad,
Thanks for the initial comments.
My mistake, I meant electrical paths or electrical connections in several
places to describe the electrical interconnection that is available in an
Interconnect Model (with IBIS-ISS or Touchstone information) or by other
available package model formats.
I named the other available package model formats by listing the keywords
and entries: [Package] R/L/C_pkg, or [Pin] R/L/C_pin, or the entries
associated with a [Define Package Model] keyword. This is a small list for
other available package model information that will exist in the Version
7.0 document, so there is no need for directing a reader to another
document.
We can discuss and work on the wording.
Bob
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, January 2, 2018 12:16 PM
To: ibis-interconn@xxxxxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-interconn] Re: BIRD189.5_draft15_v1
Bob,
A few quick reactions:
Regarding: However, if model was used to mean an electrical model, I
stated electrical model.
I am not sure I like this. After all, an interconnect model is also an
electrical model, since it carries
electrons (and not petroleum or other substances). J Wouldnt it be better
to refer to those as
[Model], or buffer model?
Regarding: I changed legacy to existing package models, I think this is
still confusing. From the
perspective of the v7.0 spec, the new BIRD189 interconnect modeling syntax
will also be an existing
package model in the v7.0 specification. I still think that the best way to
refer to the old package
modeling syntax is either what Walter suggested: Package models defined in
IBIS 6.1, or what I
suggested based on his suggestion: Package models defined (supported?)
prior to IBIS 7.0
Thanks,
Arpad
============================================================================
====
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Tuesday, January 2, 2018 2:01 PM
To: ibis-interconn@xxxxxxxxxxxxx
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] BIRD189.5_draft15_v1
All,
I was asked to propose changes to draft14 to make the terminology consistent
and to deal with forward referencing issues. Most of the rules require
detailed knowledge of the contents in a new Section XXX for Interconnect
Modeling. Many of the rail based rules require knowing details given in
the [Pin], [Pin Mapping], [Bus Label] and [Die Supply Pads] keywords.
The changes in draft15_v1 are mostly under the [Interconnect Model Group]
keyword and in some bullet items under [Interconnect Model Set] keyword.
To make the terminology consistent, in most cases I changed model to
Interconnect Model. I also expanded Set to Interconnect Model Set and Group
to Interconnect Model Group. However, if model was used to mean an
electrical model, I stated electrical model. I made these interface name
changes to be consistent with Section XXX names and capitalization:
Buffer à buffer
Pad à die pad
Pin à pin
I changed legacy to existing package models and listed the choices. These
existing package model formats remain valid and are part of IBIS Version
7.0. I also noted that if several [Define Package Model]s exit, then the
EDA tool or user needs to select one of the [Define Package Model] keywords.
For rail terminal names, pin_name only is valid for the Pin_Rail
Terminal_type to reference a POWER or GND terminal. The pin_name entry is
not used at the die pad interface. When a pin_name entry it is used at the
buffer interface for *_ref Terminal_Types, the pin_name entry is for an I/O
buffer pin_names. So some of the rules were expanded because PDN electrical
paths do not rely on only on identical pin_name entries (as does I/O
electrical paths).
Some bullet indentation might be fixed later.
Bob
--
Bob Ross
Teraspeed Labs
www.teraspeedlabs.com <http://www.teraspeedlabs.com/>
bob@xxxxxxxxxxxxxxxxx
Direct: 503-246-8048
Office: 971-279-5325
