FreeLists / si-list / [SI-LIST] Re: Article discussion on bad packages - core

["Straty Argyrakis (straty)" <straty@xxxxxxxxx>]

Chris,

The lack of on-die cap is an insidious problem effecting Core, I/O and =
PLL.
All need to be modeled and managed with care. In the case of I/O, the
pre-drivers often exhibit shoot through currents which must be managed
independent of the output drivers. The gigantic N pull-down you describe
will require hefty predrivers, I suspect the gate of the device has a =
hefty
capacitance associated with it hence a large di/dt, this is where decap =
may
be needed in VDD. Running the drivers in Hspice will reveal the shoot
through currents, combining this with a pad ring power model will reveal =
the
amount of on-die cap required and give you the budget for the remaining =
full
path model; package decap, package power distribution, board power
distribution and board decap. We always create a full path model from =
die
driver/flop cell to the power supply and establish a budget for ALL the
components. We always start with the die model as this is the key =
component
in the system from which all other budgets are set. By including the =
power
supply response in the model, you can also specify low frequency decap =
on
the PCB and know with certainty whether the "Sea of Capacitors" is =
really
necessary or do you need and Ocean.=20


Regards,
Straty



-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On
Behalf Of Chris Cheng
Sent: Wednesday, January 05, 2005 6:30 PM
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Article discussion on bad packages - core


Straty,
Yah, those Merced and McKinley people are really cool, it has always =
been my
dream to work with them. Oh well.... While conceptually your description =
of
their analysis is almost correct. I have to disagree on the I/O =
decoupling
side. The on die decoupling effect on SSO noise can have critical, =
limited
or none depending on the type of I/O deployed. In the case for =
Deschutes,
Merced and McKinley, they have limited use.=20
While Bill Gunning or me will both disagree on naming the above =
processors
FSB as GTL, they do exhibit so call open drain driver characteristics.
Namely the main switching is a gigantic N pull down that will draw the
signal current from an external pull up (at VTT) and return it through
ground. So my question to you is, what exactly can you decouple on die =
for
the I/O ? This is particular true on the original GTL driver Bill and my =
SUN
team worked on (which is a well published circuit. Hey IBIS guys, try
modeling SSO with that.) In our FSB implementation in Merced and =
McKinley
cases, things are a little different as the cartridge pin out clearly =
calls
out VTT power pins, but you should also notice there is little power
associated with it. What we did inside is something I won't dig in. =
Needless
to say, there is little need for significant decoupling for VTT on die. =
That
said, the situation may be a little different for a classical push pull
driver you see in your every day SSTL for DDR or DDR2 etc. Here, there =
may
be actual AC and DC current load between the I/O power and ground. =
However,
most of the drivers are in mA switching range and the swing is <1V for
really highspeed signal. Here, I think the real issue with on die IO
decoupling is it is critical for it as an image current return, Scott
sometimes call modal conversion. Remember I always preach that IO SSO =
noise
suppression on die and PCB is really an issue of image return management =
?
Well for GTL it is easy, everything returns through the ground reference
plane. But for push/pull drivers, you have to paths for return (power =
and
ground) and most of the time you don't have the luxury of strictly
referencing the signal trace with both I/O power and ground in all =
packages
and PCB. So one will usually be forced to at least reference it to a =
proper
ground in which the image current will return through and then use the =
on
die decoupling to return those pull up current to the I/O power through =
the
on die decoupling.
 =20

-----Original Message-----
From: Straty Argyrakis (straty) [mailto:straty@xxxxxxxxx]
Sent: Wednesday, January 05, 2005 5:06 PM
To: Larry.Smith@xxxxxxx; twesterh@xxxxxxxxx
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Article discussion on bad packages - core



Larry,

Your response in this thread has been most refreshing. Beware the fate =
=3D of
Bruce Lee for giving away the secrets of the trade....  Your comments on =
=3D
the importance of On-Die cap, in my opinion, addresses the fundamental =
=3D
problem and one we have been struggling with for a long time. I was
surprised =3D the EETimes article never mentioned any relationship to =
Die
contribution, =3D only the package contribution.=3D20

The On-Die cap for both Core and I/O set the noise budget for the entire
system power path model. If the noise is not addressed at this level, =
=3D
there is a strong possibility that there is no solution on package or on =
=3D
board. Intel, back in the 1997 time frame with the advent of Deschutes
(first =3D Intel C4 chip), Merced and McKinley chips, understood the
implications of insufficient Die-Cap and it's impact (no post fab =
repair)
and a huge =3D task force was assembled to optimize On-Die Cap =
structures. The
reality is =3D there is a war between the Power / Signal Integrity =
designers
and the chip designers for die real estate, it comes down to a choice
between =3D features and Power noise. If you put die cap in where it is
needed, it chews up =3D real estate, flooding the die in unused areas =
(which
is what is generally the
practice) may not address the problem if the die metal grid is not =3D
carefully designed. The die cap has to be in physical proximity to the =
I/O
or core flops as the die metal inductance can be too high for it to do =
any
good. Further complicating the problem is the type of capacitor you fab =
on
the
die: you run into yield problems if there is cap leakage. To address the
leakage problem, caps with series limiting structures are used, however =
=3D
this limits the effect they have. When migrating from .18, .13, to 90nm =
fab
processes, we experienced this problem gets compounded: VDD goes down
(resulting in a lower allowable noise voltage), IDD goes up, and the cap
leakage is requiring series limiting components which degrade the =3D
effective C, so it is not a linear problem. Other solutions to solving =
the
power transient problems are core logic sequencing or ramping, however =
the
benefits cannot be quantified without an accurate full path model.   =
=3D20


