I also work with high power divices:- Groups of Elevators ( as in moving people up & down buildings). The problem is the same but the scale is different (study Chaos Theory for a deeper insight!).
Foget RMS and simple averaging. Work with RSS ([Square] Root of the Sum of the Squares values & you will hit a realistic value. Your power supply will need to take care of peak power (high but short time) to avoid collapse. You
can get this from the study of a few buffers operating in worst case signal conditions (all OFF, switching ON:- don't forget the reset switching condition).
Transmission lines..how good is your model for short line lengths? Work on what you know is going to be physical reality..otherwise you can be in "foo dust "..looks interesting but has no value in reality.
Hope this helps
Best wishes
Adrian
Pat Zabinski wrote:
> I'm working on a rather large system (over 50,000 Watts!), and we
> are trying to come up with some detailed power estimates for
> each component.
>
> The system is essentially comprised of LOTS(!) of identical
> parallel processing ASICs, each ASIC having roughly 600 I/O.
> The basic I/O is full-swing CMOS with a 2.5 VDD supply running
> at roughly 100 Mbps. A small change in one ASIC will have
> a three-orders of magnitude higher impact on the system, so we need
> to pay very close attention to details. The I/O have been
> designed and tweaked to account for impedance, edge rates,
> packaging effects, etc., so we have a high level of confidence
> they are going to work; at this point, we simply need to
> obtain a power estimate for them.
>
> In order to come up with good system-level power estimates (which
> will determine cooling requirements and power supply requirements),
> we need to have an accurate ASIC power estimate. We've got pretty
> good numbers for the core circuitry, but we're trying to develop
> an estimate for the custom I/O buffers.
>
> To get the power for one buffer, we simulate the buffer with
> a 1010101... pattern, toggling every possible bit period.
> The buffer is loaded with an average-length transmission
> line, and we use spice to plot the power vs time for at
> least two bit-transitions. Overall, we get a power
> vs time plot that is relatively flat except during the logic
> transitions (no surprise here), and the peaks vary in amplitude
> depending upon a rising or falling edge.
>
> In the past, we have used the "simple average" power, meaning
> taking the integral of the power over two bit periods (to ensure
> we've captured one falling and one rising edge)and dividing
> it by the time. We have used this figure as
> our average power for the worst-case-bit-pattern.
>
> However, a colleague recently suggested using the "RMS average"
> of the power, which is computed slightly differently. For our
> case, the RMS average resulted in a power estimate that was
> 50% higher than the average value.
>
> >From my experience, taking the integral of the power curve will
> result in the effective energy consumed by the buffer, and dividing
> this by the time will provide the average power. However,
> RMS is used so frequently in power estimates, I could not provide
> a good answer why it shouldn't be used.
>
> Can anyone tell me how to best determine the average power
> for a buffer? Am I anywhere on the right track? Which is better,
> simple average or RMS average?
>
> One other point to note: as we increase the transmission line
> length, the RMS power goes up as well (as expected). However,
> this trend continues to a certain point, then the power actually
> reduces with increased line length. Can someone explain why
> the RMS power would be reduced with increased length? We're only
> seeing a small percentage change (~10-20%), but it's got
> me curious.
>
> Thanks,
> Pat Zabinski
>
> --
> Pat Zabinski ph: 507-284-5936
> Mayo Foundation fx: 507-284-9171
> 200 First Street SW [email protected]
> Rochester, MN 55905 www.mayo.edu/sppdg/sppdg_home_page.html
>
> **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****