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

Sorry for the delay in replying.
"Afterall, if you truly have done what you said and measured against what
you simulate, you would have picked it up very quickly."
It's bad to just assume.  What makes you think I'm even interested in SSN
deep quicksand?  Siwwy wabbit.

"In step 2, your return coupling sum will be excessive without negative
feedback."
In step 2 I measure V xtalk on N aggressors; what is "return" here?
Actually, you did find on of the duly placed defects.  Clever fellow.

"So you now have to re-sum your coupling again in 2), do 3) again, so on and
so forth."
I don't see how this fixes the problem.

Lesson 3 commences to solve the defect ...

Obviously, step 2 stim can be derated by step 1 results, by breaking into N
sims instead of 1, and instead of using it in step 3 as I originally have
it.  Each of the N is derated by each corresp. sim in step 1.
Also, it's obvious the stim in 1 and measurements in 2 must be consistent
regarding "0" or "1".
Further, this assumes linearity in the x driver slew rate effect.  This is
easily true for the weak couplers.  Separate linear function deratings on
x's edge rate can be done for sets of aggressors, then combined where
necessary.

Shame on you.  Now you really must pay.  I insist.  :-)
PS:  There is one last defect, though of minimal impact I believe.  Can you
find it?  Hint:  step 1 & accuracy of return current.  Or, a chicken & egg
dilemma.  Some initial looping of derating each aggressor AND x may be
needed to converge on V waveforms for both.
Higher order effects (multiple aggressors) at this stage are ignored.

"BTW, nothing you mentioned below is new or innovative."
I am so glad to be so informed.  I was a little worried, if you look back to
my original email.  Yes, grasshopper, nothing is new under the Sun.  Such
has been written before.

"As we dig deeper and deeper, it is clear to me you just talked about your
ideas and have never actually done it yourself."
We?  You and what army?  Keep digging.  Yet, this may be true.  But
irrelevant.  I believe my solution, by thought process alone, is potentially
worth more than the efforts of 50 wanderers digging in the desert.  Maybe
not.  I fully accept the possible existence of any number of unrealized
obstacles to making my solution a cost saver in the end.   I give you leave
to try my method.
Again, if it works I insist you pay up.  ;->>

As we can see (there's that "we" again), I've dug a little deeper in that
hole and found that you haven't used the correct shovel.
Further, here's a tidbit you may have overlooked, hopefully what ibis
authors you mentioned are working on - already perhaps doable with
Verilog-AMS since IBIS is inherently inextensible, requiring more hacks &
special sections than some CAD pgms have switches & menus:
Method to characterize ibis driver for N aggressors' return currents, as
described above.  Ie: Have N sections with curves of return or xtalk current
vs. delta-slew-rate.  Then model could be used in a smaller set of sims
using single-driver (the virtual victim).  The sims would emulate the
presence of N aggressors.  Recap: The "single driver" is the victim line in
the present method.  Reciprocity is used to emulate N aggressors.  This
should be the further natural goal of behavioral models:  express the impact
of multiple components in a system, not just replace each instance.

Regards,
Agathon


On 1/18/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
>
> Not quite.
> In step 2, your return coupling sum will be excessive without negative
> feedback.
> When you go to step 3, your excessive return coupling will results in too
> much feedback correction and your individual victim/aggressor will have
> worst than expected edge rate degradation i.e. too little coupling to the
> others. So you now have to re-sum your coupling again in 2), do 3) again, so
> on and so forth.
> I don't believe this will be fundamentally diverging. But on a strong
> coupling case you may have to loop quite a few more times.
> BTW, nothing you mentioned below is new or innovative. Credit it to the
> late Larry Rubin (now that's a true Master) of Quad Design fame who first
> have this discussion with me way back in early 90's when he tried to move
> from TLC to XTK and do SSO at the same time. I pointed out the problem then
> and I will point out the problem now.
> The point is not whether you can eventually work the problem out, it is at
> the beginning when you yap about how trivia the problem is and people should
> pay you for the obviously simple minded methodology that now you have to
> correct over and over again. As we dig deeper and deeper, it is clear to me
> you just talked about your ideas and have never actually done it yourself.
> Afterall, if you truly have done what you said and measured against what you
> simulate, you would have picked it up very quickly.
> ________________________________
>
> From: si-list-bounce@xxxxxxxxxxxxx on behalf of agathon
> Sent: Wed 1/17/2007 2:19 AM
> To: si-list@xxxxxxxxxxxxx
> Subject: [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
>
>
>
>
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
>                 http://www.si-list.net
>
> 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 technical documents are available at:
                http://www.si-list.net

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: