[ibis-macro] Re: EBD Modeling was originally meant to describe packages ...
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 15 Aug 2012 18:04:26 +0000
Walter,
The article in the link you quoted says that:
"Single In-line Memory Module (SIMM) is a small circuit board designed to hold
memory chips"
(emphasis added). Later they say:
"These circuit boards or modules are known as packages"
which indicates to me that while these are technically
circuit boards, some people also call them packages
(I would add, incorrectly).
The quote from BIRD 36:
"that consist of one or more ICs mounted on a PCB board"
indicates to me that we thought of the SIMM as a PCB board and
not as a package (as the article above seems to put it)...
Anyway, could we put this argument to rest and focus on the
proposals we are trying to discuss?
All I am trying to say is that I would prefer to see a complete
package modeling solution in one place, the .pkg file, which
supports stacked die components. If no-one agrees with my desire
of having this feature in the package modeling specification, I
will shut up, but I would like to hear what others have to say
about this.
Thanks,
Arpad
==================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, August 15, 2012 12:16 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: EBD Modeling was origionaly meant to describe packages ...
Arpad,
Going back to BIRD 36.2:
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.
A SIMM is a type of memory package
(http://computer-building-repairs.knoji.com/types-of-memory-packages
So how can you say that EBD was not meant to describe packages?
I am enclosing three presentation that I gave 4 years ago about Electronic
Module Design (EMD). These presentations were put on hold because we needed
IBIS-ISS as the language to describe interconnect in a Module.
EMD was designed to handle general boards as well as what we currently call
EBD, Package, MCM. The committee made a clear decision at that time that
"Boards" and "Connectors Between Boards" was the real of the EDA companies, and
should not be made an IBIS standard.
If you peruse these documents you can see that the latest proposals I have made
are essentially the same concepts as what I had proposed 4 years ago, but with
different syntax and some additional capability to reflect what I have learned
in the last 4 years.
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: Wednesday, August 15, 2012 12:29 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Walter,
I knew you will comment on the word "substrate" ... :)
The problem is that this word is not defined in the IBIS
specification. When I first learned this word, it meant
the silicon substrate of the die on which the various
layers were deposited to make the integrated circuit.
Then came the BGA-s (and MCM-s) and those tiny green
printed circuit boards which carried the black plastic
molding of the package that encapsulated and protected
the die. When I first saw these, I considered the green
tiny plates printed circuit boards, but they started to
call them substrates. First time I heard that, I was
really surprised because I thought substrate was part
of the die.
Now you say that substrate is the package.
This is a good illustration how a word can mean different
things at different times in history.
Here is a definition from an online dictionary:
http://www.thefreedictionary.com/substrate
I really like #3 in this definition, which basically says
that a substrate is a substratum. That tells me a lot... :)
Well to be fair, it also says that it is an underlying layer.
By this definition, we can start calling a printed circuit
board a substrate also because it is an underlying layer
below all the components which are soldered onto them...
Either way, this is why it is so hard to write a specification.
Even in a decade or so time, the meaning of words can change
and then we get into these discussions. But reading the word
in context, I still maintain that when we wrote EBD we were NOT
thinking about package modeling. Another point that supports
this reasoning is that the EBD syntax is almost identical but
inferior to the .pkg syntax in IBIS. In EBD we didn't include
the RLC matrix syntax, only the T-line syntax because we were
thinking about transmission lines on printed circuit boards.
RLC matrices and bond wires, etc... seemed to be more applicable
for package modeling in the days when EBD was conceived and
written, and the fact we left these out from EBD indicates to
me that we didn't intend to use it for package modeling...
Anyway, I don't want to dwell on history. I would just like to
have a package modeling syntax that can do stacked die also. I
don't think we should chop things up so that we would need three
different files (.ibs, .pkg, and .ebd) for stacked die package
models. I would prefer to be able to do that in the package
modeling syntax and .pkg file. I think it would be cleaner and
less confusing that way.
Thanks,
Arpad
================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Wednesday, August 15, 2012 10:49 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Arpad,
| A "board level component" is the generic term to be used to describe a
| printed circuit board (PCB) or substrate
A substrate is a package.
The following statement may have been the motivation for EBD, but this text
does not appear 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
The common usage of EBD files includes memory Dimms and Multi-Chip Modules
(MCM). The example is an MCM package which contains two memory packages that
are stacked.
I am enclosing three files:
1. Legacy.ebd is extracted from a real memory EBD file representing a
package currently being delivered by an IC Vendor. I redacted the name of the
Vendor. This is a subset of the pins in the original EBD file containing 3 DQ
(single ended data), one DK (differential clock), and one A (single ended
address). This package contains two memory packages which are stacked. The
memory packages themselves are Small Outline Packages (SOL) which will have
their own package models.
2. IBIS-ISS.ebd is this same package rewritten using my proposed syntax.
I include Gd and Rs on all of the wline models (the IC Vendor added these as
comments in the Legacy.ebd file).
3. IBIS-ISS_Tstonefile.ebd is this same package rewritten using my
proposed syntax using Touchstone models. The DK is done as a differential
model. I added a Power subckt and a coupled model for one of the DQ models.
Features that are left as an exercise for the user:
Full package models.
Interface package models.
Bank package models.
Coupling between signal and power.
I do not think that IBIS-ISS package need to support the "Model_name" feature
that we need to support in .ibs files.
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: Wednesday, August 15, 2012 10:23 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Walter,
I would disagree with "This is exactly what EBD was designed for".
- its name says Electrical BOARD Description
- 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
- the introduction to Section 8 on pg. 165 of the v5.0 spec
tells everyone very clearly what its purpose is:
|=============================================================================
|=============================================================================
| Section 8
|
| E L E C T R I C A L B O A R D D E S C R I P T I O N
|
|=============================================================================
|=============================================================================
|
| 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.
|
| A fundamental assumption regarding the electrical board description is that
| the inductance and capacitance parameters listed in the file are derived
| with respect to well-defined reference plane(s) within the board. Also,
| this current description does not allow one to describe electrical
| (inductive or capacitive) coupling between paths. It is recommended that if
| coupling is an issue, then an electrical description be extracted from the
| physical parameters of the board.
Whether EBD is "being used for, and are being delivered for" stacked die or
multi-chip modules is a different question. You can use fertilizers
to grow plants, but you can use them to make bombs also...
Thanks,
Arpad
=====================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Wednesday, August 15, 2012 7:14 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Arpad,
The following statements are totally incorrect:
Using EBD as a package to house multiple components (each of
which describes a packaged die) looks a little strange to me,
even if the component's package model is zeroed out.
For this reason I think that using EBD for multi-chip package
modeling is NOT the right thing to do. It simply doesn't fit
the IBIS hierarchy.
This is exactly what EBD was designed for, and are being used for, and are
being delivered for.
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: Wednesday, August 15, 2012 1:44 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Hello everyone,
I feel that it would be a little too early to take a vote with
these questions, because it seems that there are a few things
we need to clear up first. Here is one issue:
Randy commented today that he would like to have multi-chip
capabilities within a package. This is not listed in the
questions. I do remember Walter's answer to that comment
being that we can do it with EBD, but I am not so sure about
that. It seems that we have a hierarchical problem there.
Looking at "Section 3a" in the v5.0 specification on pg. 13
I see [Package] and [Package Model] under [Component]. This
indicates that [Component] doesn't refer to a die, but it
refers to a packaged die. In order to have multiple, possibly
different dice in the same package, we would need to have
another keyword which is lower than [Package] or [Package Model]
in the hierarchy for the die. Currently we don't have this.
The IBIS specification seems to be architected with the one
die per package assumption.
Looking at the architecture of the EBD specification, I see
the [Reference Designator Map] keyword which is responsible
to associate any reference designators (U1, U2, etc...) listed
in any "Node" entries of the .ebd file with an .ibs file and
component name. The syntax in EBD is RefDes.PinName where
PinName is the pin name of a component. This clearly assumes
that a component that is referenced by the reference designator
of EBD is a packaged die (since it is using a pin name, not a
pad name).
Using EBD as a package to house multiple components (each of
which describes a packaged die) looks a little strange to me,
even if the component's package model is zeroed out.
For this reason I think that using EBD for multi-chip package
modeling is NOT the right thing to do. It simply doesn't fit
the IBIS hierarchy.
Comments, questions welcome.
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: Tuesday, August 14, 2012 4:19 PM
To: IBIS-ATM
Subject: [ibis-macro] Straw Poll vote on IBIS-ISS Package Modeling
All,
I have put 28 questions in a spreadsheet. I think it will take too much time to
do the voting in the meeting, so I request that you put entries 1:4 in column 1
of each question. The meanings of 1:4 are.
4
Advocate I need this!
3
Support I support this
2
Abstain I have no opinion
1
Object I object to this functionality
Return them to me or all IBIS-ATM and I will collate the results and publish
them by Tuesday AM. I am including the .xlsx file in case you have difficulty
editing the spreadsheet in the body of this e-mail. Also including this and
last weeks presentation.
Walter
4
Advocate I need this!
3
Support I support this
2
Abstain I have no opinion
1
Object I object to this functionality
Should we add keywords Pullup_Signal_name, Pulldown_Signal_name,
Power_clamp_Signal_name, and Ground_clamp_Signal_name to the [Model] section?
Should we add a section to the .ibs file to define the voltage values of supply
signal names?
Should we add a list of supply die pad names?
Should we add an x-y coordinate for each pin and die pad?
Should we support two signal pins connected to the same die pad (Forked Signal)?
Should we be able to associate a package model with a [Model]?
Should we be able to associate a package model with a Pin_name?
Should we be able to associate a coupled package model with a [Model]?
Should we be able to associate a coupled package model with a list of Pin_names?
Should we support package models with coupling between signals and power?
Should we support a coupled package model that hooks up to two or more [Model]
names?
Should we support package models with more than 3 corners?
Should we support package Touchstone files directly?
Should we support sparse usage of large package Touchstone files?
Should we support package "Quadrants" (e.g. Banks, Interfaces)?
Should we support full package models?
Should we support on-die models?
Should we be able to associate an on-die model with a [Model]?
Should we be able to associate an on-die model with a Pin_name?
Should we be able to associate a coupled on-die model with a [Model]?
Should we be able to associate a coupled on-die model with a list of Pin_names?
Should we support on-die models with coupling between signals and power?
Should we support a coupled on-die model that hooks up to two or more [Model]
names?
Should we support on-die models with more than 3 corners?
Should we support on-die Touchstone files directly?
Should we support sparse usage of large on-die Touchstone files?
Should we support on-die "Quadrants" (e.g. Banks, Interfaces)?
Should we support full on-die models?
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
