[ibis-macro] Re: I hope you all got home safe and sound ...
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: "Bradley Brim" <bradb@xxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 3 Feb 2014 21:12:17 -0500 (EST)
Brad,
Your points are well taken. The ideal situation is to have a full package
model. We often deal with 1000 pin components, so an s2000p will give the
complete information that is required, and my proposed format will support
such models. Today we have to live with what is supplied to us by IC
Vendors. For SerDes, this is commonly an s4p (with no crosstalk
information), or s12p and sometimes s20p. So I think we need a solution
that will support the full s2000p as well as the s12p solutions. We have
had to deal with parts where even these have not been available, so we
have has to make our own measurements to get models that are sufficiently
accurate to be able to make engineering decisions. This is a time
consuming and expensive proposition (it takes many s4p measurements to
build an s12p, and doing this for a full package is cost prohibitive). In
some cases we have had to resort to grinding down a package, making
photographs of each layer interconnect, getting package cross sections,
and making TDR measurements to be able to get models of sufficient
accuracy. It is not SiSoft but a number of IC Vendors who have decided
that "swathing" models are sufficient to do accurate insertion loss and
return loss of channels, and sufficient crosstalk information to enable
engineering to make proper design decisions. This is not an IBIS modeling
strategy the forces a design methodology, but a modeling strategy that
will support both rigorous models, and simpler models that IC Vendors are
currently able to produce and deliver. I think we need to support both,
and enable IC Vendors to deliver models with required accuracy and detail.
My question to you is "Should we define a modeling format that only
supports the s2000p approach, or should we define a modeling format that
supports both an s2000p approach and an s12p approach?
Walter
PS. I understand that your use the word "swathing" is not "swathing" in
the ICM sense, but in this case models that have very accurate insertion
loss and return loss, and approximate crosstalk. The accurate insertion
loss and return loss are necessary to accurately predict ISI, while the
approximate crosstalk models are used to bound crosstalk noise.
From: Bradley Brim [mailto:bradb@xxxxxxxxxxx]
Sent: Monday, February 03, 2014 7:01 PM
To: wkatz@xxxxxxxxxx; IBIS-ATM
Subject: RE: I hope you all got home safe and sound ...
Hello Walter,
I have a few concerns.
First and most fundamental is that we seem to be pursuing not so much the
definition of a package (or on-die, implicitly addressed in the following
but not explicitly included) model but we seem to be defining a
methodology of building-up full package models based on incomplete or
approximate information. I will generally refer to this as "swathing" but
it can include much more, such as how to implement unknown aggressors
during the application of such models in an EDA tool. We have learned from
our previous IBIS package model approaches that defining approximations
and fixed topologies is of time-limited applicability. For years now we've
had the tools to generate full package models, whether based on a swathed,
single, uncoupled, ideal-power 2-port circuit or from a full-package
extraction including power. Yet, we still have no way to include this in
an IBIS standard manner. I don't want to endorse a standard that specifies
partial models but does not specify how the simulation algorithms should
apply them. The latter has not been discussed and I believe until we do so
that any proposal is incomplete.
Next, we are comparing a set of "BIRDs" whose careful and precise
documentation was led by Arpad versus your "proposal". I believe that
anyone, whether Arpad or you or a third party observer, could apply the
BIRDs to develop examples. If an example does not fit into the BIRDs then
they need to be considered for update. I perceive your proposal as
continuing to develop with changes and augmentations considered each week.
You and you alone are able to generate examples. It may be time to convert
your proposal to a BIRD and upload so that others may know the extent of
your proposal and be able to independently create examples.
Lastly, the examples we use for comparison should be documented with basic
design information and then each set of BIRDs applied to format that
general design data. Maybe a subtle point but it is the base design
information that must be applied as a reference, not one format or the
other. The base design information may also solicit ideas for additional
considerations that should be covered by the BIRDs. I applaud the
information you specified in your message about the corners and how often
the behavior falls into each of the three bins. I believe we need to
explicitly choose whether or not to do something specific with such data
or we should not specify it in the format, even if it is useful design
information in certain cases and one or more EDA tools might consider it
in some manner.
Best regards,
-Brad
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Monday, February 03, 2014 10:14 AM
To: IBIS-ATM
Subject: [ibis-macro] FW: I hope you all got home safe and sound ...
All,
I would hope that we can quickly make a choice between my package proposal
and BIRDs 163/165. I think there are compelling reasons to go with my
proposal.
First, anything that BIRDs 163/165 can do can be done with my packaging
proposal - so I challenge Arpad and Ambrish to put together a real example
that can be done in BIRDs 163/165 that cannot be done more easily in my
proposal without any loss of functionality.
Second, I will produce a series of Real Life examples, that we can compare
the package models between the two methods. The first challenge to BIRD
163/165 is a package model given to me by an IC Vendor (also an IBIS
member). It is a package model for a SerDes bus, names and numbers have
been changed so as not to indicate any IP. The SerDes bus has 16 Tx and 16
Rx. The package models are three s12p Touchstone files, with 4 ports
representing a victim channel and the other 8 ports representing 2
aggressor channels. The three s12p represent package process corners (not
necessarily speed) that are not correlated to silicon model Typ/Min/Max.
60% of parts have package process corner Typ, 20% have package process
corner Min, and 20% have package process corner Max.
This method of supplying package models for SerDes buses is far from
unique to this IC Vendor, we have received this exact same type of package
model from multiple SerDes vendors. This is the standard way that 802.3
and PCIe standards bodies distribute informative package models. The only
difference is that we sometimes get s20p models with four aggressors
instead of two aggressors, and sometimes the aggressors have a mixture of
FEXT and NEXT aggressors, this example has only FEXT aggressors since the
NEXT and FEXT channels are highly isolated in the package.
The IBIS [Component] sections is:
[Pin]
A0 TxP0 Tx
A1 TxP1 Tx
A2 TxP2 Tx
A3 TxP3 Tx
A4 TxP4 Tx
A5 TxP5 Tx
A6 TxP6 Tx
A7 TxP7 Tx
A8 TxP8 Tx
A9 TxP9 Tx
A10 TxP10 Tx
A11 TxP11 Tx
A12 TxP12 Tx
A13 TxP13 Tx
A14 TxP14 Tx
A15 TxP15 Tx
B0 TxN0 Tx
B1 TxN1 Tx
B2 TxN2 Tx
B3 TxN3 Tx
B4 TxN4 Tx
B5 TxN5 Tx
B6 TxN6 Tx
B7 TxN7 Tx
B8 TxN8 Tx
B9 TxN9 Tx
B10 TxN10 Tx
B11 TxN11 Tx
B12 TxN12 Tx
B13 TxN13 Tx
B14 TxN14 Tx
B15 TxN15 Tx
C0 RxP0 Rx
C1 RxP1 Rx
C2 RxP2 Rx
C3 RxP3 Rx
C4 RxP4 Rx
C5 RxP5 Rx
C6 RxP6 Rx
C7 RxP7 Rx
C8 RxP8 Rx
C9 RxP9 Rx
C10 RxP10 Rx
C11 RxP11 Rx
C12 RxP12 Rx
C13 RxP13 Rx
C14 RxP14 Rx
C15 RxP15 Rx
D0 RxN0 Rx
D1 RxN1 Rx
D2 RxN2 Rx
D3 RxN3 Rx
D4 RxN4 Rx
D5 RxN5 Rx
D6 RxN6 Rx
D7 RxN7 Rx
D8 RxN8 Rx
D9 RxN9 Rx
D10 RxN10 Rx
D11 RxN11 Rx
D12 RxN12 Rx
D13 RxN13 Rx
D14 RxN14 Rx
D15 RxN15 Rx
[Diff Pin]
A0 B0
A1 B1
A2 B2
A3 B3
A4 B4
A5 B5
A6 B6
A7 B7
A8 B8
A9 B9
A10 B10
A11 B11
A12 B12
A13 B13
A14 B14
A15 B15
C0 D0
C1 D1
C2 D2
C3 D3
C4 D4
C5 D5
C6 D6
C7 D7
C8 D8
C9 D9
C10 D10
C11 D11
C12 D12
C13 D13
C14 D14
C15 D15
Package Model in my format:
[Begin Package Models]
|
[Begin Package Model] Tx
Language Touchstone
File PDF .2 Tx_Min.s12p .6 Tx_Typ.s12p .2 Tx_Max.s12p
Ports Pin_Mod+.Tx.1 Pin_Mod-.Tx.1 Buf_Mod+.Tx.1 Buf_Mod-.Tx.1
Ports V_Pin_Mod+.Tx.2 V_Pin_Mod-.Tx.2 V_Buf_Mod+.Tx.2 V_Buf_Mod-.Tx.2
Ports Pin_Mod+.Tx.3 Pin_Mod-.Tx.3 Buf_Mod+.Tx.3 Buf_Mod-.Tx.3
[End Package Model]
|
[Begin Package Model] Rx
Language Touchstone
File PDF .2 Rx_Min.s12p .6 Rx_Typ.s12p .2 Rx_Max.s12p
Ports Pin_Mod+.Rx.1 Pin_Mod-.Rx.1 Buf_Mod+.Rx.1 Buf_Mod-.Rx.1
Ports V_Pin_Mod+.Rx.2 V_Pin_Mod-.Rx.2 V_Buf_Mod+.Rx.2 V_Buf_Mod-.Rx.2
Ports Pin_Mod+.Rx.3 Pin_Mod-.Rx.3 Buf_Mod+.Rx.3 Buf_Mod-.Rx.3
[End Package Model]
|
[End Package Models]
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
