[SI-LIST] Re: Article discussion on bad packages - core
- From: steve weir <weirsp@xxxxxxxxxx>
- To: zhangkun 29902 <zhang_kun@xxxxxxxxxx>
- Date: Wed, 05 Jan 2005 07:10:27 -0800
Zhangkun, internal power consumption can be satisfied with a LPF with
sufficiently low impedance within the package. So we can decouple the die
from the board and still readily succeed. However, with SSO, the signals
and their returns are duals, they both must penetrate the package
together. At very high speeds, a well-defined transmission line is needed
between the signal and its return. A lumped inductance of which a wire
bond attachment provides a gross example, will not support GHz. I/O.
Regards,
Steve.
At 10:28 PM 1/5/2005 +0800, zhangkun 29902 wrote:
>Steve:
>
>I agree with you according to my experience. In some product in my
>company, I measured the CORE power ground noise by spectrum analyzer.
>There is some great power consuming for several MHz to dozens of MHz. This
>kind of power ground noise give rise to system failure. The solvment is to
>add a lot of discrete decoupling capacitor, which is very simple:)
>
>If there is any problem with IO power, it is very difficult to solve them.
>There is also critical SSN problem.
>
>Larry:
>
>Why do you seperate the SSN and PI problem? I think they should be
>considered together.
>
>Best Regards
>
>Zhangkun
>2005.1.5
>
>----- Original Message -----
>From: steve weir <weirsp@xxxxxxxxxx>
>Date: Wednesday, January 5, 2005 7:07 pm
>Subject: [SI-LIST] Re: Article discussion on bad packages - core
>
> > Hal, I have generally found that the FPGA core power is not a
> > serious
> > challenge. In general ( beware generalizations! ) I have found
> > the I/O
> > rails tend to suffer much more percentage bounce and need much
> > more care
> > and attention than the core, even though the core is lower
> > voltage. There
> > are a number of reasons for this: fewer attachments, little in-
> > package /
> > on-die capacitance for I/O, sparse ground chevron, tendency to cut-
> > up I/O
> > power planes, etc, etc. The single most important design issue in
> > my mind
> > is planning I/Os to contain the peak value of simultaneous
> > switching di/dt
> > within the package capabilities.
> >
> > For your toolbox code, you might consider using the clock
> > multiplexers
> > available for several years now.
> >
> > For I/O rather than build a special test load, I suggest including
> > a
> > multiplexor to all output IOBs that has as its second input a
> > simple
> > pattern generator as part of the production design. Attaching the
> > mux
> > control to a scan chain, or host register makes probing with
> > otherwise
> > realistic conditions much easier, and avoids code maintenance
> > headaches. You can stay as simple or get as fancy as you like
> > with this
> > technique without consuming much area, or imposing much timing
> > penalty.
> > I don't have a good answer for CPU code.
> >
> > Steve.
> >
> > At 01:55 AM 1/5/2005 -0800, Hal Murray wrote:
> >
> > > > 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 rise time (dt) is determined by the low pass
> > filter associated
> > > > with the chip/package resonant frequency. Generally, customer
> > code> > will determine the current waveform and therefor the
> > frequency profile
> > > > of the current drawn by the chip, so I don't believe it is
> > fair to ask
> > > > chip vendors for the power spectrum. However, they should be
> > > > obligated to give their customers the maximum and minimum
> > current that
> > > > their chip will ever draw. The minium I is probably
> > determined by
> > > > sleep mode and power saving states.
> > >
> > >Is is possible to give useful numbers for min/max currents on
> > modern chips?
> > >
> > >Consider a CPU: What code is it running?
> > >
> > >Consider a FPGA: A nasty design can use many times the normal
> > peak current
> > >for a short burst without cooking itself. (Adjust duty cycle to keep
> > >temperature reasonable.)
> > >
> > >I occasionally scheme about writing some code that would try to
> > go from min
> > >to max power usage and adjust the timing to see if I can provoke
> > troubles in
> > >the PDS. Or something else will break. This seems like a
> > generally nasty
> > >sort of code to have in your toolbox.
> > >
> > >I'm thinking of something like keep all memories active for N
> > cycles, then do
> > >nothing for N cycles. Repeat for a while, then try the next N.
> > Finding the
> > >really nasty cases would probably take help from one of the
> > chip/system>designers/architects. How do you keep all the ALUs
> > and memories busy?
> > >
> > >Maybe the leakage through thin oxides will save us by making the
> > min current
> > >large enough so that the ratio of min:max is reasonable. :)
> > >
> > >Worst case might be coming out of reset.
> > >
> > >
> > >
> > >
> > >--
> > >The suespammers.org mail server is located in California. So are
> > all my
> > >other mailboxes. Please do not send unsolicited bulk e-mail or
> > unsolicited>commercial e-mail to my suespammers.org address or any
> > of my other addresses.
> > >These are my opinions, not necessarily my employer's. I hate spam.
> > >
> > >
> > >
> > >------------------------------------------------------------------
> > >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
Other related posts:
