[SI-LIST] Re: Internal package aggressors/PCB routing

Chris,
Aha!  The next problem dilemma...
Should I answer and get no reward ...
 ... or ignore it and suffer possible decrement at the hands of the master?

Feels like Super Mario.  :-)

First, my solution works best for a limited region, esp. where these package
effects are out of scope of already taken care of.

first:
Net "x" is eventual victim in final analysis.
Nets y1, y2, ... yN are final analysis aggressors.
Stims are only done with roles reversed, as below in "reciprocal xtalk".
Reciprocity is used to effect the above roles.

Your new problem:  Aggressors' return current on x driver:
1. First, stimulate yn, n=1...N, each alone.  N sims.  In each sim, measure
return current at location of interest for x driver.  Add 'em up.  Use 1 UI
one and zero and you have a building block for any pattern.  The sum is the
xtalk return for net x, what you asked.

Reciprocal xtalk...
2. Proceed as previously stated:  stim x, measure xtalk on y1,...,yN & sum.
That's the total xtalk on victim x, by reciprocity.  This assumes all yn
will have same pattern as x.  If not then, before sum, change x stim to get
different effect on selected y where they will have different stim as
aggressors.  Ie: different pattern (or 1/ 0 UI) per each y net.
3. Run x w/o coupling but w/ return current effect with ICVS or whatever at
the appropriate driver node, controlled by result from #1 above.  Post sim,
add in #2 xtalk at measurement node for x.  Simmer for 3 hrs.  Serve
straight from stove.
4. Send me money if it works.


Regards,
Agathon
 ----------



On 1/16/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
>
> >The method I described ...blah blah blah.... superposition applies =
> again.
>
> Here is a new problem for you, those return signals has a negative =
> feedback effect on the driver itself. The higher the coupling, the =
> slower the edge rate the less noise gets in. This is another reason why =
> SSO noise doesn't blows up beside the spatial degradation of noise. =
> Without the negative feedback on the driver, your superposition will =
> blow up if there is sufficient aggressor and the spatial coupling does =
> not drop off fast enough. In reality that doesn't happen.
> This is something those IBIS 4.1 guys picked up when they realise they =
> need to account for pre-driver feedback. Something I have published on =
> papers since the early 90's and the IBM people knew since the 70's.
> How does your superposition works in the presence of negative feedback ?
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of agathon
> Sent: Monday, January 15, 2007 11:10 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
>
>
> Chris,
> "How will your superposition work if the aggressors are asynchronous to =
> each
> other ?"
>
> A: So make 'em asynchronous.  They won't mind a bit (er, a UI).  How you =
> use
> the xtalk info is up to you.  I know some ways from practice (heh heh).  =
> The
> superposition works, period.  How will YOUR simulations work if the
> aggressors are asynchronous?
>
> "How will your superposition work if the crosstalk is never saturated =
> inside
> the package and the switching current is depending on the external =
> loading
> that the package designer has no priori knowledge ?"
>
> A:
> Saturation?  I guess this means the backward capacitive xtalk is max'd  =
> out
> for the entire bit period or other window of concern, yes?  Again, how =
> will
> YOURS work?  No a priori knowledge?  Well, game over then.  Just do a =
> wild
> ass guess (WAG) and be done wid it.
> Actually... apply some std loading as a reference.  The "std" usually
> defines a bunch of those, anyway.
>
> The method I described doesn't "care".  It uses 1 UI pulse; you apply =
> the
> brain's frontal lobe to do the rest.  Ie:  change occurrence (UI =
> boundaries
> or not) of the multiple aggressors' xtalk as you wish; they were the =
> victims
> in 1st pass.  Next, you add their xtalk directly to the single victim's
> response, w/o any xtalk environment (which effect was already found); it =
> was
> the aggressor from the 1st sim.  This is a "peak distortion" procedure.  =
> You
> will find the unsaturated boundaries prit' near quick, I reckon.   The
> duration involved is pretty small for a pkg.  Then go to pkg+board sims. =
> If
> I understand, superposition applies again.
>
> Moral of the story:   Linear time invariance w/ reciprocity is our =
> friend.
> Remember "Young Frankenstein" the movie?  Frennnnndd!
>
>
> On 1/15/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
> >
> > Because the observation was made on real measurements not a =
> simulation.
> > How will your superposition work if the aggressors are asynchronous to =
> =3D
> > each other ?
> > How will your superposition work if the crosstalk is never saturated =
> =3D
> > inside the package and the switching current is depending on the =3D
> > external loading that the package designer has no priori knowledge ?
> > It goes back to my opinion last week, if your package/PCB is poorly =
> =3D
> > constrained, no amount of simulation will save you.
> >
> > -----Original Message-----
> > From: si-list-bounce@xxxxxxxxxxxxx
> > [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of agathon
> > Sent: Monday, January 15, 2007 1:17 PM
> > To: si-list@xxxxxxxxxxxxx
> > Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> >
> >
> > Hello,
> > Agreed.
> > In addition, to try to contribute to the "overview" or just resolve my
> > misperception, why should the xtalk aggressor/victim selections be as
> > stated:  1 victim, multiple aggressors ?  That assumes, a priori, we =
> can
> > perfectly select aggressors, which is not the case.   A self-evincing =
> =3D
> > method
> > would be the reverse, with superposition:  There are N experiments.  =
> In
> > each, take a net as agressor.  Use a 1 UI pulse.  Record the xtalk of
> > interest in a large neighborhood.  By reciprocity, the sum is the =
> xtalk =3D
> > that
> > will appear on that net as victim (in the original arrangement).  And =
> =3D
> > ...
> > viola ... you've found the return path effects automatically.    Uh... =
> =3D
> > isn't
> > this the way it's done by all, or just me?
> >
> > Regards,
> > Agathon
> >
> >
> > On 1/12/07, Henry J. Campbell <hankcampbell@xxxxxxxx> wrote:
> > >
> > > This is one of those examples where we learn a lot more from an =3D
> > overview
> > > explanation than we would have even from a direct answer to a =
> specific
> > > question.
> > > Great job!   HJC
> > >
> > > At 11:08 AM 1/12/2007, you wrote:
> > > >Ray,
> > > >I wish crosstalk in packages is as simple as flagging the neighbor =
> =3D
> > =3D3D
> > > >traces.
> > > >Unlike most of the PCB boards, large BGA packages tends to use a =
> lot =3D
> > of =3D3D
> > > >blind and buried vias. Power and ground planes are highly meshed =
> and =3D
> > =3D3D
> > > >with evil degassing holes. A lot of times I found the crosstalk =
> does =3D
> > not
> > > =3D3D
> > > >come from the traces to traces coupling but rather from the current =
> =3D
> > =3D3D
> > > >return path overlapping each other on the reference planes.=3D3D20
> > > >A while ago there was a thread about someone challenging the need =
> for =3D
> > =3D3D
> > > >ground via drills for return vias. I have used an example in =
> package =3D
> > =3D3D
> > > >crosstalk and I will use the same here. Every time a group of slow =
> =3D
> > speed
> > > =3D3D
> > > >nets hundreds of mils aways switch, the victim line take a huge =3D
> > glitch. =3D3D
> > > >If you purely use the seperating distance to estimate the =
> crosstalk, =3D
> > the
> > > =3D3D
> > > >amplitude will be near zero. What really happen was there was =3D3D
> > > >insufficient return vias on the reference plane for those slow =
> speed =3D
> > =3D3D
> > > >signal and the return current decided to take the nearest vias =
> which =3D
> > is =3D3D
> > > >right next to the critical victim lines.=3D3D20
> > > >I believe that's exactly why Al Ruehli and friends developed PEEC =
> to =3D
> > =3D3D
> > > >estimate those crosstalk for TCM modules back in the 70's. Because =
> =3D
> > they =3D3D
> > > >realize the return path is just as critical as the signal traces =
> =3D3D
> > > >themselves in a highly meshed substrate. Things just don't change =
> =3D
> > that =3D3D
> > > >much since then, electrons move the same then and now, =3D
> > unfortunately.=3D3D20
> > > >
> > > >-----Original Message-----
> > > >From: si-list-bounce@xxxxxxxxxxxxx
> > > >[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Ray Anderson
> > > >Sent: Friday, January 12, 2007 10:08 AM
> > > >To: si-list
> > > >Cc: james.f.peterson@xxxxxxxxxxxxx; scott@xxxxxxxxxxxxx;
> > > >jmartinson@xxxxxxxxxxxxxxxxx; Ray Anderson
> > > >Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> > > >
> > > >
> > > >Jerry-
> > > >
> > > >I can't speak how other silicon vendors provide the data, but we =
> =3D
> > perform
> > > >a full package extraction on all of our package designs to generate =
> =3D
> > RLC
> > > >data for nets operating below about 1GHz (for MGT nets we provide
> > > >s-parameter data). We typically generate mutual coupling data for =
> the =3D
> > 4
> > > >nearest neighbors since we feel that crosstalk coupling from lines =
> =3D
> > more
> > > >than 4 away from the victim contribute negligible crosstalk. The L =
> =3D
> > and C
> > > >mutual coupling values are available in IBIS .pkg file format as a =
> =3D
> > data
> > > >item we make available for each package type. Given that data you =
> can
> > > >simulate or calculate crosstalk voltages.
> > > >
> > > >Besides the standard IBIS .pkg file format we can also provide =3D
> > customers
> > > >the data in a number of other formats upon request (with > 4 =3D
> > neighbors
> > > >coupling if desired).
> > > >
> > > >-Ray
> > > >
> > > >
> > > >Raymond Anderson
> > > >Senior Signal Integrity Staff Engineer
> > > >Advanced Platforms Group
> > > >Advanced Products Division
> > > >Product Technology Department
> > > >Package Design Engineering
> > > >Xilinx Inc.
> > > >2100 Logic Drive
> > > >San Jose, California  95124
> > > >(408) 626-6277
> > > >=3D3D3D20
> > > >
> > > >
> > > >------------------------------------------------------------------
> > > >To unsubscribe from si-list:
> > > >si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject =
> field
> > > >
> > > >or to administer your membership from a web page, go to:
> > > >http://www.freelists.org/webpage/si-list
> > > >
> > > >For help:
> > > >si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> > > >
> > > >List FAQ wiki page is located at:
> > > >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> > > >
> > > >List technical documents are available at:
> > > >                 http://www.si-list.org
> > > >
> > > >List archives are viewable at:
> > > >                 http://www.freelists.org/archives/si-list
> > > >or at our remote archives:
> > > >                 http://groups.yahoo.com/group/si-list/messages
> > > >Old (prior to June 6, 2001) list archives are viewable at:
> > > >                 http://www.qsl.net/wb6tpu
> > > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from si-list:
> > > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject =
> field
> > >
> > > or to administer your membership from a web page, go to:
> > > http://www.freelists.org/webpage/si-list
> > >
> > > For help:
> > > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> > >
> > > List FAQ wiki page is located at:
> > >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> > >
> > > List technical documents are available at:
> > >                 http://www.si-list.org
> > >
> > > List archives are viewable at:
> > >                 http://www.freelists.org/archives/si-list
> > > or at our remote archives:
> > >                 http://groups.yahoo.com/group/si-list/messages
> > > Old (prior to June 6, 2001) list archives are viewable at:
> > >                 http://www.qsl.net/wb6tpu
> > >
> > >
> > >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >
> > or to administer your membership from a web page, go to:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> > List FAQ wiki page is located at:
> >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> > List technical documents are available at:
> >                 http://www.si-list.org
> >
> > List archives are viewable at:    =3D20
> >                 http://www.freelists.org/archives/si-list
> > or at our remote archives:
> >                 http://groups.yahoo.com/group/si-list/messages
> > Old (prior to June 6, 2001) list archives are viewable at:
> >                 http://www.qsl.net/wb6tpu
> > =3D20
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >
> > or to administer your membership from a web page, go to:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> > List FAQ wiki page is located at:
> >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> > List technical documents are available at:
> >                 http://www.si-list.org
> >
> > List archives are viewable at:
> >                 http://www.freelists.org/archives/si-list
> > or at our remote archives:
> >                 http://groups.yahoo.com/group/si-list/messages
> > Old (prior to June 6, 2001) list archives are viewable at:
> >                 http://www.qsl.net/wb6tpu
> >
> >
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
>                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
>                 http://www.si-list.org
>
> List archives are viewable at:    =20
>                 http://www.freelists.org/archives/si-list
> or at our remote archives:
>                 http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
>                 http://www.qsl.net/wb6tpu
> =20
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
>                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
>                 http://www.si-list.org
>
> List archives are viewable at:
>                 http://www.freelists.org/archives/si-list
> or at our remote archives:
>                 http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
>                 http://www.qsl.net/wb6tpu
>
>
>


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: