[ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/22/2013
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 22 Oct 2013 13:53:27 -0400 (EDT)
Arpad,
And what makes my proposal not last for the indefinite future? What
situation can you foresee that does not get handled by this?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, October 22, 2013 1:49 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/22/2013
What is an exception today may be the norm tomorrow.
I would like to make a specification which is going
to last a little longer.
Thanks,
Arpad
======================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, October 22, 2013 12:42 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/22/2013
Arpad,
The default case is a one-to-one mapping of Signal, Pins, Die pads and
Buffer Pads. And a one-to-one relationship between supply pins and supply
die pads. There is only a need for handling the exception cases of:
1. Different number of supply pins and pads
2. One signal pin going to multiple die pads
3. Multiple signal pins going to a single die pad
I think it would be best to handle these by exceptions as I have
previously proposed:
1. Different number of supply pins and pads
a. Add a [Supply Die Pad] section that contains:
i.
<Die Pad Name> <Signal Name>
2. One signal pin going to multiple die pads
a. Either a stacked die or a single pin connected to two buffers on
the same silicon
b. Add an optional "Stacked=<n>" field to each [Pin] record
3. Multiple signal pins going to a single die pad
a. Allow two pins to have the same signal name and therefore connect
to a single instance of a buffer
Does not these simple enhancements to IBIS address this need?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, October 22, 2013 1:23 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/22/2013
Walter,
It seems to me that the biggest problems we have in IBIS
is that we don't declare the names of pads (although it is
debatable that [Node Declarations] does exactly do that),
we do not declare die names under component and that [Model]s
are instantiated from the [Pin] keyword.
What if we did the following:
-Define a new keyword to declare the die and its name [Die]
-Define a new keyword [Die Pad] which is scoped under [Die]
-Keep the [Component] keyword with [Pin] scoped under it, but
-Remove the 3rd column from [Pin] so that it would not instantiate
buffer models (the remaining columns of [Pin] could also be
removed, since lumped package modeling is practically useless).
-Find new way to instantiate [Model]s on each [Die] so that it
is not associated with die pads directly (in case there are
splits or joins in the on-die interconnect)
This way we could name the specific component pins, dice and
die-pads, and buffer terminals on each die using unique names.
As a result any package and/or on-die interconnect model could
make connections to any number of component pins, die pads
(regardless of which die they are on, or how many dice a component
contains).
This would allow us to make a netlist for any combination of
pins pads and buffers.
The question still remains as to how to address netlists which
do not have pin/pad/die names, and the package and/or on-die
interconnect topology is only associated with buffer names.
Thanks,
Arpad
====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, October 22, 2013 10:18 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/22/2013
All,
I believe that I have demonstrated that EMD-Like solutions addresses all
existing package and on-die modeling requirements. During last week's
meeting several attendees mentioned that there may be additional
requirements that we have not yet considered. One specific point was that
RDL was not all of the on-die interconnect, so someone was going to
explain the subtleties here.
This demonstration of EMD-Like solutions was limited to the understood
requirement that any package or on-die interconnect solution must support
interconnect between specific pins and die pads, and between specific die
pads and buffer terminals.
This group must also decide if the IBIS package and on-die interconnect
modeling solution should also include the following enhancement to the
IBIS Component section:
a. Two pins to single die pad
b. One pin to multiple die pads
c. Stacked memory (which can alternatively be handled by EMD)
d. Different number of supply pins and supply die pads
This group must also decide if the IBIS package and on-die interconnect
modeling solution should also include support for high levels of
abstractions:
a. Some or all of the Terminals/Ports associated with Models instead
of specific Pins/Pads/Buffer
b. Some or all of the Terminals/Ports associated with Inputs or
Outputs (NEXT/FEXT) instead of specific Pins/Pads/Buffer
One cannot proceed with any solution until we make the above fundamental
decisions of the required functionality of a package/on-die interconnect
modeling methodology.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, October 22, 2013 11:00 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] IBIS-ATM teleconference - Agenda for 10/22/2013
Time: October 22, 2013 Noon US Pacific Time =====
Audio:
======
Voice dial-in: (800) 637-5822
International: +1 (647) 723-3937 <--- (For Canada)
0114501530 <--- (For Sweden)
0201400572 <--- (For Sweden Toll Free)
069509594672 <--- (For Germany)
08001014542 <--- (For Germany Toll free)
Access Code: 685-0440
Web
===
Click Here to Join Live Meeting:
<http://tinyurl.com/yvmesj> http://tinyurl.com/yvmesj
or:
<https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j%
23-%25%7E5>
https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j%2
3-%25%7E5
Mentor Global Crossing Teleconference commands:
<http://www.globalcrossing.com/customer/collaboration/cust_ready_access_ti
ps.aspx>
http://www.globalcrossing.com/customer/collaboration/cust_ready_access_tip
s.aspx
FIRST TIME USERS: To save time before the meeting, check your system to
make sure it is compatible with Microsoft Office Live Meeting.
---------------------------------------------------------------------
Agenda
======
1) Opens
2) Call for any related patent disclosures
3) Review of ARs:
Walter: Create more EMD-like examples according to the requests
- ???
Any other AR-s?
Old ARs:
Arpad: Review the documentation (annotation) in the macro libraries.
- deferred until a demand arises or we have nothing else to do
4) Roll call
5) JEITA LPB (Mike Mirmak)
6) Discuss more EMD-like examples (Walter)
7) BIRD 147 Back-channel support (Ambrish)
- update, questions, comments?
8) BIRD 128 Allow AMI_parameters_out to pass AMI_parameters_in
data on calls to AMI_GetWave (Walter)
- update, questions, comments?
9) BIRD 157 Parameterize [Driver Schedule] (Arpad)
- discussion
10) Info, Out, InOut BIRD (Arpad)
- latest wording includes "in order to be compliant with this
specification, Model_Specific parameters ... must not ...",
and omits the word "simulation" so it's meaning doesn't have
to be defined
- questions/comments/discussion?
11) DLL error trapping and return codes (Greg Edlund)
- address the nasty condition where the DLL and tool crash
without a trace. The EDA vendor says, "I can't help you
because I can't see inside the model." The model vendor
says, "I can't help you because I don't own that tool."
The user is left with a non-functional model.
12) What is the purpose of the specification? Describe the syntax
and rules of the syntax, or tell the reader how to make models?
- questions/comments/discussion?
Tabled topics:
==============
PAM4 BIRD (Walter)
Thanks,
Arpad
=====================================================================
---------------------------------------------------------------------
IBIS Macro website : <http://www.eda.org/pub/ibis/macromodel_wip/>
http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: <//www.freelists.org/list/ibis-macro>
//www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: <mailto:ibis-macro-request@xxxxxxxxxxxxx>
ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
