Arpad,
Thank you for the review and comments. I will respond in your text in
Green.
Bob
Thank you fo th
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, December 7, 2017 8:53 PM
To: ibis-interconn@xxxxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-interconn] Re: BIRD189.x - Short Summary of Proposal
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..
BR: Good points. It is preferred that the PDN and I/Os cover the same Span.
However, if people really require that PDNs go to Buffers, and I/Os go to
Die Pad,
Then we have several ways for dealing with this:
- Add Direct Short Sets for Buffer to Pad I/Os for a limited set of
high-speed I/Os (e.g., 16)
- It may work to rename the Pad_IO to Buffer_I/O as a new set
(assuming that there are no Pad_Rail reference terminal in the I/O set (that
might be disconnected anyway
- Or, for this Group, create a special rule that if ALL I/Os only
go to the Pad, then a short to the Buffer_IO is assumed
Bob
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] On Behalf Of Muranyi, Arpad
Sent: Thursday, December 7, 2017 12:41 PM
To: 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] On Behalf Of Bob Ross
Sent: Thursday, December 7, 2017 12:16 PM
To: ibis-interconn@xxxxxxxxxxxxx; IBIS-ATM <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).
BR: [Pin Mapping] requires all I/O pins, and the First Column for I/O pins
is the pin_name. This is where rail terminal bus_labels are mapped to I/O
buffer rails (pulldown_ref, etc. columns), This routing feature is
functionally equivalent to existing IBIS Package formats. The assumption
that on-die interconnect rail busses are electrical shorted busses that are
distributed to the I/O buffers. So, with just [Pin Mapping], this Group
provides is one way to replace any existing IBIS Package model.
[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?
BR: Yes, as an added feature that was not part of the requirements but adds
includes electrical models for on-die connections.
Note, at this time the only way to produce just an on-die component (without
package) is to zero-out or delete all package entries.
This Group could remain for more electrical detail.
[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?
BR: Mentioned above. Additional points;
IOs from Pad to Pin and Rails directly from Buffer to Pin
1. Create new Set with Pad_I/O terminals renamed to Buffer_I/O. Note,
for this approach, there should not be any reference connection to a rail
terminal other the A_gnd because a Pad_Rail terminal does not exist in the
electrical connection.
2. Rail paths in two Sets (Pin to Pad and Pad to Buffer)
a. Perhaps a new rule for shorted connections for ALL I/Os from Pad to
Buffer if this is a real issue. The reason for all I/Os if only partial
Buffer to Pad sets exist, the extraction is most likely technically flawed
and incomplete.
b. Or a Set with Shorts
3. We could add the special rule for this Group that EDA tools connect
All Pad_IO terminals to Buffer_I/O terminals
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?
BR: I agree with your concerns since a PDN only structure is functionally
dead in IBIS. IBIS is I/O pin or buffer pin centric for simulation access.
The best way to analyze PDN structures for decoupling, resonance is to set
up a separate SPICE or Touchstone simulations (time and frequency sweeps)
outside of IBIS. This is already done, so there is no need to add it to
IBIS. However PDN Sets can be added to any other Group.
However, if the [ PDN Group] is added by itself, an EDA tool could use it in
a vendor-specific manner. There are many issues outside of standard IBIS.
So, I do not favor adding a [PDN Group] in IBIS..
-------
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.
BR: Eexcept [PDN Group] there is no mixing. The Group overrides all
existing IBIS Package Models. To clarify, that are I/O paths that are not
broad-band, and no Groups exist or are selected. That is where existing
IBIS Package models are used. It is not mixing, but one or the other.
As proposed, we could create Group for this mixing. However, now we have
all of the complications that you stated above and also many others. A
separate matrix RLC model is doable as long as there is no I/Os or coupling
outside the group and rails that are for different supplies than in the PDN
structure. We can even support [Merged Pins]. So for this group,
[Alternative Package Models] might be needed for selecting a different
[Define Package Model]. All of this becomes a big mess, and IBIS cannot
dictate rules because accurate information may not be available. The bottom
line is that the overall structure is likely not to be broad-band and
existing package models are sufficient and more efficient.
--
Bob Ross
Teraspeed Labs
www.teraspeedlabs.com <http://www.teraspeedlabs.com/>
bob@xxxxxxxxxxxxxxxxx
Direct: 503-246-8048
Office: 971-279-5325
