[ibis-macro] Re: I hope you all got home safe and sound ...
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: "bradb@xxxxxxxxxxx" <bradb@xxxxxxxxxxx>
- Date: Tue, 4 Feb 2014 09:46:25 -0500
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 <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
Teraspeed(R) is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
