RE: PSE vs. PD power dissipation again
Yair, Dave, all,
I'll throw some more fuel to the fire below...
Brian
>-----Original Message-----
>From: Yair Darshan [mailto:YairD@xxxxxxxxxxxxxx]
>Sent: Wednesday, March 21, 2001 5:06 AM
>To: 'Dave Dwelley'; stds-802-3-pwrviamdi@xxxxxxxx
>Subject: RE: PSE vs. PD power dissipation again
>
>
>
>Dave,
>See my comments bellow.
>
>Yair.
>
>> -----Original Message-----
>> From: Dave Dwelley [SMTP:ddwelley@xxxxxxxxxx]
>> Sent: ד מרץ 21 2001 4:43
>> To: stds-802-3-pwrviamdi@xxxxxxxx
>> Subject: PSE vs. PD power dissipation again
>>
>>
>> Group -
>>
>> In lieu of a dedicated power ad-hoc reflector, I'm posting
>this to the
>> general list. Is there a power reflector in the works?
>>
>> I'm assuming that we'd eventually like to integrate the
>power switches
>> into
>> a PSE chip, and that PSE designers will tend to want to
>service multiple
>> channels with a single chip: 4, 8, or more.
> [Yair Darshan] (1) Yes we would like it, if it will
>not increase
>system cost and complexity (PSE and PD).
>> Also, I assume that we'd like
>> to be able to power up many PDs simultaneously (when the
>wiring closet
>> power comes back on after a California shutdown) - this
>isn't critical,
>> but
>> it's desirable.
> [Yair Darshan] (2) I don't think it is an issue at
>all, since after
>break down of long time, it is not important if a PD will get service
> right now or within few seconds.
[Brian Lynch] If it is OK for a PD to get service "within a few seconds"
then
why do we concentrate so much on detection/classification time? If, by
adding
a classification step to discovery, we add 200ms, is that a problem? How
much time
will it take for the 100th port to come alive in a large system?
>> To do this, we need a scheme that keeps the power
>dissipation out of the
>> PSE end.
> [Yair Darshan] Agree. Remember that we have two cases of power
>dissipation. Case 1: during startup. Case 2: During normal operation.
> In Case 1: We indeed can reduce the power loss in PSE switch by
>setting the PD current limit lower than the PSE, we are not "kill" the
>problem completely, we just moving it to the PD with some ability of
>reducing it by increasing PD cost.
[Brian Lynch] I agree that in startup the power has to be lost in either
the PSE or the PD. That is physics. By putting the inrush current limit
on the PD side, and setting the current limit to a value below the current
limit in the PSE, we get a number of advantages.
- The PSE switch losses are always low. Turn ON losses
can be limited to 300mw for the initial "spike" and continuous
operation losses are in the 100mw region. (assuming a 1 ohm MOSFET).
In a practical case, the RdsON will be much less. A SOT-223 FET or SO-8 with
RdsON in the .02 to .05 range will dissipate much less.
- In a fault condition (as a shorted wire) the reaction time may be
virtually instantaneous, keeping PSE switch losses low.
- The PD designer has the freedom to choose the size and rate of
charge of
his PD's bulk capacitor, and thus the size of the MOSFET used. A low cost PD
can use a small MOSFET, and a higher end device may use a larger. The point
is that
PD can be sized to the job, and not be limited by avoidable constraints.
If the PSE limits the inrush current:
- The PSE muse always be sized for the worst case, which is at least
350ma for the maximum startup time allowed. So for large systems and small,
the PSE
would need to have and expensive D2PAK MOSFET on every port.
- Under a shorted wire condition, the switch must stay on for and
extended
period of time. (A time greater than the longest startup time). If the
current limit is
set at 500ma, then the losses could be as high as 57*.5=28.5 watts for up to
500ms.
- The size of the PD bulk capacitor must be limited, and the time to
turn-on
must be limited in the spec, constraining future design freedom.
- To avoid startup issues, additional circuitry is needed in the PD
to keep
the switch ON while the PSE voltage drops to zero and begins charging the
bulk capacitor.
The added circuitry must have energy storage in it sufficient to keep the PD
switch alive for the
time it takes to charge the capacitor....more cost and potential for failure
to start up.
> Case 2: During normal operation we need to support
>350mA avg, with
>57V output. It means a 80-100V, 0.6-1A MOSFET which its die
>size is function
>of the Rdson. At 350mA average current the power loss on the
>FET will be
>0.350^2xRdson.
[Brian Lynch] 100mw/port or less.
> In low cost plastic package you can dissipate between
>1-1.5W thus to
>meet this number you will need low Rdson MOSFET
> which will have large die size.
> We didn't mention yet what we will need with current
>peaks above the
>average which is normal situation at some loads.
[Brian Lynch] The peak current requirements, no matter what they are, will
only the change the numbers, not their relative positioning.
>
> To summarize this: I am not sure that integrating the
>Mosfets in the
>chip will get us important advantages.
> Info received from chip vendors shows that:
> a- They have the technology to implement MOSFET (HV technology )
>with the chip (Low voltage technology)
> b- Integrating the MOSFET into the chip will not save footprint
>since the die size is large which will increase the package size.
> c- The cost of integrated chip+Mosfet is greater than
>the cost of
>low power low voltage small package chip with external MOSFET.
>
> In light of the above what is the incentive to
>integrate the Mosfets
>into the chip?
>
>> Rick and Dieter have both shown that if the PD limits inrush
>> current to some value lower than the PSE current limit (eg.,
>350mA for the
>>
>> PD, 500mA for the PSE), dissipation in the PSE is near zero.
> [Yair Darshan] Dissipation on PSE switch is very low and
>dissipation on PD switch is very high.
>
[Brian Lynch] The loss in the PD switch FET can be limited to any value,
depending on the startup time allowed. It can be as high as 10watts for
100ms
startup (into a 100uf capacitor charging to 57 volts) or as low as 200mw for
a
longer period of time, then less than 100mw continuous. It is up to the PD
designer to
decide the trade offs he is willing to make.
>> This one of
>> several options allowed by the draft standard as it reads
>now - others
>> share the dissipation between the two ends (the Avaya
>resistor divider/FET
>>
>> scheme), or put all the dissipation in the PSE (the
>UVLO/latch-on scheme
>> that Micrel showed at the meeting).
>>
>> If we allow any PD to push any dissipation back into the
>PSE, we force the
>>
>> PSE to be able to handle the worst case - all channels powering
>> simultaneously, with all the power in the PSE.
> [Yair Darshan] All channels are not required to startup
>simultaneously. After detection we can turn on each channel
> at atime since we have control on it according to management
>requirements.
>
[Brian Lynch] Will mid-span have the same intelligence for startup?
>> To do this, the PSE needs
>> some accommodation: heat sinks,
> [Yair Darshan] No heat sink required. With D2PACK, we
>can support
>easily 500mA peak for 100mSec.
> Now, if we reduce the time from
>100mSec to
>40-50mS it is even better.
[Brian Lynch] Perhaps better for dissipation in the PSE switch, but worse
for a PD designer, since now EVERY PD must start in a certain time. Low cost
and
high end.
>> external FETs,
> [Yair Darshan] Agreed.
>> sequential power up algorithms (which lengthen average
>detect time), or
>> low current limits at startup. None of these are desirable.
> [Yair Darshan] - Sequential power up algorithm is
>easy to get with
>no cost. We will need some intelligence in any case.
> this requirement is part of it. It will help reducing
>power supply
>size and many other good advantages.
> [Yair Darshan] - It will not affect detection time,
>it will affect
>the time that the PD is turning on, However we agreed that it is not an
>issue, since boot up time can be long ( Laptop, PC etc...)
>
>
>> There is the issue of line capacitance, which will put the
>PSE into its
>> 500mA limit briefly (<74us) - but this short time duration won't
>> significantly heat the PSE. We could also see a short on the
>wire - in
>> this
>> case, the PSE could shut off quickly (<1ms) or incorporate
>foldback to
>> limit dissipation, like Micrel showed.
> [Yair Darshan] As stated before, if we can support
>500mS for TBD
>ms, the above is not an issue.
>
>> I propose that we mandate that the PD limit the inrush
>current, say to
>> 350mA +/-50mA, and mandate that the PSE limit at say 500mA
>+/-50mA. By
>> forcing the PD to do this, we allow a multi-channel PSE chip
>with FETs on
>> board. Otherwise we can't do it.
> [Yair Darshan] I do not agree to this conclusion from
>the reasons
>mentioned above, and from the reasons described
> in my presentation regarding "Where to
>locate the inrush current limit".
> If you do not agree to my
>conclusions and
>data presented there, lets discuss it and crack it,
> until we will have the best
>understanding of
>what is the optimum solution for us.
[Brian Lynch] I the 350+/-50ma and 500ma +/-50ma are reasonable numbers.
I think putting the inrush control in the PD side provides a more robust
solution that allows more design freedom and less opportunity for
mis-behavior.
It is relatively easy to specify, and allows designers to size their PDs
according
to their own needs, without impacting system behavior.
Yair, I think the approach you describe can be made to work in a limited
scope,
but with so many vendors, so many designers, and so many unknown future
designs,
I think it is prone to difficulty, not only in specifying, but in
implimentation.
>
> In my opinion, setting the PSE to 500mA for TBD msec. and not
>forcing inrush current limiter in the PD is the desirable solution
> in terms of performance/cost ratio.
> It does not mean that the PD will not have current
>protection. It is
>part of the PD power supply after the big cap.
> We are discussing only on the inrush current limiter
>that should be
>located before the PD big cap.
>
>
>> This does make a bare-bones PD more complicated. In the
>short run, it
>> probably requires a low-cost op amp and a sense resistor to
>implement - or
>>
>> a 150 ohm/~1W series resistor and a FET to short it out when
>the switcher
>> input cap voltage approaches the line voltage
> [Yair Darshan] All the above functions and more you
>have already in
>the PSE. Why duplicate it also in PD?
[Brian Lynch] THere has to be some control for the switch in the PD. Whether
it is
ON/OFF or a current limit circuit, there has to be something. A resistor and
an NPN
would do it, too.
>
>> Going forward, the PD
>> function (with power device, current limit, UVLO, the works) can be
>> integrated - and since PDs generally don't need multiple
>channels, the
>> power in the single switch is tolerable (as Dieter showed at
>the meeting).
>>
> [Yair Darshan] The power in the switch is tolerable
>also if it is
>on PSE when external FET is used.
>> The "30 watt" PD would conceivably need a dual - we'll use a bigger
>> package
>> or some other trick to deal with the heat in that case.
>>
>> How much is it worth to integrate a multi-channel PSE chip?
> [Yair Darshan] From the data that I have today: It is
>not worth the
>effort. To many problems compared to trivial solution.
>
> [Yair Darshan] To summarize the above, I think that we need to
>answer the following questions:
>
> 1. Do we have a space problem that integration the MOSFET in the
>chip can help us?
> 2. Do we have power loss problem when the fet is not integrated?
> 3. Do we have power loss problem when the fet is integrated?
> 4. How chip cost affected by integrating the Mosfet
>compared to chip
>+ discrete Mosfet?
> 5. Cost of multi channel chip with integrated Mosfets
>compared to
>multi channel chip with external Mosfets
> 6. Foot print of multi channel chip with integrated Mosfets
>compared to multi channel chip with external Mosfets
> 7. Can we support many applications with low cost
>solution when the
>PD contains the inrush current limit function?
> 7.1. What it does to PD cost
> 7.2. What it does to System cost
> 7.3. How it complicate PD design
> 7.4. How it affect PSE-PD inter-operate
>
> Yair Darshan/ PowerDsine
>
>> Dave Dwelley
>> Linear Technology
>>
>