Hi George and Heath,
I will try to address each point you guys made.
First, George, you are completely correct about the reference in Table 33-18, item 22 to the term Ipeak-2p-unb-max. I did not catch that and thus my rewording
of that sentence now seems strange. My understanding when I rewrote this section was that this was the worst case value which people could use in order to simplify the math. I used Pclass as an example, here is how Pclass which has a complex equation and
simple values in the table is worded (taken from page 110):
The minimum power output a PSE supports for a particular PD Class, when powering a single-signature PD, or supplying power in 2-pair mode, is defined by Equation (33–2). PSE implementations may use VPSE
= VPort_PSE-2P
min and RChan
= RCh
when powering using a single pairset, or RChan
= RCh/2 when powering using two pairsets to arrive at over-margined values as shown in Table 33–13.
Thus, not realizing that Ipeak-2p-unb-max was used anywhere else, I assume it was a similar thing. Now, I still believe the “over margined, but simpler” approach
that uses Ipeak-2p-unb will still be used in that way. This would mean people actually implement a lower bound template with the red square included as beneath the template:
I believe this is what most people do currently anyways. As such, I would like to try to come up with some wording that gets that point across while also referencing
the use of Ipeak-2p-unb-max in the Iunb requirements. I am sure we can do that over a beer.
For Heath’s second point, I am not sure what to say as I did not change any of the technical requirements (the lower bound template already depended on Rchan(-2P)
before my rewrite. However, I will give my opinion in a second email since there has been further discussion since this email.
David Abramson
IC Design
Power Interface
Texas Instruments
Office: 603.222.8519
Mobile: 603.410.7884
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, January 05, 2017 6:23 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5
Heath –
I emailed David A about the ‘Alternatively’ issue on item 1 above (hadn’t heard back). I agree with you it is a problem.
Because IPeak-2P_unb_max is actually used in a requirement which references 33.2.8.5 – Table 33-18, item 22 (page 121), this is problematic. Additionally, the term, “may
be used.” Is difficult – “may” gets translated to “is permitted to be” in IEEE standards language - may be used for what? – it doesn’t say.
We could change Table 33-18 item 22 as well, and create a new value, AND change the language here, I suggest a different, smaller change, that I think preserves the improved
clarity that David was trying to bring, AND avoids the problem:
I would delete “Alternatively” and replace “may be used” by “is used in Table 33-18 to limit the unbalance current in Type 3 and 4 PSEs.”
So that it says:
"An over-margined value of IPeak-2P-unb, IPeak-2P-unb_max which is defined by Equation (33–14) is used in Table 33-18 to limit the unbalance current in Type 3 and 4 PSEs."
2) I also agree that the lower bound template should be independent of the channel. I don’t have a good fix for that right now.
-george
From: Heath Stewart [mailto:00000855853231d4-dmarc-request@xxxxxxxx]
Sent: Thursday, January 05, 2017 3:14 PM
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