Arpad,
See my comments below. Please note that I do not agree with distinguishing
between "Pin_to_pad, Pin_to_buffer and Buffer_to_pad". I think they all
represent "Pin_to_buffer". I distinguished them because Bob wants to
distinguish them and this is the easiest way to have that debate, they are
a distillation of Bob's presentations.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
978.461-0449 x 133
Mobile 303.335-6156
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 6, 2017 1:39 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Updated Interconnect Model Group rules,
including change to [Interconnect Model Set]
Walter,
Thanks for explaining it. I am starting to understand these subparameters
now. First I
have a clarification question. You start the explanation under all four
of these with
"This group contains models". If we have a hierarchy in which groups
contain sets,
and sets contain models, then groups can't contain models (only
indirectly).
WMK> Yes, Groups contain Sets which contain Models. Ultimately, a Group
contains a list of Models.
Also, do these subparameters apply equally to signal and supply
connections? For
example, if I have an [Interconnect Model] which has a coupled model for
signal and
power, all ports must be at the same "interface"? Power can't go from pin
to a buffer
terminal while the signal goes to pad, etc.? What if there are two
[Interconnect Model]s
in a set, one that covers supply and the other covers signal. Can these
two go to different
interfaces (pin to pad and pin to buffer)?
WMK> If signals are couple to rails, you are correct. But consider what I
consider to be a very common way of delivering models, and the ways that
models today are delivered by IC vendors, and the way models today are
used by EDA vendors (note that the models in each a., b. and c. might be
delivered in separate Sets because they are generate by different tools):
1. Method 1
a. Signal interconnect will be between Pin and Pad, and generated by
a package design tool.
b. Package rail interconnect will be between pin rail signal name and
pad rail signal name
c. On die rail interconnect will be between pad rail signal name and
buffer rail signal name
i.
This might simply be die capacitance
2. Method 2
a. Signal interconnect will be between Pin and Pad, and generated by
a package design tool.
b. Rail interconnect will be between pin rail signal name and buffer
rail signal name
So how would this work? Do we still allow multiple sets in a group? But
depending on
what the subparameter value is for the group, all sets mentioned in that
group would
only be allowed to have models which have only the corresponding terminal
types?
I am still not sure why these subparameters need to be under the group
keyword
instead of under the set keyword.
Along the lines of what you wrote in your last paragraph, I see a few
"redundancies".
For Pin_to_Buffer you say "Some Pin_names may have models just from pin
to pad,
in which case the buffer shall be shorted to the pad". This make this
subparameter
the same as Pin_to_Pad for those pins, and if we don't prohibit the case
to do that for
all pins, than there will be two ways of doing the same thing. That is
redundant.
WMK> As I said it is nonsense to distinguish "Pin_to_pad, Pin_to_buffer
and Buffer_to_pad".
Similarly, Buffer_to_Pad and Bare_die become identical if the legacy
package model
is zeroed out for Buffer_to_Pad, which is again redundant.
WMK> There is a subtle point here. An IC Vendor may deliver a component
model (not bare die) that has on-die interconnect and legacy package
models, and an EDA tool adds broadband package models in their current
proprietary way (as I expect all EDA vendors do today). So I can envision
an IC vendor delivering an IBIS file with three Groups.
1. Group 1 (Pin to buffer containing two Sets)
a. Set_A which contains only Pad to Buffer Models
b. Set_B which contains only Pin to Pad models
2. Group 2 (Pin to buffer containing one Set)
a. Set_A which contains only Pad to Buffer Models
b. Connections from Pad to Pin use the legacy package models
3. Group 3 (Pad to Die containing one Set)
a. Set_A which contains only Pad to Buffer Models
b. Connections from Pad to Pin are supplied by the EDA tool.
I wonder if we could find a better way of doing this than with these
half-redundant
subparameters.
WMK> Yes, add a sub-parameter Group_type with the following allowed
values
Component
Models in included Sets can be Pin to Buffer, Pin to Pad or Pad to Buffer
1. If a pin_name (or rail signal name) only has Buffer to Pad
a. Use legacy Pad to Pin models
2. If a pin_name (or rail signal name) only has Pin to Pad
a. Short between Buffer and Pad
Bare_die
Sets only contain Buffer_to_pad models
EDA tool supply package models (if any)
Thanks,
Arpad
==================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, December 5, 2017 6:56 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Updated Interconnect Model Group rules,
including change to [Interconnect Model Set]
Arpad,
But that is not the functionality that Bob asked for.
Here is the logic for each group:
Pin_to_Pad
This group contains models from Pin to Pad. For this group, it shall be
assumed that all of the on die interconnect is included in the [Model].
This is what we have traditionally called a package model.
Pin_to_Buffer
This group contains models from Pin to Buffer. Some Pin_names may have
models just from pin to pad, in which case the buffer shall be shorted to
the pad.
Buffer_to_Pad
This group contains only on-die models. The EDA tool shall use legacy
package models from pin to pad.
Bare_die
This group contains only on-die models. The EDA tool shall connect
interconnect directly to the pad. Another way of saying this is that pins
in the component are at the die pad, or are shorted to the die pad.
In reality Pin_to_pad, Pin_to_buffer and Buffer_to_pad each describe a
connection from Pin to Buffer. There is no need to distinguish them since
the rules below do not care if the Group is Pin_to_Pad, Pin_to_Buffer or
Buffer_to_Pad. Bare_die is different because it allows the EDA tool to put
in its own package model, as we have to today because IBIS 6.1 does not
have a way of describing broad band coupled models. So Bare_die is useful
for this case.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
978.461-0449 x 133
Mobile 303.335-6156
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 5, 2017 5:01 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: Updated Interconnect Model Group rules,
including change to [Interconnect Model Set]
Walter,
I am looking at this from the EDA tool's GUI perspective. At the
beginning of this
discussion we said that we would have a single list of groups and the user
will
need to select only one from the list. This idea will change all that.
You list four values for this subparameter:
Pin_to_Pad
Pin_to_Buffer
Buffer_to_Pad
Bare_die
If there is a Pin_to_Pad group, there may also be a Buffer_to_Pad group
(but not
required). If both of these exist, the user may have to make one
selection from both.
If the user is making selections from these groups, they shouldn't be
allowed to make
selections from any of the other groups if they exist.
If there is a Pin_to_Buffer group, the user will need to make only one
selection, and
if the user makes a selection from that group, he/she should not be
allowed to select
from any of the other groups, if they exist.
If the user makes selections from Bare_die, they should not be allowed to
make
selections from Pin_to_Pad and/or Pin_to_Buffer, but if Buffer_to_pad
exists they
should be able to select from that group.
I didn't think all this through in a great detail, but I am afraid that
the GUI logic and
rules might get quite complicated, as opposed to having a single list of
groups with a
single output selection. Is this really what we want?
I think we should consider moving these subparameters to the set keyword
level.
That way we could define rules for what combination of sets should be
allowed to
be listed in the groups. This could actually be parsed by the parser and
issue errors
or warnings if certain combinations are prohibited or missing, etc. That
way the
GUI of the EDA tool could be kept simple, and the user wouldn't have to
scratch
their head how to make the right choices, and there would be no way the
user could
make the wrong selections.
Thanks,
Arpad
=================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, December 5, 2017 3:11 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] FW: Updated Interconnect Model Group rules,
including change to [Interconnect Model Set]
All,
After the meeting I added a new [Interconnect Model Group] sub-parameter
"Group_type", with a list of allowed values and rules associated with each
type. I think this addition covers all of the additional functionality
that Bob described in his presentation.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
978.461-0449 x 133
Mobile 303.335-6156
From: Walter Katz [mailto:wkatz@xxxxxxxxxx] ;
Sent: Tuesday, November 21, 2017 9:47 AM
To: ibis-interconn@xxxxxxxxxxxxx <mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: FW: Updated Interconnect Model Group rules, including change to
[Interconnect Model Set]
This was sent from my Gmail account, resending from my SiSoft account.
All,
Replace the following paragraph:
Model makers are recommended to ensure that each Interconnect Model Set
contains a complete description, through Interconnect Models, needed for
the path connecting the I/O buffers of interest to their associated pins,
and for connecting all rails related to these I/O buffers. This
simplifies choices to be made by the user or automatically by the EDA
tool. It also assures that the full electrical structure that is
simulated matches what the model provider intends. Some EDA tools may
support selecting several Interconnect Model Sets at once to form a
complete path, but this requires additional user interaction and may risk
generating less-accurate simulation data due to duplicate or missing
content.
With
An [Interconnect Model Set] contains a list of [Interconnect Model]s that
have a logical association such as:
* All models in a bus (e.g.. DDR4, or PCIeG3)
* PDN Network
* All I/O models between Pad and Pin
* All I/O models between Buffer and Pad
* All uncoupled models
* All coupled models
Change [Interconnect Model Set Group] to [Interconnect Model Group] Done
And add the following paragraph to the Interconnect Model Group section
Add a sub-parameter Group_type with the following allowed values
Pin_to_Pad
Assumes no on-die interconnect models
Pin_to_Buffer
May have Pin to Pad models without Pad to Buffer models on some pin_name
Buffer_to_Pad
(use legacy package models)
Bare_die
(Buffer_to_Pad - no package model)
"Pin" Terminals are not allowed in any model in Bare_die groups
It is the responsibility of the model maker to create Interconnect Model
Groups that contain a list of Interconnect Model Sets that form a list of
Interconnect Models that will satisfy the interconnect modeling
requirements for simulating a group of I/O and or Rail connections. The
following rules shall apply to the combined list of models in all of the
Sets in each Group.
The following rules apply to non-aggressor (victim) I/O Pin_name
terminals:
Errors
If there is a Pin to Buffer model, then
Error if there is a Pin to Pad model or a Pad to Buffer model.
Error if two (or more) models have a buffer terminal with the same
Pin_name
Error if two (or more) models have a pad terminal with the same Pin_name
Error if two (or more) models have a pin terminal with the same Pin_name
If there is a pin to pad model and no pad to buffer model, the pad and
buffer shall be shorted.
If there is a pad to buffer model and no pin to pad model.
If Group_type is Bare_die
No Package Model
Else
Use legacy package model.
Endif
The following rules apply to aggressor and non-aggressor I/O Pin_name
terminals:
Warnings
If there is a Pin to Buffer model, then
Warning if there is a Pin to Pad model or a Pad to Buffer model.
Warning if two (or more) models have a buffer terminal with the same
Pin_name
Warning if two (or more) models have a pad terminal with the same Pin_name
Warning if two (or more) models have a pin terminal with the same Pin_name
If there is a pin to pad model and no pad to buffer model, the pad and
buffer shall be shorted.
If there is a pad to buffer model and no pin to pad model.
If Group_type is Bare_die
No Package Model
Else
Use legacy package model.
Endif
For models with rail voltages:
If a rail signal name is only on pin terminals, or only on pad terminals
or only on buffer terminals, then these terminals are used to define
references for the interconnect in the model
Ignore the following rail voltage terminal rules on models that a rail
signal name is only on pins, or only on pads or only on buffers.
It is an error if two interconnect models have a connection to the same
buffer rail terminal.
It is an error if two interconnect models have a connection to the same
pin rail terminal.
Walter
