[SI-LIST] Re: Article discussion on bad packages - core powermeasurments
- From: zhangkun 29902 <zhang_kun@xxxxxxxxxx>
- To: "Grasso, Charles" <Charles.Grasso@xxxxxxxxxxxx>
- Date: Wed, 05 Jan 2005 22:56:17 +0800
Dear Charles
The 50 ohm input impedance of SA would not affect the PDS. Normally, the
impedance of PDS is below 1 ohm, which is little compared with 50ohm. If the
freqeuncy domain is extended above 3GHz, my method is not useful. There are
some point to suggust.
1.There is a dc-block. If the frequency domain is below 2GHz, a very cheap
dc-block could be made by PCB and discrete capacitor, which is about of $1.00:)
A commerical dc-block is about of $100:(
2.The "pigtail" effect should be awared. The pigtail should be as short as
possible.
I hope this is helpful.
I am also trying to corelate the measurement in time domain and frequency
domain. I have not get any success:( In SA maesurement, there is no phase
information. Another problem is "what is measured by SA?" I have found that
some kinds of noise could not be caught by SA.
Best Regards
Zhangkun
2005.1.5
----- Original Message -----
From: "Grasso, Charles" <Charles.Grasso@xxxxxxxxxxxx>
Date: Wednesday, January 5, 2005 10:38 pm
Subject: RE: [SI-LIST] Re: Article discussion on bad packages - core power
measurments
> Dear Zhangun
>
> I am intrigued by your last email. In it you mentioned that:
> "I measured the CORE power ground noise by spectrum analyzer...."
>
> I very interested in your experiences as I have tried to correlate
> SA power measurements with scope measurements with minimal success.
> One problem I think is that a SA has a 50ohm input impedance that
> can load the PDS and the coax needed to hook up the SA will add
> how hf filtering,
>
> Would you share with us some thoughts on how to use a SA for
> power measurements ??
>
> Thanks!
>
> Best Regards
> Charles Grasso
> Senior Compliance Engineer
> Echostar Communications Corp.
> Tel: 303-706-5467
> Fax: 303-799-6222
> Cell: 303-204-2974
> Pager/Short Message: 3032042974@xxxxxxxx
> Email: charles.grasso@xxxxxxxxxxxx;
> Email Alternate: chasgrasso@xxxxxxxx
>
>
>
> -----Original Message-----
> From: zhangkun 29902 [zhang_kun@xxxxxxxxxx]
> Sent: Wednesday, January 05, 2005 7:29 AM
> To: weirsp@xxxxxxxxxx
> Cc: hmurray@xxxxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Article discussion on bad packages - core
>
>
> 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
>
>
------------------------------------------------------------------
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:
