Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3ae] Unclosed TR comments




Hi,
There are still some unclosed TR comments against 802.3 where technical
discussion is required versus some procedural assessment in the response to
this comment. One important comment against the Serial WAN Phy was the
required clock tolerance rate at the receiver. In the arguments rejecting
this was stated that this primarily concerns clause 51. This assessment is
difficult to be followed, as a +/- 20ppm serial clock of the PHY will always
lie within a +/- 100ppm XSBI requirement (where one can argue for, as this
is a common internal interface)
 However concerning the technical reason on the serial interface the
following is a matter of fact:
-	due to the +/- 20 ppm spec of the transmitter there will never be a
requirement for +/-100 ppm . This concerns in main the pullin range of the
receiver PLL (under full jitter!)
-	The pull-in range of a PLL is subject to various influences
concerning temperature drift, aging and relation to distortions as
particular jitter content which will narrow down the lifetime worst case
range.
This means that it is easier to design a PLL (CDR) in relation to a more
exact clock frequency than to a wider range. This would enable two things,
design a bit simpler design to save effort and cost for the WAN Phy, as over
temperature the window from where a frequency needs to be recovered is
narrower that it would be for 100 ppm. The other opportunity would be to
allow a wider temperature range for units working on the WAN in comparison
to the LAN using a common approach as a smaller tolerance range of input
clock allows a larger temperature drift of overall pull-in range. 
As there will always be in relation to the transmitter specification WAN
signal of +/- 20ppm there should made use of this and simplify wan Receiver
requirement to use this cost saving opportunity.
This does not force anything to be changed o the parallel interfaces further
down in the system where this pull-in problem is much relaxed anyway.
So this comment is strictly technical, related to clause 52 only and removes
an inconsistency as currently there is an unnecessary stringent pull-in
range requirement.
Regards Juergen Rahn