| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
George, Just trying to reach Piergiorgio directly to be able to answer the 1st one. The answer to the 2nd one is a yes, as far as I am concerned. Let me get back to you shortly. Yours sincerely Gergely From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> Guys - the state diagrams will probably come up this afternoon (after 1pm I am guessing). They’re the most critical technical thing we have to do. Could we try to have a unified
consensus proposal by then? ALso, can you confirm (asap) that figure 148-4 is the only one we are still trying to figure out the right change? Get
Outlook for iOS From: Huszak Gergely <Gergely.Huszak@xxxxxxxx> 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>
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>
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>
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>
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" 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 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 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 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 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 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 |