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

Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Question on Baseline Text Proposal for TDD Based 802.3dm PHY

Hi Wei,

 

Thanks once again for your prompt response to my questions.

 

Regarding the comment about the PHYC state diagram having sufficient information, I am not sure that this is the case. The current New-TDD baseline text was provided “fully formed” to the task force without any explanation of how the solution was derived. My following questions related to the SILENT1 state should demonstrate this.

 

I have now implemented a simulation of the New-TDD Control State Diagram, and I have several questions related to the SILENT1 state:

  1. Why is the SILENT1 state needed, and does it serve any purpose for the receiver on the Master side?
  2. The slave will exit the SILENT1 state as soon as loc_rcvr_state1 is OK, without any min_wait_timer, so theoretically the Slave could fall directly through the SILENT1 state. Would this be a potential interoperability problem for the Master?
  3. The SILENT1 state has config_timer that is started when entering the SILENT1 state, and if this timer expires before exiting the SILENT1 state, the state will transition to the SILENT0 state. As far as I can tell there is no way for the Master to know if the Slave is still in the SILENT1 state or if it has transitioned to the SILENT0 state. The Master is now transmitting SEND_TA, but the Slave is expecting SENS_TS and will probably be stuck in the SILENT0 state. The startup sequence is now dead-locked as far as I can tell. Am I missing something?

 

Regarding the dead-lock in case 3 above, what happened in my simulation was the following:

  1. The Master is stuck in the TRAINING1 state until the link_fail_inhibit_timer will expire
  2. The Master transitions to the DISABLE_TRASMIT state and starts all over again and stops in the TRANINING0 state
  3. The Slave stays stuck in the SILENT0 state, even after its link_fail_inhibit_timer has expired, until it declares loc_rcvr_status is OK
  4. The Slave declears loc_rcvr_status is OK and transitions to the TRAINING0 state, but it’s link_fail_inhibit_timer has expired so it transitions straight into DISABLE_TRANSMIT and starts over again

What happens next is implementation specific.  If the Slave started transmitting before it exited the TRAINING0 state it might confuse the Master, but this is again implementation dependent. Are you seeing similar things in your simulations?

 

Ragnar

 

From: Wei Lou <000047a3c8c56bbe-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, July 13, 2025 6:10 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Question on Baseline Text Proposal for TDD Based 802.3dm PHY

 

Hi, Ragnar, Regarding loc_rcvr_status, statements b) and c) are both similarly defined in IEEE 802. 3ch. I agree with you that statement c) indicates that frame synchronization is required before loc_rcvr_status = OK. Please also note that pcs_status

ZjQcmQRYFpfptBannerStart

Prioritize security for external emails:

Confirm sender and content safety before clicking links or opening attachments

    Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

Hi, Ragnar,
 
Regarding loc_rcvr_status, statements b) and c) are both similarly defined in IEEE 802.3ch. I agree with you that statement c) indicates that frame synchronization is required before loc_rcvr_status = OK. Please also note that pcs_status and scr_status are used in data mode and training mode, respectively. I believe statement c) provides a fairly clear definition for loc_rcvr_status = OK.
 
As for statement b), the full sentence from the TDD text proposal reads:
 
“When loc_rcvr_status indicates OK, then the PCS Synchronization process accepts data-units via the PMA_UNITDATA.indication primitive. It attains frame and block synchronization based on the PMA training frames and conveys received blocks to the PCS Receive process when PHY control is in PCS_DATA state.”
 
In addition to the original sentence from IEEE 802.3ch, we added the clause “when PHY control is in PCS_DATA state” in our proposal for clarity—because block synchronization, in our view, only applies during data mode.
 
So, the proposal we’re presenting is not introducing anything fundamentally new; it’s consistent with both 802.3bp and 802.3ch.
 
Finally, since receiver design is implementation-dependent, I won’t comment on your specific state diagram. We believe our PHYC state diagram text proposal is sufficient as currently written.
 
Thank you!
 
Wei
 
________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=3dDl1ZUF-uXT7J1ynjH5Se8zuoPPO7cGvSbVXqoWPLElWOzfFGYn1sLSglvu5ldL&s=0G8QbwmNGssGaDoI89omCePrZcvsmsuhhB2-TfJ9wTY&e=

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1