Re: [802.3_10SPE] Comment r02-33

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

Hello Tim,

And thank you for jumping in. Based on all your replies, allow me please then consolidate 12, 13 and 14, as follows:

[12] Change the condition on the open-ended transition to NORMAL of “Figure 148–4—PLCA Data state diagram” from “plca_reset + (!plca_en) * (!plca_status)” to “plca_reset + (!plca_en) + (plca_status ≠ OK)”.

[13] Change the condition on the NORMAL->IDLE transition of “Figure 148–4—PLCA Data state diagram” from “plca_en * (!plca_reset) * plca_status” to “plca_en * (!plca_reset) * (plca_status = OK)”.

[14] Remove the NORMAL->NORMAL transition of “Figure 148–4—PLCA Data state diagram” with “ELSE” on it.

Yours sincerely

Gergely

From: Tim Baggett <Tim.Baggett@xxxxxxxxxxxxx>
Sent: Wednesday, August 14, 2019 6:21 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Comment r02-33

Hello Gergely, David,

I was just reading your suggested changes to the PLCA Data state diagram and had the following thoughts:

[12] I believe the open-ended transition to NORMAL should be change to:

plca_reset + (!plca_en) + (plca_status = FAIL)

I understand the intention for the NORMAL state is to “pass through” the MII signals to the PCS when “PLCA is disabled OR PLCA is held in reset OR there is no PLCA coordinator transmitting a periodic BEACON causing plca_status to be set to FAIL”. If any one of these condition terms are true such that PLCA cannot operate, immediately jump into NORMAL.

[13] I agree that the exit transition from NORMAL to IDLE should change to:

plca_en * (!plca_reset) * (plca_status = OK)

We want to exit NORMAL when “PLCA is enabled AND PLCA is NOT in reset AND a periodic BEACON is being received causing plca_status to be set to OK”. Only exit when all of these condition terms for PLCA operation are TRUE.

[14] David, thanks for educating us on the open arrow transition always executing. I knew it would take precedence over any other transition, but it wasn’t clear to me that it would always cause the actions within the NORMAL state to continuously be performed.

However it is documented, we need to continuously perform the actions within the NORMAL state until all terms of the exit condition allowing PLCA to operate are true. At this point we transition to IDLE. The exit from NORMAL may be mutually exclusive from the entry into NORMAL, but it is possible for only one term to become true, but not all three: (plca_en==TRUE, plca not reset, plca_status=OK). In this case we have to continue processing the actions within NORMAL and either need the ELSE circulator transition or the understanding as David provided.

Regards,

Tim

From: Huszak Gergely <Gergely.Huszak@xxxxxxxx>
Sent: Tuesday, August 13, 2019 2:48 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Comment r02-33

External E-Mail

Hello Piergiorgio,

Thank you very much for your kind words.

I have been trying to reach you but to get these checked before mailing in the consolidated output to the reflector, but I failed to get through and the meeting is upon us, thus I decided to go ahead with the submission, then let the group on the floor respond these: please my proposed changes below in bold red

Finally, only, I also updated figure 148_4.pptx (attached) with what is being proposed and one more correction, as what is described under [3] was not correctly reflected by figure 148_4.pptx (“TX_ER <=” and “TXD <=” were missing from the .pptx file). Should still any differences still exist, the test shall prevail.

Yours sincerely

Gergely

From: Piergiorgio Beruto <piergiorgio.beruto@xxxxxxxxxxxxxx>
Sent: Monday, August 12, 2019 3:25 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] Comment r02-33

Hello again,

First, I would like to thank all the people that worked and are still working offline to check and validate this issue, including (but not limited to) Gergely and Mr. Yong Kim.

After collecting some more feedback, I wish to post the latest resolution that I am going to propose in Milwaukee.

This one also better clarifies how to synchronize the internal variables with the MII transmit clock. Besides, it fixes a couple of editorial issues.

Kind Regards,

Piergiorgio

----- FULL TEXT OF THE PROPOSED RESOLUTION -----

PROPOSED ACCEPT IN PRINCIPLE.

[1] In Figure 148-4, in the HOLD state, replace "

TX_ER <= plca_txer

TXD <= 0000

with "

TX_ER <= ENCODE_TXER(tx_cmd_sync)

TXD <= ENCODE_TXD(tx_cmd_sync)

[2] In Figure 148-4, in the ABORT state, replace "

TX_ER <= plca_txer

TXD <= 0000

with "

TX_ER <= ENCODE_TXER(tx_cmd_sync)

TXD <= ENCODE_TXD(tx_cmd_sync)

[3] In Figure 148-4, in both the COLLIDE and DELAY_PENDING states add the following: "

TX_ER <= ENCODE_TXER(tx_cmd_sync)

TXD <= ENCODE_TXD(tx_cmd_sync)

[4] In Figure 148-4, add a recirculating arc with an "ELSE" condition to the following state boxes: WAIT_MAC, PENDING, DELAY_PENDING, COLLIDE and ABORT.

[5] In Figure 148-4, in the transition from WAIT_MAC to TRANSMIT state, change the condition from "plca_txen" to "MCD * plca_txen"

[6] At page 242, line 44, change the duration of the beacon_timer from "20 bit times" to "22 bit times".

[RATIONALE] this is required so that the BEACON duration is guaranteed to be always the same (20 bit times) despite the timer tolerance vs the MII TX_CLK tolerance which drives the PLCA DATA State Diagram.

[7] At page 248, line 8 remove the duplicate MCD declaration (the correct definition is at line 50 in the Abbreviations section).

[8] At page 248, line 34 change "A continuous free-running timer that shall expire synchronously with the falling edge of TX_TCLK."

with "A continuous free-running timer that shall expire synchronously with the falling edge of the MII TX_CLK"

[9] Add the following variable definition in 148.4.6.2: "

tx_cmd_sync

The value of the tx_cmd variable sampled on the rising edge of the MII TX_CLK.

Values: see tx_cmd in 148.4.5.2"

[10] In Figure 148-4, replace all occurrances of "ENCODE_TXD(tx_cmd)" with "ENCODE_TXD(tx_cmd_sync)"

[11] In Figure 148-4, replace all occurrances of "ENCODE_TXER(tx_cmd)" with "ENCODE_TXER(tx_cmd_sync)"

[12] Change the condition on the open-ended transition to NORMAL of “Figure 148–4—PLCA Data state diagram” from “plca_reset + (!plca_en) * (!plca_status)” to “plca_status != OK”.

If the proposed change is not correct, craft one that handles the following possible problems:

- Add the necessary parentheses to eliminate the order of evaluation- and precedence-related ambiguities in the original condition

- Handle the fact that plca_status is not Boolean, but an enum with the allowed values of OK and FAIL

- Check whether the condition between “(!plca_en)” and “(!plca_status)” should indeed be an AND instead of an OR.

RATIONALE: the proposed resolution handles all 3 problems, by relying on the variable plca_status generated by PLCA_STATUS, which is set to FAIL (!= OK) under the exact same conditions NORMAL should be entered

[13] Change the condition on the NORMAL->IDLE transition of “Figure 148–4—PLCA Data state diagram” from “plca_en * (!plca_reset) * plca_status” to “plca_status = OK”.

If the proposed change is not correct, craft one that handles the problem that plca_status is not Boolean, but an enum with the allowed values of OK and FAIL

RATIONALE: the proposed resolution I indeed a disambiguation and also relies on the variable plca_status generated by PLCA_STATUS, which is set to OK under the exact same conditions NORMAL should be left

[14] Remove the NORMAL->NORMAL transition of “Figure 148–4—PLCA Data state diagram” with “ELSE” on it.

If the proposed change is not correct, craft one that handles the problem that when PLCA_DATA is not supposed to run, it must transparently and continuously reflect TXD, TX_EN and TX_ER, while it is not clear whether e.g. a plca_en being continuously asserted would have this effect

RATIONALE: The open-ended entry condition to NORMAL (A) and the condition on NORMAL->IDLE (B) are each other’s complement, in other words “if (A) {} else {//B} covers the complete variable-space, so the “ELSE” is equivalent to - therefore ambiguous with - B, which should be resolved

-----------

From: Piergiorgio Beruto <piergiorgio.beruto@xxxxxxxxxxxxxx>
Sent: Friday, August 9, 2019 11:01 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] Comment r02-33

Hello 802.3cg,

Thanks to some of you working offline, we’ve found a regression in the PLCA DATA State Diagram caused by comment i-373 on D3.0.

The intention of i-373 resolution was to clarify the behaviour of the State Diagram without changing the functionality.

In the process, despite our best effort, we’ve missed some important changes that broke the DATA State Diagram function.

Please find attached to this e-mail the proposed changes meant to accomplish the original intention of i-373.

Any feedback would be much appreciated.

Kind Regards,

Piergiorgio Beruto

Senior System Designer

Canova Tech Srl.

"The Art of Silicon Sculpting"

www.canovatech.com

Via Magliotto 2,

Campus Savona, Palazzina Branca

17100 Savona (SV), Italy

Phone: +39 049 7811065 ext. 265

GSM: +39 333 6333289

Skype: canovatech_pb

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