My co-workers, Arthur Fraser and Paul Mantiply and myself, have been =3D
working on these issues for about 7 years and we have had great success
breaking =3D the full path model down into it's fundamental components =
and
modeling them. Validating our models in the lab with measurements (like
measuring =3D on-die cap with VNA as you indicated) increases our model
accuracy. After =3D modeling the subcomponents, including on-Die power
distribution, we generate a =3D full path model from the components to =
achieve
solutions in a reasonable time frame. The full path model then reveals =
the
system level power noise =3D budget. We generate ground rules for the =
chip,
package, and board level =3D decoupling capacitance and are able to =
predict
the noise impact of compromising the guidelines. We have achieved good
correlation in the lab between our =3D pre-fab simulations and post-fab
measurements with this methodology. We have not =3D had success with =
importing
entire package designs into a tool to perform =3D power modeling (the =
loss of
flexibility when attempting such a solution =3D preempts any attempt to =
fully
understand the fundamental pieces).

Regards,
Straty

Straty Argyrakis
Acting Integrity Manager
CPP Engineering
Cisco Systems Inc.
170 West Tasman Ave.
San Jose, Ca 95134

Office:408 527-8712
Cell  :408-691-7744=3D20





-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
=3D
On Behalf Of Larry SMITH
Sent: Tuesday, January 04, 2005 11:38 AM
To: twesterh@xxxxxxxxx
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Article discussion on bad packages - core


Todd - Your comments are right on target!  I've been sorting through all =
=3D
my email after a nice long break and there has been a lot of energy on =
this
thread.  One of the confusion factors is that we are getting SSN and I/O
return current mixed up with core power transients (VDD/Gnd). These are =
=3D
two very different PI topics and need to be considered in very different =
 =3D
ways. I want to make some further remarks to your comments on the core =
PDS.
=3D As you have implied, the correct approach is to examine the =
individual
components (chip, package, PCB) and combine them into a power =3D =
distribution
system.

1) On-die decoupling capacitance is very important because it is the =3D =
only
charge reservoir that is going to supply current above approximately =3D
100MHz to a system that has a target impedance of approximately 1 mOhm.
1.59pH =3D is 1 mOhm at 100MHz and it is nearly impossible reduce the =
package
=3D inductance to that realm.  The chip must be self sufficient above =
some
frequency, approximately 100 MHz. Our recent micro processors have had
on-chip decoupling capacitance on the order of 500nF, which is 3.18mOhms =
at
100 =3D MHz, so we have chosen the dividing line at about the right =
frequency.

The best way to find the on-chip capacitance is to measure it.  I have =
=3D not
seen a software tool yet that can correctly predict the whole chip
capacitance.  Measure the capacitance of a bare PCB using a VNA and then
attach the chip and remeasure.  The capacitance of the chip is the
difference between the two measurements.  Be sure and bias the chip at =
=3D the
proper voltage.  In my experience, the capacitance of the chip goes up =
=3D
about 3X with bias because of all the FET channels are formed by gate =
bias.
=3D The chip comes up in a completely unknown state but I don't believe =
the
chip capacitance is a strong state function.  The gates that are not =3D
switching form capacitance for those that are.

The on-chip capacitance forms a parallel LC circuit with the package
inductance and PCB impedance and makes a PDS peak that I call =3D =
chip/package
resonance.  It is the most difficult impedance peak in the PDS.  I have =
=3D
not seen a system yet that meets target impedance in this frequency =
band, =3D
but they seem to keep working anyway, probably because the circuits can =
=3D
tolerate more voltage drop than we thought.

2) On-package capacitance can help this situation, but the challenge is =
=3D to
hook it up with conductors that are less than the target impedance. Very
Difficult!  One strategy is to take the core power solder bumps straight
down to the PCB pins with package vias.  In this case, on-package
capacitance must be off to the side.  It is very difficult to mount
capacitors on the package and channel their current into the core power
solder bumps with 1 mOhm or less of series impedance at 100 MHz. Package
power planes suffer from the same spreading inductance and perforation
degradation as PCB power planes.

Another strategy is to place the on-package capacitors directly =3D =
underneath
the chip core and connect them with 100's of package vias. This makes =
=3D the
on-package capacitors effective but now you have to bring in ~100 amps =
=3D of
DC current on package power planes that are probably perforated.  Hmmm.  =
=3D
There is really no good way to do it and this may be the very motivation =
=3D
behind the EE Times article and the subject of this thread.

The decisions made by the package designer pretty much determine the =3D
quality of the PDS that the circuits on the chip see as they look for =
gobs
of current at low impedance.  It is certainly possible to make a mistake
on-chip or on-pcb, but the electronic package is probably the most =3D
critical part of the core PDS design.  To a great extent, the pin pitch =
of
the package influences the spreading inductance of the perforated PCB =
power
planes that bring power to the core power pins.  If the core power pins =
=3D
are surrounded by many rows of I/O pins on 1 millimeter pitch, there =
will be
precious little copper left between the PCB antipads to channel the =3D
current. High resistance and high inductance!  If there are 1000's of =
I/O,
the =3D PCB will have to be thick to escape all the signals, which =
drives up
the via =3D and antipad size, further compounding the problem.  This is =
just
another =3D example of decisions made by the package designer affecting =
the
PDS quality of =3D the system by forcing constraints on the PCB power =
planes.
The package =3D design can truly make or break the system design.

3) Your question (proposal) pertains to documenting a chip's high speed
power requirements.  Let's further clarify it to be a "packaged chip"
because a corner frequency has already been set by the chip/package =3D
resonant frequency.  The PCB designer is responsible for keeping the PDS =
=3D
impedance below the target up to the corner frequency that is =
established by
chip/package resonance.  The "breakout" portion of the PCB should be
considered to be part of the package because it's design dimesions have =
=3D
been set by the package.  The impedance of the broad PCB should be =
resistive
rather than inductive at the chip/package resonant frequency because =3D =
that
lowers the Q of the resonant circuit (inductance raises the Q).

The most crucial piece of information from the chip manufacturer is the
maximum and minimum currents that can be drawn from the PCB PDS.  This
establishes the dI or transient current that the PCB must supply.  The =
=3D
rise time (dt) is determined by the low pass filter associated with the
chip/package resonant frequency.  Generally, customer code will =3D =
determine
the current waveform and therefor the frequency profile of the current =
=3D
drawn by the chip, so I don't believe it is fair to ask chip vendors for =
the
=3D power spectrum.  However, they should be obligated to give their =
customers
the maximum and minimum current that their chip will ever draw.  The =
minium
=3D I is probably determined by sleep mode and power saving states.

There is a move a foot to standardize the tools and methods used for =3D =
power
integrity.  This is a very worthwhile endeavor.  But it is a huge =3D =
problem
and must be broken down into solvable parts.  This note pertains to core
power and transient current on Vdd and Gnd.  The SSN and return current =
=3D PI
problem is entirely different.  It will help if we divide these two =3D
problems and conquer them individually.

regards,
Larry Smith
Sun Microsystems

Todd Westerhoff (twesterh) wrote:
> Happy New Year to all!
>=3D20
> Having gone through the collection of messages to this point, I have a =

>=3D

> few questions I'd like to raise:
>=3D20
> 1) How are people accounting for the effects of on-die decoupling=20
>in=3D20  their analyses?  We can analyze the power delivery capbilities =

>of the=3D20  package, but part of the power delivery system is=20
>implemented by=3D20  on-die decoupling, isn't it?  How do folks go =
about=20
>extracting die=3D20  parasitics and incorporating them into their PDS=20
>analyses? =3D20
> 2) It seems to me that the combination of on-die and [optionally]=3D20 =
=20
>on-package decoupling makes the package/die PDS self-sufficient=20
>above=3D20  some frequency. If we look at the board PDS, the target PDS =

>impedance=3D20  requirements would therefore increase with frequency. =20
>The rolloff (or =3D

> rollup, if you prefer) of target impedance with frequency would =
be=3D20 =20
>design-specific, and, I believe, complex to determine, but would=3D20 =20
>nonetheless serve as a design requirement for the board's PDS at=20
>that=3D20  point. =3D20
> My question here - does anyone else think this would be a possible and =
=3D

> reasonable method for documenting a chip's high speed current=3D20=20
> requirements? I suggest we leave FPGAs out for the moment, since their =

> =3D

> requirements will be design specific.  Could we document PDS=3D20 =20
>impedance/frequency profiles for standard components, and use that=3D20 =
=20
>information to segregate some of the high speed signaling and PDS=3D20  =

>design tasks? =3D20
> Comments are welcome and appreciated.
>=3D20
> Todd.
>=3D20
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@xxxxxxxxx
> ph: 978-936-2149
> =3D
=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D
=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D
>=3D20
> "Always do right.
>  This will gratify some people and astonish the rest."
>=3D20
> - Mark Twain
>=3D20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field=20
>=3D20  or to administer your membership from a web page, go to:=3D20
> http://www.freelists.org/webpage/si-list
>=3D20
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>=3D20
> List FAQ wiki page is located at:
>                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>=3D20
> List technical documents are available at:
>                 http://www.si-list.org
>=3D20
> 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
>=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:    =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:    =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:    =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