[SI-LIST] Re: Article discussion on bad packages - core
- From: steve weir <weirsp@xxxxxxxxxx>
- To: hmurray@xxxxxxxxxxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Wed, 05 Jan 2005 03:07:31 -0800
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
Other related posts:
