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