| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
William – the 802.3ch task force discussed your email on comments 70 & 96 today. We decided on comment 70 (timing requirements) to stay with just changing the reference to 46.1.7, on the basis that the timing requirement in 46.3.1.5 was not a timing requirement on the phy changing to LPI mode, but rather a requirement
on the action of the clause 46 XGMII interface clock being stopped. (the sentence we were considering says:
PHYs with the EEE capability support transition to the LPI mode when the PHY has successfully completed training and pcs_data_mode is TRUE and subject to the timing requirements of 46.3.1.5. 46.3.1.5 states a behavior not on the PHY transition to LPI mode, but on the RS stopping the clock at the XGMII. On comment 96, we also decided to stay with the change, and reference that pcs_status on the generation of loc_rcvr_status. This one was a bit more of a judgement call. We agree that the loc_rcvr_status is implementation independent,
and this has been the case in all the multigbase-t phys and 1000BASE-T1. The difference is the PHY control diagram. all the multigbase-t phys use pcs_status in the phy control diagram, and generally they use it or’d (in the appropriate transitions) with
loc_rcvr_status. Clause 97 substitutes this out with loc_phy_ready. Clause 149 chose not to use a new variable for this purpose, and doesn’t have loc_phy_ready. However, it also chose not to use pcs_status in the PHY Control, so, as a result, the reader has NO IDEA why pcs_status might be passed to the
PMA. Taking the transmission of pcs_status out of the PMA would keep implementers from using it in phy control or link monitoring – we agreed that would not be good. Also, having no guidance where it might fit in is also bad. The usual way it gets used
(and there was some consensus on this by phy designers in the room) is through (or aligned with) loc_rcvr_status. Therefore, having the descriptive text is helpful, and the designer should be able to know that when pcs_status hasn’t yet been defined in phy
control, you really shouldn’t use it in generating loc_rcvr_status… Since scr_status only reflects the training mode scramblers, this would likely be used during training, and pcs_status would likely be used in later stages. Thank you for consideration and review of the comments. These are subtle points. George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |