OK. sounds good. you might add in what Tom found too.
From: NATALIE WIENCKOWSKI <nwienckowski@xxxxxxx>
Sent: Tuesday, January 14, 2020 2:16 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx; George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: 802.3ch d3p0 late comments on state diagrams
George,
They're already in the database. I have corrected this in the proposed responses.
For the comment referencing page 88:
PROPOSED ACCEPT IN PRINCIPLE.
The actual signal line into "PHY CONTROL" is "scr_status / pcs_status".
Change Figure 149-26 to delete connection of "scr_status / pcs_status" to PHY CONTROL, and change the first sentence of the third paragraph of 149.4.2.3 (P145 L5) from "The PMA
Receive function uses the scr_status parameter and the state of the equalization, cancellation, and estimation functions to determine the quality of the receiver performance, and generates the loc_rcvr_status variable accordingly." to "The PMA Receive function
uses the parameters pcs_status and scr_status, and the state of the equalization, cancellation, and estimation functions to determine the quality of the receiver performance, and generates the loc_rcvr_status variable accordingly."
For the comment referencing page 156:
PROPOSED ACCEPT IN PRINCIPLE.
The incorrect figure was referenced in the suggested remedy.
In Figure 149-34 (EEE Refresh monitor state diagram), add PMA_refresh_status <= OK to state LPI_OK and add PMA_refresh_status <= FAIL to state LPI_REFRESH_TIMEOUT. (<= is used here to indicate
the assignment operator).
Change the fourth sentence of 149.4.2.7 from "The function forces a link retrain" to "The refresh monitor sets the PMA_refresh_status variable, which forces a link retrain"…
Thanks,
Natalie
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 14, 2020 5:11 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx <STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_NGAUTO] 802.3ch d3p0 late comments on state diagrams
forgot to answer the second question – yes, I wanted to change the refresh monitor figure, figure 149-34. (Natalie – let me know if you want me to resubmit the late comment with the corrections to the remedy. I believe we can do that
if you haven’t yet entered the comment into the myballot system.)
FYI – I’m suspecting my red highlighting got all messed up, so here is what it looks like on my screen:
-george
From: George Zimmerman
Sent: Tuesday, January 14, 2020 1:35 PM
To: NATALIE WIENCKOWSKI <nwienckowski@xxxxxxx>;
STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: RE: 802.3ch d3p0 late comments on state diagrams
It probably should have been two signals to begin with, and if you want to use my comment to do that split, I’m fine with it. there is no combined “scr_status/pcs_status” signal – they just happen to come from and go to the same places.
I don’t see scr_status used in the PHY control either (except as it effect loc_rcvr_status) , so the simplest change is just to delete the connection of both to the PHY Control block, which was my comment, deleting the line I’ve shaded
red in your figure below.
-george
From: NATALIE WIENCKOWSKI <nwienckowski@xxxxxxx>
Sent: Tuesday, January 14, 2020 12:18 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx; George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: 802.3ch d3p0 late comments on state diagrams
George,
I have been reviewing your comments to ensure I know how to implement them and have some questions.
For the first comment below referencing page 88, the suggested remedy includes: Change Figure 149-26 to delete connection of pcs_status to PHY CONTROL. There is not a pcs_status signal in the
Figure. There is a scr_status/pcs_status signal. Are you suggesting that this connection be deleted from PHY
CONTROL, or should this be broken into two separate signals with scr_status still going to PHY
CONTROL and PMA RECEIVE and pcs_stats going to PMA RECEIVE only?
For the second comment below referencing page 156, I believe the Figure you want changed is the EEE Refresh monitor state diagram 149-34, not 149-33. 149-34 contains the States you mention.
Thanks,
Natalie
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 14, 2020 10:54 AM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx <STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx>
Subject: [802.3_NGAUTO] 802.3ch d3p0 late comments on state diagrams
All –
Reviewing the state diagrams and variables internal to the Marvell team, we noticed a couple of things awry in the state diagrams. I would urge all of you to review the state diagrams and variables carefully, because missing these things
can draw out a ballot.
These late comments are in addition to the earlier late comment submitted – I believe Steve and Natalie are processing them now.
Both of these relate to the loc_rcvr_status variable, which, as the text says (and as in similar PHYs) is generated in an implementation-dependent manner. We do not propose to change this.
The first issue is that pcs_status, although passed to the PMA and shown in the PMA reference figure to go to both PHY Control and PMA Receive, is not mentioned anywhere in either the state diagrams or text of the PMA section. Previously,
in similar PHYs, and earlier in our drafts, this parameter was used to help the PMA determine when a retrain needed to be forced to retrain. Since then we have changed where the state machines referenced it. It is useful and generally necessary to consider
the state of the PCS in determining loc_rcvr_status, but right now the text limits this to the PCS information to the state of the scrambler. The proposed change would fix the reference figure to show that pcs_status is NOT used in the PHY control directly,
and modify the text to show that pcs_status is available for determining loc_rcvr_status.
The second issue involves PMA_refresh_status. The link monitor state diagram uses this, but we changed the Refresh Monitor state diagram to operate directly on loc_rcvr_status. We have a choice – either we can remove the references
to PMA_refresh_status everywhere, or, make the Refresh monitor produce PMA_refresh_status. Since loc_rcvr_status is SUPPOSED to be implementation dependent (the text says this in numerous places) it seems inappropriate to define a setting of it in a state
diagram. Also, it is described as being generated with the scrambler status, and the state of the equalization, cancellation, and estimation functions (and pcs_status if the above comment is accepted), not the refresh status. SO, the proposed remedy is to
just have the refresh monitor produce this variable properly, rather than force loc_rcvr_status to FAIL. The link monitor currently uses an OR of the two variables, so this isn’t a functional change.
The detailed text of the comments is below.
I will likely not be on this Wednesday’s ad hoc call, due to a conflict, so, please feel free to discuss on the reflector (preferably, so everyone can participate) or email me directly.
-george
====
Technical comment
Page 88 line 4, 149.2.2.6
The parameter pcs_status is passed to the PMA from the PCS, but other than showing it is being passed in figure 149-26 to PMA_Receive and PHY_Control, there is no mention of this parameter’s effect on behavior. It appears that pcs_status
may be used in the determination of loc_rcvr_status, because it indicates block lock in the PCS and RS-FEC behavior. Additionally, neither pcs_status nor scr_status are used in the PHY Control state diagram as indicated in Figure 149-26.
In draft 2.0, pcs_status was in the link monitor state diagram, but in the current draft this has been replaced by pcs_data_mode. pcs_status = OK requires the hi_rfer indication to be false, but pcs_data mode doesn’t – it just requires PHY
Control to have progressed to data mode, which initially requires hi_rfer to be false, but not continually.
If the link_monitor goes to fail, the link goes down and pcs_data_mode is set false by the link_synchronization state diagram (or autoneg) reseting the phy control.
Reading through this, it looks to me like the new state diagrams can operate in a perpetual state of hi_rfer or even loss of pcs block lock. That could be a problem, but can be remedied if loc_rcvr_status may be set with the information from
pcs_status.
Suggested remedy:
Change Figure 149-26 to delete connection of pcs_status to PHY Control, and change the first sentence of the third paragraph of 149.4.2.3 (P145 L5) from “The PMA Receive function uses the scr_status parameter and the state of the equalization,
cancellation, and estimation functions to determine the quality of the receiver performance, and generates the loc_rcvr_status variable accordingly.” to “The PMA Receive function uses the parameters pcs_status and scr_status, and the state of the equalization,
cancellation, and estimation functions to determine the quality of the receiver performance, and generates the loc_rcvr_status variable accordingly.”
Must be satisfied: No.
====
===
Technical comment
Page 156, line 51 Subclause 149.4.4.1
Comment:
The Link Monitor state diagram (Figure 149-33) uses the variable PMA_refresh_status for one of its transitions but the behavior is not defined anywhere.
Section 149.4.4.1 indicates that it indicates the status of the Refresh Monitor and is described in 149.4.2.7, but there isn’t any definition there.
The Refresh Monitor (Figure 149-34) sets loc_rcvr_status to NOT_OK upon failure, which causes the same transition in the Link Monitor state diagram as PMA_refresh_status=FAIL, so I suspect that a change was made and some of the references
to PMA_refresh_status were not removed. Further, the definition of loc_rcvr_status elsewhere is listed as ‘implementation dependent’ and the result of monitoring the receiver performance (149.2.2.7 and 149.4.2.3) – having behavior defined in a state diagram
contradicts these statements.
Suggested remedy:
In Figure 149-33, add PMA_refresh_status <= OK to state LPI_OK and add PMA_refresh_status <= FAIL to state LPI_REFRESH_TIMEOUT. (<= is used here to indicate the assignment operator). Change the fourth sentence of 149.4.2.7 from “The function
forces a link retrain” to “The refresh monitor sets the PMA_refresh_status variable, which forces a link retrain”…
Must be satisfied: No.
===
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
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
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