[ibis-macro] Re: The EMD like syntax of package and on-die interconnect models
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'Scott McMorrow'" <scott@xxxxxxxxxxxxx>
- Date: Wed, 18 Sep 2013 18:23:58 -0400 (EDT)
Scott,
You should limit yourself to extending my proposed format, you can do it
based on BIRD 125, or BIRD 145, or come up with a totally new format.
Walter
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, September 18, 2013 5:38 PM
To: 'Scott McMorrow'
Cc: 'IBIS-ATM'; 'Randy Wolff'
Subject: RE: [ibis-macro] The EMD like syntax of package and on-die
interconnect models
Scott,
The example are the kinds of models that we receive from IC Vendors.
Please use the syntax I have proposed, and demonstrate how you would
describe the terminals of a model that you think IC Vendors should be
delivering. When I say using my syntax, I mean that there are branches in
package models of the form
(<terminal number> (Pin (<keyword> <Value>) (<keyword> <value>) ..)
(<terminal number> (Pad (<keyword> <Value>) (<keyword> <value>) ..)
And the branches in on-die models of the form:
(<terminal number> (Pad (<keyword> <Value>) (<keyword> <value>) ..)
(<terminal number> (Buffer (<keyword> <Value>) (<keyword> <value>) ..)
The <terminal number> is also the port or node of the sNp or the .subckt.
Please do not get hung up by the parameter tree syntax, we could implement
this same functionality with an IBIS like keyword syntax, e.g.
(sdram
(DQ0 | s2p for this specific pin (C2)
(Tstonefile_File (Corner DQ0_typ.s2p DQ0_min.s2p DQ0_max.s2p))
(Terminals
(1 (Pin (Pin_Name C2)))
(2 (Pad (Pad_Name C2)))
)
)
Could have been implemented as
[IBIS-ISS Package Models] sdram
[Package Model] DQ0
Tstonefile DQ0_typ.s2p DQ0_min.s2p DQ0_max.s2p
[Begin Terminals]
Terminal 1
Terminal_Type Pin
Pin_Name C2
Terminal 2
Terminal_Type Pad
Pin_Name C2
[End Package Model]
So propose a specific syntax for your approach, and document exactly how
an IC Vendor should generate such a model, and how an EDA tool should use
such a model.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Wednesday, September 18, 2013 5:24 PM
To: Walter Katz
Cc: IBIS-ATM; Randy Wolff
Subject: Re: [ibis-macro] The EMD like syntax of package and on-die
interconnect models
There is a not to subtle difference between supplying models that
accurately represent the part, and supplying models that represent a
conservative model. Supplying a model with a part is an inferred warrantee
that could affect the production yield of a part, so IC Vendors
(especially high volume ones) will be conservative on their models, often
specifying the models using typ/min/max models from a standard as opposed
to actual accurate models.
This is a false choice. There is no inferred or implied warranty. A
disclaimer usually is attached to a model.
"Do you object that our package solution support both detailed aggressor
information as you support and bounded aggressor information?"
Your approach is a subset of mine. With my approach you can created a
bounded model. It's very simple. A list of Drivers. A list of
Receivers. A List of Receivers available for crosstalk analysis (which is
a subset of the list of receivers), and a method to indicate those drivers
and receivers that are in proximity to the analyzed receiver. The list of
proximate I/O cells is optional for models encapsulated within a package,
since by definition they are proximate.
On Wed, Sep 18, 2013 at 5:15 PM, Scott McMorrow <scott@xxxxxxxxxxxxx>
wrote:
Walter
A generic model can specify Drivers, receivers, and proximity to the
target receiver. If you want I can go through each one of your examples
and show that it can be done in this way. Or ... do you already have
models that you are forcing the specification around?
On Wed, Sep 18, 2013 at 5:05 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
Scott,
Scott, with all due respect, your approach is most accurate, and I expect
you will try to convince IC Vendors to supply the models in your format;
our packaging solution must support such models. You should not be
surprised that many IC Vendors (and particularly those that have very few
letters in their names) will not supply such model in your format, but
that they supply models that are either generic to a bus with generic
worst case aggressors, or are specific to a pin for the victim through
path with generic worst case aggressors; our package solution must support
this as well.
There is a not to subtle difference between supplying models that
accurately represent the part, and supplying models that represent a
conservative model. Supplying a model with a part is an inferred warrantee
that could affect the production yield of a part, so IC Vendors
(especially high volume ones) will be conservative on their models, often
specifying the models using typ/min/max models from a standard as opposed
to actual accurate models.
Do you object that our package solution support both detailed aggressor
information as you support and bounded aggressor information?
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Wednesday, September 18, 2013 4:22 PM
To: Walter Katz
Cc: IBIS-ATM; Randy Wolff
Subject: Re: [ibis-macro] The EMD like syntax of package and on-die
interconnect models
Walter, with all due respect, all one needs to know are three pieces of
information:
1) where are all receivers and drivers
2) what receiver are we currently measuring
3) what drivers in near end proximity to the receiver.
with those three pieces of information, all crosstalk methodologies can be
implemented. One does not need special cases to describe each potential
methodology.
Scott
On Wed, Sep 18, 2013 at 4:02 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
Scott,
There is more than one way to skin a cat. There are crosstalk
methodologies that do not care about victim and aggressors. There are
crosstalk methodologies that do care which terminals are victims and
aggressors. An IC vendor can and will choose the way they are going to
construct and distribute these models. We need to be able to support both
methodologies.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Wednesday, September 18, 2013 2:38 PM
To: Walter Katz
Cc: IBIS-ATM; Randy Wolff
Subject: Re: [ibis-macro] The EMD like syntax of package and on-die
interconnect models
i disagree with victim aggressor constructs. All that needs to be known
is the location of the drivers and receivers, and grouping of such for a
general solution.
On Wed, Sep 18, 2013 at 2:35 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
All,
I am enclosing a presentation which demonstrates the simple language used
to describe both the package and on-die interconnect models using the EMD
like methodology applied to all of the types of models that IC Vendors are
requesting to deliver.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
