Re: [802.3_4PPOE] Rewrite of 33.2.8.5

["Yseboodt, Lennart" <lennart.yseboodt@xxxxxxxxxxx>]

Hi Heath,

IPeak-2P indeed depends on Rchan, in 2 ways.

First in Eq 33-10, IPeak depends on Rchan.

Second, KIPeak in Eq 33-12 also depends on Rchan.

Because this is so complex (and useless to optimize for), a 'simple' worst-case calculation is provided in the form of IPeak-2P-unb_max. This number is higher than IPeak-2P-unb and using this would automatically mean meeting peak unbalance requirements.

With regard to George's comment that the lowerbound template should not depend on Rchan... that has always been the case, since at least AT.

ICon also depends on Rchan for instance. Here it does make sense as it allows a PSE to optimize the power output to match with the channel losses.

Kind regards,

Lennart

---

From: Heath Stewart <00000855853231d4-dmarc-request@xxxxxxxx>
Sent: Friday, January 6, 2017 0:13
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5

 

All,

We are noticing a few incongruities after looking at this longer.

1) Inadvertent change

"Alternatively, an over-margined value of IPeak-2P-unb, IPeak-2P-unb_max which is defined by Equation (33–14), may  be used."

is incorrect. It creates an alternate definition of IPeak-2P-unb.

It used to create a new variable, IPeak-2P-unb_max, which happens to have a relationship to IPeak-2P-unb. We need to preserve the original wording. This term is only used to form Iunb.

"The worst case value of IPeak-2P-unb is IPeak-2P-unb_max which is defined by Equation (33–14)."

2) The lower-bound template as defined by IPeak-2P (by way of IPeak-2P_unb) now has a third dimension, Rchan-2P. This is not only strange but is at odds with the definition of Icon-2P_unb, which is a scalar.

Is this what we want?

Cheers,

-Heath

On Wed, Jan 4, 2017 at 1:30 PM, Abramson, David <david.abramson@xxxxxx> wrote:

Hi everyone,

 

I just wanted to give everyone a chance to review my rewrite of 33.2.8.5.  I have attached a final version and a marked up version to this email.  I have tried to include everyone else’s comments on this section.

 

Regards,

 

David Abramson

IC Design

Power Interface

Texas Instruments

Office:  603.222.8519

Mobile:  603.410.7884