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

Re: [802.3_SPMD] DPLCA State Diagram Errors

Michael – the first issue is a matter of the text being incorrect.  Tim and I discussed this when we were resolving the D-PLCA state diagrams.  Only the last slot is tested to be open.  Due to an editorial error in the text, we had left fixing the description for D3.0.  The diagram works as is.  If you keep the last two always open, you would always have one extra slot.

 

The State Diagram does not perform the reduce action when the last two TO are empty, but always when the last TO is empty.

 

So, we need to fix the descriptive text.  (by and large, trust the diagram – its been checked more than the text).

 

I’ll have to look into the other two issues.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Paul, Michael <Michael.Paul@xxxxxxxxxx>
Sent: Tuesday, August 12, 2025 12:32 PM
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: [802.3_SPMD] DPLCA State Diagram Errors

 

All,

 

The designer who has implemented DPLCA at ADI, Pablo Ventura, has spotted 3 potential issues with the DPLCA spec, one of which is possibly an error in the state machine diagram.

 

 

  • Page 82, figure 148-8 DPLCA Control state Diagram
    • Transition from COORDINATOR state to REDUCE_NODE_COUNT state
      • In the conditions for transition the last node unclaimed !CLAIMING(plca_node_count-1) needs to be ANDed with another check for the 2nd last one also unclaimed !(CLAIMING(plca_node_count-2). This ties in with the text in page 78 line 37: “When the coordinator detects that no node has a claim on the last two transmit opportunities of the cycle, it transitions to the REDUCE_NODE_COUNT state”. Otherwise it may reduce count with just the last empty and then has to increase +1 to leave the 1 spare slot (in next age)
    • Transition from LOOPBACK_TX state to LOOPBACK_RX state
      • There may be a case where condition rx_cmd = BEACON is not met if 2 nodes transmitted at the same time and collided deforming the signal such that is not interpreted correctly as a beacon. Then this state machine will remain “stuck” in the LOOPBACK_TX state waiting for someone else to send a beacon… what if no-other node can do that (e.g. also stuck in the same state, or do not have the LeaderRoleAllowed configuration set, or are statically assigned PCLA ID) and the system is now stuck without beacons or way to self restore.
        • I propose an additional condition check in the LOOPBACK_TX state to go around to DISABLED stat when the “normal” PLCA control FSM did not identify the beacon (plca_status remains low) after we are finished transmitting our beacon (tx_cmd no longer BEACON): (tx_cmd != BEACON) & !plca_status
  • Page 76, figure 148-5 PLCA Data state diagram, part a
    • Transition from NORMAL state to IDLE state
      • The condition (local_nodID != 255) is required but should be disabled when dplca_en is active (e.g. while learning): ((local_nodID != 255) + !dplca_en). This would be similar to what is done in the PLCA control state diagram (page 73, figure 148-3) from DISABLE state to RESYNC state

 

 

Is there anything we are overlooking?  If not we will submit comments against the next draft to fix these issues.

 

Thanks,

Michael Paul

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

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