[ibis-macro] Re: Lets go all the way!
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 27 Aug 2012 16:47:59 +0000
Walter,
What I am trying to stay away from are things like this:
"The (Pins ... ) in the .ibsx file are really Pads."
Let's do things the right way and call things by their real
name... What I have in mind is this:
The IBIS file starts with the [Component] keyword. What makes
up a component, i.e. what does it consist of? Well, it has
pins (or balls), package, at least one die (could be more).
Then on the die we have pads (bumps) and we might have on-die
interconnects between the pads and buffer terminals.
Currently, IBIS starts out correctly with the [Pin] and package
keywords in the [Component] but we forgot to declare and name
(instantiate) the die, and that's where things are starting to
fall apart. I would like to fix that but listing out all the
elements that make up a component, including the die and its
on-die interconnects, and do all this using the correct hierarchy
and terminology.
Thanks,
Arpad
==================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, August 27, 2012 6:58 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Lets go all the way!
Arpad,
Note that in this IBISx approach, the Model is not associated in the package
.emd file. The package .emd file references a die .ibsx file. The (Pins ... )
in the .ibsx file are really Pads. These Pins (Pads) do reference the buffer
model name. I do think that this instantiate [Models] the right way by
associating [Models] with the die pads instead of the package pins.
Are you suggesting that in the .ibsx file we have a list of Pins (pads), and a
separate list of [Models]? Can you describe any existing silicon that would
require this?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Muranyi, Arpad
Sent: Monday, August 27, 2012 12:07 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Lets go all the way!
Walter,
I think you may have misunderstood my comment last Friday,
because I don't remember saying what you write below. I
don't even see myself saying it, because I don't think there
is really a "problem that legacy IBIS combines both package and die
models in .ibs files", because the most accurate package modeling
syntax that is available in IBIS currently allows the [Define
Package Model] keyword (and its content) to be either in the
.ibs or the (separate) .pkg file. Either way, I am really
not very concerned about having things in one or multiple
files.
My comment last Friday was about the mechanism by which the
IBIS specification defines and instantiates [Model]s using
the [Pin] keyword. This was OK in the days when the number
of pins were the same as pads and the package had a one-to-one
pin to pad path. But now that we are talking about arbitrary
pin and pad relations, and now that we are talking about
adding to this an also arbitrary pad to buffer terminal on-die
interconnect modeling capability, we can no longer rely on
defining and instantiating [Model]s using the pin names. I
made the suggestion on Friday, that if we "overhaul" IBIS
with significant changes as you suggested in your presentation,
we should also consider this and instantiate [Model]s the
right way. Doing this the right way might make the rest of
the package and on-die interconnect syntax cleaner.
Thanks,
Arpad
================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Walter Katz
Sent: Sunday, August 26, 2012 2:03 PM
To: IBIS-ATM
Subject: [ibis-macro] Lets go all the way!
All,
In the Friday Open Forum meeting Arpad raised a question that reflects the
problem that legacy IBIS combines both package and die models in .ibs files. I
believe the answer to this question is to split up "components" into a package
EMD file and a die IBISx file.
The enclosed presentation illustrates this using the example legacy IBIS file
in my last presentation.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
