Re: [802.3_SPMD] Symbol aligner in 802.3 Clause 147 PCS
Hi Lokesh,
I think the reason is that the alignment with the incoming symbols is a PMA
RX duty, not a PCS RX. Since the PMA RX is allowed to consume up to 800 ns
before achieving both DME and 5B symbols boundary synchronization, it may
(theoretically) happen that the first received 5B symbol of the PCS RX is
SSD (having used both SYNC symbols to achieve synchronization).
Regards,
Antonio
-----Original Message-----
From: Lokesh Kabra <00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, August 1, 2025 9:42 AM
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPMD] Symbol aligner in 802.3 Clause 147 PCS
Hi George,
Thanks.
Yes, this issue is a bit tricky because the aligner cannot differentiate
between BEACON & SSD symbols until it is too late, in this scenario (when
first bit of BEACON is lost).
If you (or someone else) can recall or give a pointer on the reason why this
direct transition from WAIT-SYNC to WAIT_SSD was required, then we can
rethink on this.
Otherwise, I do not see a reason why this transition is required (triggered
only if first 2 symbols have errors).
Anyway, I will put in a comment in Clause188 as you suggested, to trigger a
discussion.
Thanks,
Lokesh
-----Original Message-----
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: 31 July 2025 21:29
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPMD] Symbol aligner in 802.3 Clause 147 PCS
Lokesh - reading your description, it appears you are proposing an
improvement to the clause 147 PCS spec. It doesn't appear that it is broken
(nonfunctional) per-se, just perhaps weaker than it might be.
As such, while you could suggest this as maintenance on clause 147,
Improvements (rather than fixing fatal errors or ambiguous specifications)
don't usually pass. They're new features...
However, I'd suggest that you are free to submit it as a comment on clause
188 as the initial SA ballot, which should open soon. That way the CRG can
discuss the issue on comments. I believe there was a good reason we had the
transition of WAIT-SYNC to WAIT_SSD, but, quite frankly, I am so tired after
this week I can't remember at the moment. Perhaps others can.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
-----Original Message-----
From: Lokesh Kabra <00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, July 31, 2025 2:33 PM
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPMD] Symbol aligner in 802.3 Clause 147 PCS
Hi all,
Resending this query as we did not receive any response to my earlier email.
If this is not the right forum to raise this, please advise on which forum I
can raise this issue.
Thanks,
Lokesh
-----Original Message-----
From: Lokesh Kabra
Sent: 09 July 2025 18:15
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: Symbol aligner in 802.3 Clause 147 PCS
Hello,
We have a query regarding a possible false-lock scenario in PCS Receive
state diagram (Figure 147-7).
In this figure, for multidrop use-case, there are 3 "out" transition from
WAIT_SYNC state depending on the symbols received
a. to SYNCING state on reception of SYNC symbol b. to BEACON1 state on
reception of BEACOM symbol c. to WAIT_SSD state on reception of SSD symbol.
However, the BEACON symbol & SSD symbol are very similar and prone to
false-lock in an aligner when consecutive symbols are received
2xBEACON symbols = 01000 01000
2xSSD symbols = 00100 00100
For example, if 1st bit of actual BEACON reception (LSB "0") is lost/missed
(which is practically possible with OA/TC14 3-pin PMD transceiver
interface), then the subsequent pattern becomes equivalent to 2xSSD symbols.
Hence the aligner in PMA can falsely lock to SSD instead of BEACON & thus
the PCS state machine can falsely transition to WAIT_SSD instead of BEACON1
state & results in a loss of BEACON.
My query : Considering that PCS TX always transmits at least 2 SYNC/COMMIT
symbols before an SSD, should the PCS RX directly check for SSD symbol in
WAIT_SYNC state. If we remove the transition of WAIT-SYNC to WAIT_SSD, then
this false lock will not occur as it will first transition to SYNCING state
on reception of SYNC symbol before moving to WAIT_SSD.
Any comments on this resolution/ambiguity are appreciated.
Thanks,
Lokesh Kabra
________________________________________________________________________
To unsubscribe from the STDS-802-3-SPMD list, click the following link:
https://urldefense.com/v3/__https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS
-802-3-SPMD&A=1__;!!A4F2R9G_pg!ZHioJBcPaM_TwKoPEocQWoT7TwEBKzY4hKFYSzjFlp-fg
I6DbOycDstZMIKWkqYTEbwppoAYHkWKt5-WgDblrlBWt6AK$
________________________________________________________________________
To unsubscribe from the STDS-802-3-SPMD list, click the following link:
https://urldefense.com/v3/__https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS
-802-3-SPMD&A=1__;!!A4F2R9G_pg!ZHioJBcPaM_TwKoPEocQWoT7TwEBKzY4hKFYSzjFlp-fg
I6DbOycDstZMIKWkqYTEbwppoAYHkWKt5-WgDblrlBWt6AK$
________________________________________________________________________
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