[ibis-macro] Re: Using EBD for stacked die package modeling?
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 17 Aug 2012 08:16:48 -0400 (EDT)
Arpad,
Is there anything in EBD that prevents is from fully describing the
interconnect of an MCM package?
I aver that the answer to this question is "No".
We could clarify this by submitting the following new BIRD against IBIS
5.1:
BIRD XXX
Replace the following text:
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, and which can connect to another board through a set of
user visible pins. The electrical connectivity of such a board level
component is referred to as an "Electrical Board Description". For
example, a SIMM module is a board level component that is used to attach
several DRAM components on the PCB to another board through edge connector
pins. An electrical board description file (a .ebd file) is defined to
describe the connections of a board level component between the board pins
and its components on the board.
With
A "board level component" is the generic term to be used to describe a
printed circuit board (PCB), Multi Chip Module (MCM) or substrate which
can contain components or even other boards and MCMs, and which can
connect to another board or MCM through a set of user visible pins. The
electrical connectivity of such a board level component is referred to as
an "Electrical Board Description". For example, a SIMM module is a board
level component that is used to attach several DRAM components on the PCB
to another board through edge connector pins. An electrical board
description file (a .ebd file) is defined to describe the connections of a
board level component between the board pins and its components on the
board.
Walter
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, August 17, 2012 7:42 AM
To: 'Arpad_Muranyi@xxxxxxxxxx'; 'IBIS-ATM'
Subject: RE: [ibis-macro] Using EBD for stacked die package modeling?
Arpad,
Sorry, the IBIS 5.0 text is:
| 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, and which can connect to another board through a set
of
| user visible pins. The electrical connectivity of such a board level
| component is referred to as an "Electrical Board Description". For
example,
| a SIMM module is a board level component that is used to attach several
DRAM
| components on the PCB to another board through edge connector pins. An
| electrical board description file (a .ebd file) is defined to describe
the
| connections of a board level component between the board pins and its
| components on the board.
Also,
| Keyword: [Reference Designator Map]
| Required: Yes, if any of the path descriptions use the Node
subparameter
| Description: Maps a reference designator to a component or electrical
board
| description contained in an .ibs or .ebd file.
| Usage Rules: The [Reference Designator Map] keyword must be followed by
a
| list of all of the reference designators called out by the
| Node subparameters used in the various path descriptions.
| 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. The reference
designator,
| file name and component name terms are separated by white
| space. By default the .ibs or .ebd files are assumed to
exist
| in the same directory as the calling .ebd file. It is
legal
| for a reference designator to point to a component that is
| contained in the calling .ebd file.
Which says an ebd file can contains .ibs components (packages that contain
single chips), and .ebd "modules" that contain multiple chips.
There are many examples DIMM-IN-A-PACKAGE and MCM products being delivered
today.
http://www.electronicspecifier.com/Memory/DIMM-IN-A-PACKAGE-Solution-Based
-on-xFD-Technology-Invensas.asp
http://www.amkor.com/go/packaging/all-packages/mcm-pbga/mcm-pbga-multi-chi
p-module-plastic-ball-grid-array
There is nothing in the current EBD specification that distinguishes
between FR4 or ceramic substrate.
There is nothing in the current EBD specification that distinguishes
between vertical or horizontal mount.
There is nothing in the current EBD specification that distinguishes
between its component being:
Flip Chips (IC)
Wire Bond Chips (IC)
Small Outline Packages containing a single Chip (IC)
Multi Chip Modules containing multiple Chips (ICs)
So we already have a solution that supports multiple die in a package -
EBD, and it works, and it is currently being used to describe the
interconnect of BGA and PGA packages in addition to SIMM and DIMM packages
. Why would we complicate .ibs when we already have a solution that works
and is successfully being used?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, August 17, 2012 1:41 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Using EBD for stacked die package modeling?
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 <http://en.wikipedia.org/wiki/Integrated_circuit> integrated
circuits (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] 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] 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
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
