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

  • From: agathon <hreidmarkailen@xxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Mon, 15 Jan 2007 23:10:19 -0800

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 =
> each other ?
> 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 ?
> It goes back to my opinion last week, if your package/PCB is poorly =
> 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 =
> 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 =
> that
> will appear on that net as victim (in the original arrangement).  And =
> ...
> viola ... you've found the return path effects automatically.    Uh... =
> 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 =
> 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
> > >traces.
> > >Unlike most of the PCB boards, large BGA packages tends to use a lot =
> of =3D
> > >blind and buried vias. Power and ground planes are highly meshed and =
> =3D
> > >with evil degassing holes. A lot of times I found the crosstalk does =
> not
> > =3D
> > >come from the traces to traces coupling but rather from the current =
> =3D
> > >return path overlapping each other on the reference planes.=3D20
> > >A while ago there was a thread about someone challenging the need for =
> =3D
> > >ground via drills for return vias. I have used an example in package =
> =3D
> > >crosstalk and I will use the same here. Every time a group of slow =
> speed
> > =3D
> > >nets hundreds of mils aways switch, the victim line take a huge =
> glitch. =3D
> > >If you purely use the seperating distance to estimate the crosstalk, =
> the
> > =3D
> > >amplitude will be near zero. What really happen was there was =3D
> > >insufficient return vias on the reference plane for those slow speed =
> =3D
> > >signal and the return current decided to take the nearest vias which =
> is =3D
> > >right next to the critical victim lines.=3D20
> > >I believe that's exactly why Al Ruehli and friends developed PEEC to =
> =3D
> > >estimate those crosstalk for TCM modules back in the 70's. Because =
> they =3D
> > >realize the return path is just as critical as the signal traces =3D
> > >themselves in a highly meshed substrate. Things just don't change =
> that =3D
> > >much since then, electrons move the same then and now, =
> unfortunately.=3D20
> > >
> > >-----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 =
> perform
> > >a full package extraction on all of our package designs to generate =
> RLC
> > >data for nets operating below about 1GHz (for MGT nets we provide
> > >s-parameter data). We typically generate mutual coupling data for the =
> 4
> > >nearest neighbors since we feel that crosstalk coupling from lines =
> more
> > >than 4 away from the victim contribute negligible crosstalk. The L =
> and C
> > >mutual coupling values are available in IBIS .pkg file format as a =
> 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 =
> customers
> > >the data in a number of other formats upon request (with > 4 =
> 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
> > >=3D3D20
> > >
> > >
> > >------------------------------------------------------------------
> > >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:
> > >//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:
> > >                 //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:
> > //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:
> >                 //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:
> //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
>                 //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:
> //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:
>                 //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:
//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:     
                //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: