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).
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)?
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.
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.
I wonder if we could find a better way of doing this than with these
half-redundant
subparameters...
Thanks,
Arpad
==================================================================
From: 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>; 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
wkatz@xxxxxxxxxx<mailto: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
wkatz@xxxxxxxxxx<mailto: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
