Hi George, Heath, and Lennart,
I have to agree with Lennart here. If you look at the existing standard (I will use 2012 because that what I have lying around), Ipeak is defined as:
Which not only depends on the channel but VPSE as well. While I understand your concern about it being related to the channel (really hard for the PSE to figure
out), I would point out that most PSEs just assume a worst case value (lowest value allowed) for VPSE as well. And just for reference, here is the lower bound template for 2012:
And while yes, the lower bound template relies on this parameter, you don’t actually need to do anything with it. Using the same picture I used in my last
email:
I would point out that the PSEs just needs to include the red box as part of the lower bound template (use the top of the red box). This removes any relation
to the channel from the lower bound template. I don’t see why we would need to change this as I believe everyone has figured this out already.
Regards,
David Abramson
IC Design
Power Interface
Texas Instruments
Office: 603.222.8519
Mobile: 603.410.7884
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, January 06, 2017 11:44 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Lennart – just because the template depended on Rchan in the past doesn’t make it good practice – we’ve uncovered more than a few ambiguities that we’ve dealt with in the
new spec.
If dependency on the template is essential and adds a substantial benefit (and is actually used in legacy products or necessary for broad market potential of new products),
that’s another story. It comes with a not-insignificant testing cost if one really wants to be compliant.
Testing compliance of the template when the template lower bound varies with Rchan requires testing over various values of Rchan. This is why I was saying that the template
should not depend on Rchan. (unless it provides a substantial benefit actually used in legacy products or necessary for BMP of new products)
From: Yseboodt, Lennart [mailto:lennart.yseboodt@xxxxxxxxxxx]
Sent: Thursday, January 05, 2017 11:14 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
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