Bob,
If you can only have a single Group Type, then signal and supply models
will all have to cover the same "span". You won't be able to have one of
them between pin and pad, and the other go from pin to buffer, or pad
to buffer, etc... Or, if a model maker must have a different span for their
models, then they will need to make "fake" models with shorts to make
up where the other model covers a wider span. That would be very
undesirable for various reasons....
I will put a few more comments between your lines below in red.
Thanks,
Arpad
========================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Thursday, December 7, 2017 5:07 PM
To: ibis-interconn@xxxxxxxxxxxxx; 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: BIRD189.x - Short Summary of Proposal
Arpad,
Normally , one only at a time.
Bob
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, December 7, 2017 12:41 PM
To: ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM
Subject: [ibis-interconn] Re: BIRD189.x - Short Summary of Proposal
Bob,
How many of these Group keyword types would you allow simultaneously
in one component?
Thanks,
Arpad
==========================================================
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Thursday, December 7, 2017 12:16 PM
To: ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-interconn] BIRD189.x - Short Summary of Proposal
All,
Brief Alterative Proposal Summary as it is evolving (shortcut names for clarity)
Note, [Pin], [Pin Mapping], [Bus Label] and [Die Supply Pads] information may
be needed rail for connections to I/O buffer rails.
[Pad Pin Group] (could be [Package Group])
Replaces all existing IBIS Package Model formats with broad-band electrical
models
No Set includes Interconnect Models with terminals at the Buffer boundary
Simulations based on I/O pin_name selection(s)
PDN interface: Pin boundary, but connections to I/O supplies are translated
at the Pad boundary into bus_labels
Requires [Pin Mapping] because no direct mapping of rails to buffer supply
terminals is documented
Without PDN, internal [* Reference] rails are used, and [Pin Mapping] optional
AM: If the above group cannot have any terminals at the buffer, than
Buffer_I/O is
illegal too. As a result, you can only use Pad_I/O for signal terminals on the
die side,
and you will have a disconnect between Buffer_I/O and Pad_I/O, unless you allow
"automatic shorting" between them, which is something you do not want to have
(if I understand you correctly). And [Pin Mapping] can only establish busses
for supplies,
not signals. (None of the columns in [Pin Mapping] are signal columns).
[Buffer Pad Group] (could be [On Die Group]
Adds electrical models to the on-die interconnect, but stops at the Pad
boundary
No Set includes Interconnect Models at the Pin boundary
No existing IBIS Package Model formats used, but EDA tool can optionally use
shorts to Pin boundary
Simulations based on I/O pin_name selection(s)
PDN interface: Pad boundary
Uses [Pin Mapping] rail to buffer supply terminal connections, OR uses direct
connections to buffer rail terminals
Without PDN, internal [* Reference] rails are used, and [Pin Mapping] optional
AM: The above would only be able to do bare-dies, since Pin_to_Pad models and
other Group Types are not allowed. Is that your intent?
[Full Path Group] (could be [Buffer Pin Group] or some other name)
Replaces all existing IBIS Package Model formats with broad-band electrical
models
Supports broadband Buffer to Pin connections where broad-band electrical
models exist between
Buffer-to-Pin, AND/OR between connected
Buffer-Pad, and Pad-Pin
Full path connections required for all I/Os and PDNs, if included
Simulations based on I/O pin_name selection(s)
PDN interface: Pin boundary
Uses [Pin Mapping] rail to buffer supply terminal connections, OR uses direct
connections to buffer rail terminals
Without PDN, internal [* Reference] rails are used, and [Pin Mapping] optional
AM: The above will require a model maker to make fake "short" models if
they do not have or want to model signal and supply the same way. Imagine
a Pin_to_Pad signal model and a Pin_to_Buffer supply model. How would
that be done without fake (shorting) models?
Added, for identification, but not part of earlier proposal
[PDN Group]
Full path PDN structure only
No I/O terminals in any Sets
Does not support broad-band I/O simulation within IBIS
Simulations based on I/O pin_name selection(s) and existing IBIS Package Models
that do not include PDN paths
I/O pins used as stimuli
AM: If you don't allow multiple Group Types to exist simultaneously, this Group
doesn't make much sense by itself. Who would want to model the supply paths
alone without being able to model signal paths?
-------
Main Points of Proposal Summary Here
- Group keywords tell EDA tool and model-maker purpose and intent; and
User can make informed selection
- Boundaries avoid default shorts or else allows rules for default
shorts for all paths to new boundary
- Except for PDN group, no mixing of existing IBIS Package models
(that would be contrary to broad-band simulation)
- Full Path connections likely to contain Sets for Interconnect Model
that have paths same boundaries
o Missing Sets likely to be an Error of omission or in linkages - must be
reported
o Unintended shorts may reduce quality of the Interconnect Structure
simulation
AM: We need to define what we mean by "mixing of existing IBIS Package models".
I can see several combinations which would be quite useful and doable without
any
complications. For example, we can make a BIRD189 model for on-die
interconnects
while using legacy models for package modeling. I can even see that BIRD189
and legacy
package models could coexists when the legacy package model does not use the RLC
matrix format (i.e. has no coupling). The only thing we would have to stay
away from
is mixing the RLC matrix legacy package model with BIRD189 package models,
because
the coupling terms make it difficult or impossible to mix them easily. We need
to
revisit Requirement #15 in the BIRD, because it doesn't state clearly what we
mean
by not mixing the models...
--
Bob Ross
Teraspeed Labs
www.teraspeedlabs.com<http://www.teraspeedlabs.com/>
bob@xxxxxxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxxxxxx>
Direct: 503-246-8048
Office: 971-279-5325
