[ibis-macro] Re: I hope you all got home safe and sound ...
- From: Bradley Brim <bradb@xxxxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 3 Feb 2014 16:00:52 -0800
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
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
