[ibis-macro] Using EBD for stacked die package modeling?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 17 Aug 2012 05:40:54 +0000
Walter,
First, let's get a typo out of the way. Under "In IBIS 5.0:" you
actually quoted something from one of my earlier emails, not
something out of the IBIS v5.0 specification, but I assume you
were trying to quote something from Section 8 on pg. 165...
Anyway, I think we can quote websites, BIRDs, and the IBIS
specification all we want in attempt to prove what some of
these words mean, and we will not succeed, because these
terms are used rather imprecisely. Depending on who we quote
and when that quote was written we can find a "definition"
that we like to prove our own point. It doesn't look like
we are going to be able to settle our difference of opinions
that way.
I also want to state it upfront that I do not dispute whether EBD
could be used the way you propose. What I am saying is that using
it that way was not intended, and it doesn't fit in with the way
the specification is structured.
Instead of trying to prove what "package" and "substrate" really
mans, I would like to point out a few technical things from
Section 8 (pg. 165) in v5.0. The first sentence starts out like
this:
| A "board level component" is the generic term to be used to describe a
| printed circuit board (PCB) or substrate which can contain components or
| even other boards...
Note that this is sort of a definition of what a "board level
component" is. Also note that in IBIS we have a keyword, called
[Component] which is a container for the pin list in the [Pin] keyword,
the [Package] and [Package Model] keywords, and the [Model] keywords,
among many others. The point here is that in IBIS a [Component] is
a packaged chip. Contrast that with "board level component" in EBD,
which is defined as a PCB that holds components = [Component]s,
i.e. packaged chips. That's what a SIMM or DIMM looked like in our
eyes when we wrote IBIS and EBD in the 90's. Yes, there were MCM-s
and other fancy devices in those days too, but they were usually used in
expensive supercomputers, not commodity PC motherboards, and IBIS was
really not targeted for simulating the unusual, rare or expensive stuff.
Those guys used SPICE for everything they did, because the thinking was
that SPICE is the most perfect and accurate way to model and simulate
everything.
The next sentence in Section 8 says:
... The electrical connectivity of such a board level
| component is referred to as an "Electrical Board Description".
These first two sentences make it very clear to me that EBD was
invented to model a small PCB with packaged chips on it.
Now, why do I say that your proposed way of using EBD for MCM-s
or stacked die memory chips doesn't fit in with the way the
specification is structured?
Look at the keyword hierarchy in Section 3a, pg. 13 in v5.0.
We have [Component], under which we have [Pin], [Package],
[Package Model]. The [Model] and [Define Package Model]
keywords are on the same level as [Component] so that multiple
components can use them if they are in the same .ibs file.
The "Node" subparameter of the [Path Description] keyword of
EBD contains reference designators and pin names to instantiate
and connect to a pin of an IBIS [Component] or another "board
level component", i.e. another EBD model (pg. 172):
| Each reference designator is followed by the name of the .ibs
| or .ebd file containing the electrical description of the
| component or board, then the name of the component itself as
| given by the .ibs or .ebd file's [Component] or [Begin Board
| Description] keyword respectively.
If an IBIS [Component] is a packaged die, or if an EBD is a
"board level component" which carries multiple packaged dice,
it doesn't look right to me to consider EBD the package of
multiple unpackaged dice and call it the package model of a
stacked die module or MCM. This feels like a circular reference
to me or walking up-side down on the ceiling of a room, etc...
Again, I don't dispute that this couldn't be done, but I feel
that it would clutter the specification and make it confusing.
The way I think this could be done correctly is by adding a new
keyword to IBIS under the [Component] keyword and another one
in parallel with it. We could call the first one [Die Model]
and the second one [Define Die Model] or similar. This way an
IBIS [Component] could contain a definition and call to a package
(or multiple slices of a package, if you will) and contain one
or more die definitions and calls. The [Define Die Model]
could then have a [Pads] keyword (or similar) to define all of
its on-die connection points (nodes) and the package and on-die
interconnect instances could then be simply connected to the pins
listed under the existing [Pin] keyword, and the proposed [Pads]
keywords of the die instance(s). While we are at it, we could
also make the necessary changes to instantiate the [Model]s in
the die definition instead of the [Pin] keyword, and do it so
that the [Model] terminals are all available so that on-die
interconnects could also be inserted between the pads and [Model]s
easily.
By doing this we could finally get rid of the age old problem of
the assumed pads, and assumed one-to-one paths in the package, etc...
This would handle single die or stacked die devices cleanly and
appropriately as it is done in hardware. This way we wouldn't
have to worry about giving a face lift to EBD's clunky syntax...
Thanks,
Arpad
====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Thursday, August 16, 2012 9:10 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: [ibis-macro] Re: Topics for 8/21/12 IBIS-ATM meeting
Arpad,
From http://en.wikipedia.org/wiki/Multi-chip_module
A multi-chip module (MCM) is a specialized electronic package where multiple
integrated circuits<http://en.wikipedia.org/wiki/Integrated_circuit> (ICs),
semiconductor dies or other discrete components are packaged onto a unifying
substrate, facilitating their use as a single component (as though a larger
IC). The MCM itself will often be referred to as a "chip" in designs, thus
illustrating its integrated nature.
In IBIS 5.0:
- it was designed to describe the printed circuit BOARDs
of memory modules in the days when memory modules used to
be modeled as a lumped capacitance and we felt that more
details were necessary to find the timing to the memory
chips on these memory modules
In BIRD 36.3
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 36.3
ISSUE TITLE: Electric Descriptions of Boards
REQUESTER: Stephen Peters, Intel, Hank Herrmann, AMP
DATE SUBMITTED: June 23, 1996, Feb. 13, 1997, March 7, 1997, March 31, 1997
DATE ACCEPTED BY IBIS OPEN FORUM: April 8, 1997
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related
type components that consist of one or more ICs mounted on a PCB board that
connects them to a system thru a set of pins. The following BIRD proposes a
new type of file called .ebd (Electrical Board Description) that
addresses this need. This proposal does not encompass an electrical
description of connectors and other interconnect devices.
So the statement of the issue for BIRD 36.3, the EBD BIRD, states quite clearly
that EBD satisfies the
"need to describe SIMM modules". According to Wikipedia a SIMM (similar to a
DIMM) is
"a specialized electronic package where multiple integrated
circuits<http://en.wikipedia.org/wiki/Integrated_circuit> (ICs), semiconductor
dies or other discrete
components are packaged onto a unifying substrate". That substrate could be a
"board" using FR4, or ceramic.
So from the very beginning EBD was targeted to packages (using either board or
ceramic substrates), and in practice,
every EBD file I have seen has been for packages that are mounted either
vertically (SIMM, DIMM) or horizontally (mezzanine style).
I think the above statements clearly resolve the issue. You may think that it
"is not the right thing to do",
But the BIRD Statement of the Issue, IBIS 5.0, Wikipedia, and common practice
say otherwise.
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: Thursday, August 16, 2012 8:39 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Topics for 8/21/12 IBIS-ATM meeting
Walter,
I am sorry, but I did not get the impression that anything has been
resolved in the email thread we had on EBD. At this time I still
maintain my position that using EBD for package modeling is not the
right thing to do. I know you see things differently, but I don't
think that this difference between our views were resolved by any
means.
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: Thursday, August 16, 2012 6:52 PM
To: IBIS-ATM
Subject: [ibis-macro] Topics for 8/21/12 IBIS-ATM meeting
All,
It has been resolved via e-mail thread that EBD files describe modules
containing two or more IC's. These modules can be boards, or packages.
Arpad and I plan to evaluate this syntax and the BIRD 125 and 145 syntax and
report to the committee with our recommendations.
The enclosed presentation summarizes all of the proposed parameter tree syntax
by using simple examples that demonstrate the proposed package modeling
functionality for IBIS 6.0.
I previously sent out an example applying this functionality to an EBD example.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
