[802.3_SPMD] Comment R1-61

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

Hi George,

Further to your reference to comment R1-61 below, I am attaching a timing diagram (comment_R1_61_timing.pdf) that illustrates my concern. As always, I'm very happy to be corrected if I'm missing something, but my concern is that a BEACON can be transmitted by the coordinator node shortly after the end of a packet sent during the last transmit opportunity. I believe that the CRS de-assert delay is shorter than the RX_DV de-assert time. This is not an issue for MAC operation as CRS is only used by the MAC transmit function for CSMA/CD operation, and RX_DV is only used by the MAC receive function to frame the data, but the Figure 148–3 PLCA Control state diagram uses both for its operation.

As a result, I am concerned that if the end of packet to BEACON delay is short, RX_DV may not be de-asserted from the end of the packet until after the CRS is asserted for the subsequent BEACON at another node on the segment. I believe this can result in that node missing the BEACON, preventing it from transmitting since its current Transmit Opportunity counter (curID) keeps incrementing, and is not reset by the BEACON, as seen for nodes 2 and 3 in the attached (comment_R1_61_waveform.pdf) simulation waveform.

I've used the following parameters in the timing diagram:

tTCL_EoP_to_CRS_node_0 : End of packet at TCI to CRS de-asserted Node 0 (Table 188-5: TCI input to CRS deasserted)

tCRS_to_TX_ER_SoB_node_0 : CRS negated to TX_ER BEACON encoding Node 0 (not specified)

tTX_ER_to_TCI_SoB_node_0 : TX_ER BEACON sampled to start of BEACON TCI Node 0 (Table 188-5: TX_EN/TX_ER sampled to TCI output)

tTCI_SoB_to_CRS_node_n : Start of BAECON at TCI to CRS asserted Node n (Table 188-5: TCI input to CRS asserted)

tTCI_EoP_to_RX_DV_node_n : End of packet at TCI to RX_DV de-asserted Node n (derived from Table 188-5: TCI input to RX_DV asserted)

Based on the above, the minimum delay between the end of a packet and the start of a BEACON (tEoP_to_SoB) on the TCI is:

tEoP_to_SoB min = tTCL_EoP_to_CRS_node_0 min + tCRS_to_TX_ER_SoB_node_0 min + tTX_ER_to_TCI_SoB_node_0 min

NOTE: Table 188–2 DME timings specifies a minimum delay between transmissions (T1) of 480 ns, but since Table 188-5 specifies a TCI input to CRS de-asserted of 640 ns minimum and a TX_EN/TX_ER sampled to TCI output of 120 ns minimum, it seems this minimum delay between transmissions does not impact the above calculation.

Since the delay between the end of a packet and the start of a BEACON is determined by the coordinator node, but the issue occurs when another node misses the BEACON, I believe that we need to consider the worst case where the coordinator node has minimum delay values, but the other observing node has maximum delay values.

Assuming for correct operation, RX_DV has to be de-asserted at the end of the last transmit opportunity packet before, or at the same time as, CRS is asserted for the following BEACON:

tEoP_to_SoB > tEoP_TCI_RX_DV_node_n max - tTCI_SoB_CRS_node_n min

NOTE: Using the maximum tEoP_TCI_RX_DV_node_n value in combination with the minimum tTCI_SoB_CRS_node_n value is probably unreasonable since these parameters are for the same device. Assuming, however, that they will track perfectly may also be unreasonable, as the implementation path for the CRS, which is based on TCI activity as described in subclause 188.4.6, may be different from RX_DV, which is based on clocked receive characters as described in the Figure 188-7 state diagram.

Based on the above:

tTCL_EoP_to_CRS_node_0 min + tCRS_to_TX_ER_SoB_node_0 min + tTX_ER_to_TCI_SoB_node_0 min > tEoP_TCI_RX_DV_node_n max - tTCI_SoB_CRS_node_n min

As a result:

tCRS_to_TX_ER_SoB_node_0 min > tEoP_TCI_RX_DV_node_n max - tTCI_SoB_CRS_node_n min - tTCL_EoP_to_CRS_node_0 min - tTX_ER_to_TCI_SoB_node_0 min

While the end of packet at TCI to RX_DV de-asserted delay is not specified in Table 188-5, I believe it can be derived from the TCI input to RX_DV asserted specified in Table 188-5. With my acknowledgement and my thanks to Dick Gahan for helping me understand the PHY specification, I believe that the TCI to RX_DV de-assert delay is two symbol times shorter than the TCI to RX_DV assert delay. This is because an ESD and an ESDOK symbol is appended to the end of a packet on transmit (see Figure 188-4). RX_DV, however, is de-asserted at the start of the ESD symbol, two symbols before the end of activity at the TCI on receive (see Figure 188-7). Based on this assumption, and the TCI input to RX_DV asserted delays specified in Table 188-5, the TCI input to RX_DV de-asserted minimum delay is 2.4 - 0.8 = 1.6 us and a maximum delay is 4 - 0.8 = 3.2 us.

Based on the above, and the other values in Table 188-5:

tCRS_to_TX_ER_SoB_node_0 min > 3200 ns - 400 ns - 640 ns - 120 ns

> 2040 ns

I appreciate that specifying a 2.04 us delay between CRS negated to TX_ER BEACON encoding for the PLCA RS will be unpalatable due to the performance impact. Another suggestion I therefore have is to reduce the Table 188-5 TCI input to RX_DV asserted delay if possible, although I note that the Figure 188–7 PCS Receive state diagram imposes a minimum three-symbol delay, since the DECODE function operates on RXn–3 (the rx_sym parameter used is from 3 cycles before the most recent one). As an aside, since the MAC can operate with preamble loss (see subclause 4.2.6), could the PHY perhaps discard the first three preamble symbols and then operate on the DECODE function on RXn.

Best regards,

David

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: 30 October 2025 16:05
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: [802.3_SPMD] status of comments to be closed:

I have the following status on the comments to be closed on 802.3da:

R1-28 (informative annex) – text received, working with author, to be decided whether to include this or suggest author consider other venues for publication of informative material (https://www.ieee802.org/3/SPMD/email/msg00889.html)

R1-30 (TCI RL in the presence of current) – editor’s proposal offered. (https://www.ieee802.org/3/SPMD/email/msg00900.html )

R1-39 (electrical isolation for PHYs that are not MPIs) – proposed response confirmed in email, https://www.ieee802.org/3/SPMD/email/msg00905.html

R1-40 & R1-41 (multiple ports and isolation) – proposal offered - https://www.ieee802.org/3/SPMD/email/msg00906.html

R1-61(delay for RX_DV) – we haven’t had anything on the reflector to close this yet… some offline discussion. Please bring to the reflector (https://www.ieee802.org/3/SPMD/email/msg00893.html)

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

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