[ibis-macro] Re: I hope you all got home safe and sound ...
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: "Scott McMorrow" <scott@xxxxxxxxxxxxx>, <bradb@xxxxxxxxxxx>
- Date: Tue, 4 Feb 2014 10:28:04 -0500 (EST)
Scott,
This should be impetus for implementing Sparse Matrix format in Touchstone
"3". The Sparse Touchstone format proposed in October 2009 would reduce
the size of your 36GB model based on the number of matrix elements that
are zero at all frequencies (or effectively 0) and the number of matrix
elements that are the same at all frequencies (or effectively the same).
Based on this do you have any indication on how much this would reduce the
size of your model?
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Tuesday, February 04, 2014 9:46 AM
To: bradb@xxxxxxxxxxx
Cc: wkatz@xxxxxxxxxx; IBIS-ATM
Subject: Re: [ibis-macro] Re: I hope you all got home safe and sound ...
brad
I just recently completed a modeling effort where I extracted an s654p
file to model DDR, Serdes, power, and all ancillary signals on a fairly
interesting custom processor package. This was then integrated with the
RLC model extraction of the die redistribution layer. The resulting model
was 36GB uncompressed. Full package model extraction was used to derive
the full-wave behavior and identify non-local noise problems, which are a
huge problem with packages as we push to higher bandwidths.
The model was then processed with custom software to identify absolute
worst case paths, from the perspective of insertion loss, return loss and
signal-to-noise ratio. Using this methodology, any model of any number of
aggressors can be reduced and extracted from the full package model, from
s2p to swhateverp. In my system work, i find that i need larger than an
s4p or even s12p model for a serdes package, in order to simulate the
fully coupled path through a backplane connector onto a backplane. Most
backplane connectors are poorly localized for common mode, which requires
that 3 to 5 wafers of differential pairs must be modeled in order to
simulate worst case crosstalk induced noise and jitter. This amounts to a
minimum of 9 differential pairs modeled, to as many as 25 differential
pairs (s36p to s100p).
Given that there is not a one-to-one mapping of the serdes package paths
to the connector paths, I often require a model that just does not exist
from the device manufacturer, unless I create it myself. What I receive,
instead, is a much smaller model that has to be replicated and mapped into
the connector path. Below 10G rates, this does not impose a huge accuracy
hit. However, at higher rates, it is a problem. Lack of near-die
non-localized coupling information will render the total system
interconnect model an interesting academic exercise that does not
represent the actual behavior of the links, generally turning simulation
models into analog hallucinations.
I am a fan of having a "side car" data structure along side an s-parameter
model, in order to be able to unambiguously identify the side of the model
where Tx ,Rx, and BI models will eventually be attached, when it is
possible. This allows for post processing to easily identify cases of
interest that can then be modeled with reduction techniques and simulated.
In addition, the "side car" should identify bus groups, and sub-groups,
that would allow for efficient identification of different types of Serdes
interfaces, memory interfaces ... etc, for effective modeling and
simulation.
It is not until I have fully identified worst case passive links for
simulation that I instantiate active models. In fact, most of the work I
do (and I contend that to be the case for most system designers) can be
done effectively without active analog silicon models. Signal processing
tends to obfuscate real problems in interconnect that should be resolved
first, so that Murphy himself, rising from the grave, does not rear his
ugly head. For me, modeling with active models is the last validation
step in a long interconnect design process.
Now, I recognize that my process is in the best interest of the system
designer who is interested in evaluating the worst case performance of his
design, even though it may not be in the best interest of the
semiconductor company whose simplified models tend to never address the
real margin problems, or worst case paths in their designs. Most package
designers are woefully unaware of the issues that lurk in their designs.
Yet, those simplified models must still be accommodated, even though they
are a poor representation of a real package.
In my opinion, we need the ability to model an entire package completely,
sections of a package completely, and logical sub-sections that have some
sort of minimum/maximum behavior, as defied by the vendor, that can be
easily placed anywhere across the pins of a bus. As with most things,
I'll take the most I can get.
regards,
Scott
On Mon, Feb 3, 2014 at 11:25 PM, Bradley Brim <bradb@xxxxxxxxxxx> wrote:
Hi Walter,
I understand what we're up against and how this is done in practice.
I can easily generate a 2000 pin RLCK lumped model for you. However, it's
an exaggeration to imply we might need an S2000p model. For such a large
package half of the pins might be power/ground and someone we know just
presented an argument you don't need other than a spectral macromodel for
those J Most of the rest are either digital or low speed control and only
the remaining are high speed serdes. The packages where high speed serdes
channels dominant pin count don't have nearly that many pins. Even with
these lower pin count packages it is still an impractical task to model
the entire package all at once.
I only ask that we bound what is done in this area of "swathing", define
it unambiguously and if "unknown" aggressors are included in any manner
that a definitive algorithm for their application in a circuit simulator
be defined.
Swathing of S-parameters, even swathing of L and C parasitics, can cause
non-passivity. Should we provide guidance for dealing with this? Maybe the
loss present will be enough it doesn't matter?
Cheers,
-Brad
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, February 03, 2014 6:12 PM
To: Bradley Brim; IBIS-ATM
Subject: RE: I hope you all got home safe and sound ...
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
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
Other related posts:
