[SI-LIST] Re: Referencing multiple voltages in a stackup

  • From: Chris Padilla <cpad@xxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Fri, 22 Oct 2004 08:37:47 -0700

Thanks, Scott, for the tome.  Writing a book at all? :)  Personally, I 
think the use of the word "mode" is becoming all too ubiquitous and losing 
its meaning but I follow nonetheless.  How about: form, style, manner, 
method, means, approach, type, sort, way, kind, genre, or fashion. 
;)  Yeah, I just typed 'mode' into MS-Word and hit Shift+F7....

I appreciate the eye-opener...it'll be my coffee for a Friday.... :)

----->Chris
EMC Engineer
Cisco Systems
San Jose, CA

At 11:02 AM 10/22/2004 -0400, Scott McMorrow wrote:
>Dudes,
>There is a need to expand beyond the view of the "plane" and refocus
>your thinking to power delivery vs. signal transmission.  Everyone wants
>to conflate everything into one term called return current.
>Unfortuntately, this conflation also happens at the text book level,
>further complicating correct understanding.  In fact, two totally
>seperate phenomena occur.
>
>First, for Kirchhoff's Current Law to be satisfied, there has to be an
>AC and a DC path from Vcc to Ground, and it must extend back to the
>regulator.  This path, however does not need too, nor rarely does,
>follow the path of the signal.  If there was no wire attached to the
>output of a driver, this current would still exist.  This is the Power
>Delivery Mode current.
>
>Second, if we attach a wire to the driver, then current is diverted to
>the signal line.  This current division is form of mode converstion into
>Signal Mode.  In this process, most of the driver current is driven
>down(up) the line.  It is in this area that really interesting things
>happen, depending upon whether a signal is ground referenced, vcc driver
>referenced or vcc other referenced.  For example, if the driver is
>switching to a high state (positive logic) and the signal wire is
>referenced to ground, then very little has to happen at the boundary
>between the chip and the package.  Since vcc current at the driver is
>already referenced to ground at the output transistors, and since there
>is usually a ground connection fairly close to the driver bump, there is
>no disruption in the path, and thus a smooth transition in the mode
>converstion process.  (i.e. a significant percentage of the driver
>energy is transferred to the signal wire.)  If the wire were infinitely
>long, then current would continue to travel out away from the package to
>infinity.  This energy is lost to the system and must be replenished by
>the power supply regulator.  Where does this current come from?  It
>comes from between Vcc and ground.  It comes from the power grid of the
>system. This would be the Power Delivery Mode.
>
>The power grid of the system is comprised of the regulator (VRM), power
>delivery traces or planes, decoupling capacitors, package balls, vias
>and bumps, and finally any on-die decoupling.  Fortunately, or
>unfortunately depending on your point of view, the package, it's bumps,
>vias, balls, pads and pcb breakouts, has a fairly low cutoff frequency
>for power delivery purposes. Somewhere between 100 and 500 MHz  not a
>hell of a lot of power supply energy is being passed through the package
>power grid.  Why? Because there's just too much darn inductance.  So, if
>you have a driver that is switching in 150 ns (2.33 GHz) you better hope
>that the transition from die to signal wire is extremely good, and that
>most of the energy has been transferred to the wire.  Otherwise,
>whatever is left rattling around in the package and die must be
>decoupled locally with on-die capacitance that can absorb the impact of
>high frequency transients.  If this is not done properly then noise at
>the die can grow to unacceptable levels.  There is nothing that can be
>done at the PCB level which can resolve this issue, again, because of
>the power/ground pin inductance in the way.
>
>The goal of good silicon and package design is to convert as much of the
>switching energy into a signal mode.  This relegates Kirchhoff to
>recharging the "batteries" for the next switching cycle, which is
>usually a lower frequency event than the switching transient.  This
>lower frequency event occurs whether or not the signal path ever returns
>to the driver.  For example, with an infinite line, energy converted to
>the signal mode travels out and away from the package infinitely, lost
>to the universe.  On the other side, at the receiver, energy received
>from an infinitely long signal mode, needs to be converted back to Power
>Mode by the package and the receiver.  If the receiver is terminated,
>and the package is designed well, then a high percentage of the energy
>is recovered.  Whatever energy is not recovered by the receiver (and
>therefore terminated to Vcc and ground and decoupled by on die
>capacitors) is reflected back out to the universe and is lost.  There is
>reciprocity between package design for drivers and receivers, much like
>there is reciprocity for transmitting and receiving antennas in the RF
>world.
>
>So, we can summarize that there are two modes of current in a device:
>Power Delivery Mode and Signal Mode.  We can further state that the
>package and drivers should be designed to facilitate conversion of
>energy from one mode to as much of the Signal Mode as possible.  The
>function of the driver and the package is to convert as much energy from
>the Power Mode to the Signal Mode, much like an RF amplifier, feedline
>and antenna's job is to convert as much energy from the Power Mode into
>a propagating wave.  An efficient conversion leaves little high
>frequency energy rattling around. The function of the receiver and
>package is to convert as much energy from the Signal Mode back to the
>Power Mode.
>
>So, what about an unterminated receiver.  Oops ... conversion of energy
>is near zero. So what happens?  Most all of the energy is reflected back
>out to the universe.  And for a poorly matched driver?  A significant
>amount of energy reflects back to the driver and needs to be absorbed by
>the silicon Power Mode control devices (i.e. on-die capacitors),
>increasing the amount of noice at the driver.  And what if you combine
>an unterminated receiver with a poorly matched driver?  Well, the energy
>just rattles around and around and around.  In the SI world we look at
>these waveforms every day.  They have overshoot, undershoot, ringing and
>have all sorts of nasty effects.  So we slap on resistors to absorb and
>disipate the energy and keep it from slamming the die.  But, when it
>slams the die there we go again causing energy to be converted from
>Signal Mode back to Power Mode .... yuck!  Who does all the decoupling
>work?  Why the silicon, of course ... until the energy drops below the
>cutoff frequency of the package and is capable of being decoupled by the
>PCB planes and decoupling capacitors.  There it propgates out and away
>from the package in a circular wavefront.
>
>So, you ask the question, "why is there so much high freqency noise
>(>500 MHz)  on my power and ground planes?" Well, my  answer to this is
>"Because you did not ground reference all your high edge rate signals."
>Remember that we've said the purpose of the driver and the package is to
>convert energy from the Power Mode to the Signal Mode and vice versa.
>This allows the energy to be carried by a uniform transmission line.
>But, if the transmission line is not uniform then several things can
>occur.  First, at an impedance discontinuity energy can be reflected
>back.  We're all used to this at an unterminated receiver where all the
>energy is reflected back to the driver.  This causes the driver to be
>responsible for returning the energy back to the Power Mode, and thus
>forcing the driver and it's package to do double duty.  Second, there
>can be a mode discontinuity where a change in propagation mode is
>forced.  Vias are the common example.  At a via transition, Signal Mode
>(stripline or microstrip mode signals) is converted to the Via Mode.  At
>the transition, Via Mode is converted near-simultaneously to another
>Signal Mode on the new trace layer, and to multiple Parallel Plate Modes
>(the dominate mode between power and ground planes.) Parallel Plate Mode
>energy is a predominant amount of the high frequency noise that you see
>on your planes.  This energy will propagate outward in a circular
>wavefront until it is absorbed or reflected back.  Mostly it reflects
>(although Istvan's concept of capacitors terminating to the
>characterisitc impedance of the plane solves the reflection , and
>therefore resonance, issues.)  Unfortunately, at switching frequencies,
>the mounted inductance of a capacitor is such that it is a very poor
>terminator at best.  Which is why it is a very bad idea to switch from a
>ground referenced trace layer to a Vcc referenced trace layer.  Some of
>the energy has to be converted into parallel plate mode and has to
>travel through decoupling capacitors whose mounted inductance are such
>that they do not do a very good job.  Let me repeat, if you transition a
>trace from a ground referenced layer to a Vcc referenced layer through a
>via, you will force noise into your power planes.  But if you transition
>from ground referenced layers to ground referenced layers, the noise
>will be short circuited by ground to ground via connections all around
>the PCB.
>
>To solve this problem is simple.  Don't transition to Vcc referenced
>trace layers.  In order of noise priority it is wise to do the following.
>
>1) Place a ground layer underneath all packages.
>2) Keep trace routing on one ground referenced layer with two vias maximum.
>3) If you have to transition through more than two vias, transition from
>ground referenced to ground referenced layer.
>4) Surround high speed signal transitions (such as clocks) with ground
>vias to contain the energy in the transition.
>5) Place ground stitch vias in all unused board space to form energy
>containment boundaries.
>
>Now it's time to get another cup of coffee.
>
>
>best regards,
>
>scott
>
>
>
>
>Gourari, Alexandre wrote:
>
> >Good point, Jim, and I agree with what Geoff said. The only point I'd like
> >to clarify, probably for myself mostly ;-))
> >Considering single CMOS totem pole driver with decoupling cap large enough
> >to store energy necessary to supply switching current you may want to look
> >at the receiver side now. The load worth considering for switching consists
> >of 2 caps, input-Vss and input-Vcc. Depending on signal transition direction
> >receiver's input current charges one and discharges the other. That effect
> >creates return currents in the both planes at either transition. Obviously
> >the difference in cap values and load side termination affects magnitude of
> >these return currents, but IMHO return current shall be considered for both
> >planes.
> >
> >Best regards,
> >Alex Gourari
> >
> >
> >-----Original Message-----
> >From: Geoff Stokes [mailto:gstokes@xxxxxxxxx]
> >Sent: Friday, October 22, 2004 7:55 AM
> >To: si-list@xxxxxxxxxxxxx)
> >Subject: [SI-LIST] Re: Referencing multiple voltages in a stackup
> >
> >
> >Hi Jim
> >
> >This link was posted here a few days ago.
> >http://www.ewh.ieee.org/r5/denver/rockymountainemc/archive/2004/Sep/Maxwell.
> >pdf
> >I recommend you download it in case it disappears at some point.
> >
> >Page 57 says that for high frequency, ground is a concept that does not
> >exist.  There is a fair amount of discussion to back that view.  The high
> >frequency components of a signal return through various paths, including Vdd
> >plane decoupling caps and 0V plane.  So basically you are right if you add
> >the fact that the (distributed) load current might be dumped either in the
> >0V or Vdd conductors/planes, whereas, as you point out in many cases it must
> >return to the FET drain or source.  Actually the power planes are AC
> >"ground" planes.  They carry currents and develop associated local voltage
> >drops and give rise to system imperfections in terms of pulse shapes and
> >noise immunity at critical devices.  But the important point is that in
> >order for the return current coupling, radiation and susceptibility all to
> >be kept to a minimum, the immediate current-carrying parts of power and 0V
> >planes must be well-stitched together, using vias and decoupling caps.
> >
> >Cheers
> >Geoff
> >
> >
> >
> >>-----Original Message-----
> >>From: Peterson, James F (FL51) [mailto:james.f.peterson@xxxxxxxxxxxxx]
> >>Sent: 22 October 2004 12:23
> >>To: si-list@xxxxxxxxxxxxx
> >>Subject: [SI-LIST] Re: Referencing multiple voltages in a stackup
> >>
> >>
> >>With regards to Chris's comments below:
> >>(paraphrasing : return currents reluctantly using the Vcc
> >>plane until they
> >>can get to a ground plane.) with a typical driver topology
> >>(totem pole), and
> >>the driver switched to a logic "1" state, don't return
> >>currents want to use
> >>this Vcc plane. Don't they need to return to the pullup FET
> >>(Kirchhoff's
> >>current law)? If this is true, it seems the return currents
> >>would want to
> >>hop on the Vccio plane to get back to that FET.....I've
> >>always been curious
> >>about this and have heard different arguments.
> >>thanks,
> >>Jim Peterson
> >>Honeywell
> >>
> >>-----Original Message-----
> >>From: si-list-bounce@xxxxxxxxxxxxx
> >>[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of steve weir
> >>Sent: Thursday, October 21, 2004 6:01 PM
> >>To: chris.mcgrath@xxxxxxxx; si-list@xxxxxxxxxxxxx
> >>Subject: [SI-LIST] Re: Referencing multiple voltages in a stackup
> >>
> >>
> >>Chris,
> >>
> >>You need to be very careful with that proposal.  In a perfect world,
> >>signals return only against the reference ( typically ground
> >>) for the I/O,
> >>and only operate on one side of that reference plane.  It is
> >>not much worse
> >>to operate on both sides of the plane.  The antipad for the
> >>signal via
> >>typically provides the return signal path from one side of
> >>the plane to the
> >>other.
> >>
> >>Substantively worse is the common practice of offset
> >>striplines in a Vcc
> >>Sig Sig Gnd sandwich.  Most of the return current has to work
> >>its way to
> >>nearby decoupling capacitors on the surface and back down to
> >>the opposing
> >>power layer.  This works OK for non-demanding signals, but makes for
> >>resonant cavities that can be vexing.
> >>
> >>Then we get to what I understand as your proposal.  Be
> >>afraid, be very
> >>afraid.  For that proposal to fly, you need to thoroughly
> >>evaluate the
> >>effective inductance between whatever chunk of metal you are
> >>attempting to
> >>use as an image plane and the rest of the return signal path,
> >>and be able
> >>to show that the L*di/dt is not going to first create an EMC
> >>nightmare and
> >>secondly will not create signaling problems.  You could
> >>readily create a
> >>situation where no amount of decoupling will make the board work.
> >>
> >>Steve
> >>At 02:09 PM 10/21/2004 -0700, Chris McGrath wrote:
> >>
> >>
> >>
> >>>I'm putting together a stackup with roughly 20 layers that requires
> >>>distribution of five different voltages and I'm wondering what effect
> >>>running 3.3V logic (133MHz) adjacent to a lower voltage
> >>>
> >>>
> >>reference plane
> >>
> >>
> >>>(such as 1.5V) would have on the lower voltage reference plane. =20
> >>>
> >>>I understand the concept of the power plane operating as a reference
> >>>plane, but with 4 mil cores throughout the board, I am worried about
> >>>coupling switching noise from 3.3V signals into lower
> >>>
> >>>
> >>voltage reference
> >>
> >>
> >>>planes adjacent to the 3.3V signals. =20
> >>>
> >>>As I see it, the conservative approach would be to only route 3.3V
> >>>signals next to the 3.3V plane or next to a ground plane.  However,
> >>>given the rise times involved (~ 1ns), I tend to believe
> >>>
> >>>
> >>that sufficient
> >>
> >>
> >>>decoupling and stitching together of ground planes in the area would
> >>>suppress any noise that could potentially couple into the
> >>>
> >>>
> >>lower voltage
> >>
> >>
> >>>planes.  My understanding is that for the higher speed
> >>>
> >>>
> >>signals (over 1
> >>
> >>
> >>>GHz), it is not wise to route adjacent to any reference other than
> >>>ground and the voltage reference for the GHZ signals.  My question
> >>>mainly revolves around signals running at less than 1 GHz.
> >>>
> >>>I am interested in hearing any opinions you may have on the
> >>>
> >>>
> >>topic.  We
> >>
> >>
> >>>often talk about stackups but I could not find anything in
> >>>
> >>>
> >>the archives
> >>
> >>
> >>>that addressed the issue of stackups with a number of different
> >>>voltages.
> >>>
> >>>Thanks,
> >>>Chris
> >>>
> >>>
> >>>------------------------------------------
> >>>Chris McGrath
> >>>Sr. Hardware Engineer
> >>>ADIC
> >>>ph: (607) 241-4858
> >>>eM: chris.mcgrath@xxxxxxxx
> >>>------------------------------------------
> >>>------------------------------------------------------------------
> >>>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:
> >>              //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
> >>
> >>
> >>
> >>
> >
> >
> >_________________________________________________________
> >
> >Zetex Semiconductors - Solutions for an analog world
> >
> >http://www.zetex.com
> >_________________________________________________________
> >
> >######################################################################
> >E-MAILS are susceptible to interference. You should not assume that
> >the contents originated from the sender or the Zetex Group or that they
> >have been accurately reproduced from their original form.
> >Zetex accepts no responsibility for information, errors or omissions in
> >this e-mail nor for its use or misuse nor for any act committed or
> >omitted in connection with this communication.
> >If in doubt, please verify the authenticity with the sender.
> >######################################################################
> >
> >------------------------------------------------------------------
> >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
> >
> >
> >
> >
>
>--
>Scott McMorrow
>Teraspeed Consulting Group LLC
>121 North River Drive
>Narragansett, RI 02882
>(401) 284-1827 Business
>(401) 284-1840 Fax
>(503) 750-6481 Cellular
>http://www.teraspeed.com
>
>Teraspeed is the registered service mark of
>Teraspeed Consulting Group LLC
>
>
>
>------------------------------------------------------------------
>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: