IEEE P802.3z. Task Force. Comments and Responses on Clauses 36 and 37 (PCS, PMA, LC) of 802.3z Draft 1

Transcription

1 IEEE P802.3z Task Force Comments and Responses on Clauses 36 and 37 (PCS, PMA, LC) of 802.3z Draft 1 Prepared by: Rich Taborek, Amdahl revision date March 6, 1997

2 PCS/PMA/LC Comment Resolution Comments received on 802.3zD1 clauses 36 and 37 are separated into three categories for resolution. All comments received during 802.3z and related meetings, via , phon , etc. are all acceptable. However, comments sent in by to the 802.3z reflector are preferred. The three categories are as follows: I = Issue: Major technical problems the resolution of which probably requires committee decision. T = Technical: Technical errors where it is believed that there is full agreement as to the function in question. E = Editorial: Errors of expression where the technical meaning is clear. In several instances, original comments containing more than a single issue have been divided into two or more comments to allow separate responses to those issues (e.g.accepted, rejected, etc. responses to multiple issues contained in a single original comment. Comments and associated responses are further grouped into PCS, PMA, and LC sections and consecutively numbered in each section. Comments in each section are numbered according to the date received zD1 PCS Comments and Responses 1. (E) Direction of TX_CLK Source/Date: Devendra Tripathi, XaQti, 1/16/97 The direction of TX_CLK is not same in figure 36-8 and I assume it should be like shown in If the intention in 36-7 is to show the inputs available to PCS (one of which is TX_CLK) it may be better to show the TX_CLK coming from some third source and going to both GMII and PCS. Please clarify on this. Response: Accepted: PCS is clocked by GTX_CLK from the GMII. Following the conventions in figure 35.2, The direction of GTX_CLK is from the GMII to the PCS. Figure 36-8 (36-2 in D2) is corrected. Only GTX_CLK is specified in clause 36. TX_CLK is not discussed in clause 36. D1 figure 36-7 is deleted and not included in D2. 2. (T) cycle meaning Source/Date: Devendra Tripathi, XaQti, 1/16/97 Please clarify on the word cycle. I could not get it in variable or constant section. Response: Accepted: Replaced cycle with GTX_CLK period. I assume that this comment does not apply to the usage of the word cycle in the term duty cycle in the PMA section. 3. (I) VOID Source/Date: Devendra Tripathi, XaQti, 1/16/97 The explanation of VOID is really neat (thanks for limiting the duration to TX_ER valid period only). The delay part of the sentence If TX_ER is asserted following the de-assertion of TX_EN, /R/ ordered_sets are sourced for as many cycle as TX_ER is asserted with a two cycle delay to first source the EPD1 and EPD2 ordered_sets. may be simplified. It took a few readings to understand it. Just a suggestion. Page 2 of 33 March 6, 1997

3 VOID and VOID function usage cleaned. The reference sentence is also clarified. NOTE: Not corrected in D2. Corrected in D (T) Encapsulation Source/Date: Devendra Tripathi, XaQti, 1/18/97 (d)... end of a less-than-minimum size packet may be replaced by end of a less-than-slottime size packet because the minimum size of packet still remains 64 bytes only. Response: Not applicable. This text is deleted in D2. 5. (E) Encapsulation Source/Date: Devendra Tripathi, XaQti, 1/18/97 (e) The word command in this case does not look appropriate as the idle function is really PCS driven and not GMII. Instead saying like when GMII interface is idle, TX_EN and TX_ER both are inactive... or so may be better. Response: Not applicable. This text is deleted in D2. 6. (E) Mapping Source/Date: Devendra Tripathi, XaQti, 1/18/97 Line 17 PMA should be replaced by PMD. Line 22 replace PCS => PMA, PMA => PMD. 7. (E) Table 36-2 Source/Date: Devendra Tripathi, XaQti, 1/18/97 The note 1 indicating reserved should be removed from K23.7, K27.7, K29.7, K (E) Source/Date: Devendra Tripathi, XaQti, 1/18/97 On line 36 (c) I think it should be by the MAC... instead of By the PCS (T) Source/Date: Devendra Tripathi, XaQti, 1/18/97 In clause we are saying that loss_of_sync_timeout takes the link monitor to link_not_available state but it is not mentioned in the state diagram On the other hand in the state diagram config_timer_long_done is mentioned but it is not in the text. Since state diagram takes priority, I believe that loss of synchronization is no longer a criteria for link to go to fail state or the arrow going out of LINK_OK state should be labeled as loss_of_sync_timeout. The later seems to be true but please clarify on this. If indeed later is true, the arrow should go to LINK_NOT_AVAILABE state directly instead of via the other path because the other path already says ability_match = true (BTW I think it should be ability_match = false). Response: Accepted in principle. Loss_of_sync_timeout is removed per motion #6 at San Diego interim meeting. In addition, the Synchronization and Loss of Synchronization state machines are merged and the Link Monitor state machine is replaced by the Link Configuration state machine in clause 37. This comment will be re-evaluated for the new state machines. Several comments on D2 clause 37, Figure Arbitration Diagram are in order here: Page 3 of 33 March 6, 1997

4 1. (Editorial) All instances of sync_acquired = FALSE should be changed to link_status = FAIL. 2. (Technical) The variable xmit is never set to CONFIGURATION. This condition must be set to allow the PCS TX state machines to transmit /C/. I propose setting xmit = CONFIGURATION in state ABILITY DETECT. 10. (E) Source/Date: John Wolcott, Intel, 1/24/97 Item a) remove and at the end. 11. (E) Source/Date: John Wolcott, Intel, 1/24/97 Should be GMII. Changed all other similar occurrences. 12. (E) ~line 52 Source/Date: John Wolcott, Intel, 1/24/97 Missing a space after sentence 8B10B code bit assignments are illustrated in figure (E) P36.3, L44 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 The reference to Figure is incorrect, probably should be Response: Not applicable. This reference has been removed. 14. (T) P36.5, L39-49 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 Running disparity is discussed, but there are no actual rules on how it should be determined. I think the actual running disparity rule should be either here or in a state machine. Response: Rejected. 8B/10B transmission code details can be found in ANSI X , Fibre Channel Physical and Signaling Protocol (FC-PH) clause 11, and other references noted therein. Reference to FC-PH is contained in par. 3 of (T) P36.19, L26 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 There is no definition of loss_of_signal or loss_of_synchronization. What is the difference between the two? Response: Accepted in principle. Loss_of_signal (a.k.a., signal_status=fail) is not used by the PCS in D2. Loss_of_synchronization is defined in D1, and link_status is redefined to be equivalent to loss_of_synchronization when set to FAIL. 16. (E) P36.39, Figure 36-5 and P36.40, Figure 36-6 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 The MAC Control sublayer is missing from both diagrams. Figures 36-5 and 36-6 are merged into new figure The MAC Control sublayer is added to figure Page 4 of 33 March 6, 1997

5 17. (T) P Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 The state machines on these pages have a input variable called BEGIN. BEGIN is not defined anywhere, what does it mean? Response: Rejected. This convention is defined in clause (T) P36.44, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 There is a state called error_check in the middle of the state machine which seems to do nothing. Can it be eliminated? Figure is redrawn and renumbered as figure (T) P36.49, Figure and P36.50, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 The sync and loss of sync state machines are different than the Fibre Channel FC-1 state machines that were proposed in Rev. 4.1 in the White Book. I don't remember any discussions related to any changes from the Fibre Channel versions. What was the reason not to follow the Fibre Channel state machines? The Synchronization and Loss of Synchronization state machines are merged and corrected into a new Synchronization state machine in figure 36-9 which follows the Fibre Channel state machines where appropriate. 20. (T) P36.49, Figure and P36.50, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 If a device acquires sync (sitting in sync_acquired and sync_acquired1 states), but then sync is lost, it seems that the synchronization SM in Figure will be stuck in the sync_acquired state. The Synchronization and Loss of Synchronization state machines are merged and corrected into a new Synchronization state machine in figure (T) P36.28, L28-32 and L38-41 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 The description for EN_CDET and COM_DET is not the same as used in Fibre Channel. I propose that we specify these two signals that same way that they are used in Fibre Channel so that the PCS block will work with existing SerDes chips. Response: Accepted in principle. Both EN_CDET and COM_DET are optional and not required for proper PMA and PCS operation. 22. (T) P36.28, L1-41 Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 There is no mapping between the 10-Bit interface signals specified here and the variable in the state machines in Figures through Specifically, EN_CDET and COM_DET should appear in the sync state machines, and it would be useful to refer to the other signals as well. Response: Rejected. Both EN_CDET and COM_DET are defined as optional and not required for proper PMA and PCS operation. As optional signals, they are not included in clause 36 state machines. 23. (T) P36.49, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 Page 5 of 33 March 6, 1997

6 It would be more robust to require the detection of K28.5 characters instead of just the comma character. There are some comma characters that are not used, and the PCS would gain sync if it detected these undefined characters, which is undesirable. Response: Rejected. Prior reflector discussion and input from PMA component vendors indicated that synchronizing on commas was more desirable than all other options. D1 reflects this desire. 24. (T) P36.49, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 It would be more robust to require the detection of one of the defined ordered sets to exit the comma_detect states rather than just detect any data character. There are some data characters that are not used, and the PCS would try to gain sync if it detected these undefined characters, which is undesirable. Also, the state machine in Figure needs three good code_groups, so the two synchronization state machines now are using different criteria to try to gain sync. Response: Rejected. For reasons of implementation simplicity it is sufficient to acquire sync by detecting a stream of commas interspersed with valid data code_groups. If sync is acquired, and the link is not reliable, the link will quickly lose sync. Additional robustness to acquire sync is deemed unnecessarily complex. 25. (T) P36.49, Figure and P36.50, Figure Source/Date: Steve Dreyer, Seeq Technology, 1/23/97 These two state machines are intimately tied together. It was difficult to go back and forth between the two. Wouldn't it be a lot easier to comprehend if the two state machines were combined into one? The Synchronization and Loss of Synchronization state machines are merged into a new Synchronization state machine in figure (I) GMII Management Functional Requirements (35.2.4) What controls and status information requirements exist for the GMII management interface? The possibilities include: a) RESET b) LOOPBACK c) POWER DOWN d) OFFLINE e) TX_DISABLE f) ISOLATE g) COLLISION TEST h) FAULT i) SIGNAL DETECT Response: Open. Deferred to D (I) LOSS_OF_SYNC vs. LOSS_OF_SYNC_TIMEOUT ( ) Should the PCS start Link_Configuration after LOSS_OF_SYNC or only after LOSS_OF_SYNC_TIMEOUT? Fibre Channel and SBCON both enter the Link_Failure state only after LOSS_OF_SYNC_TIMEOUT. Is LOSS_OF_SYNC_TIMEOUT necessary? Response: Resolved. Loss_of_sync_timeout is removed per motion #6 at San Diego interim meeting. D2 specifies that the PCS starts start Link_Configuration after loss of synchronization. 28. (I) Undefined Ordered_Sets Rules ( ) Page 6 of 33 March 6, 1997

7 Currently, the reception of an ordered_set which is not defined is treated as the reception of an IDLE ordered_set to prevent unnecessary errors during IDLE and to allow interoperable future expansion of the list of defined ordered_sets? Should these rules be changed? Response: Accepted: Defined ordered_sets and ordered_sets consisting of two code_groups and with K28.5 followed by a Dx.y code group will not result in False Carrier and will be treated as idles. From a management perspective, link errors consisting of code_violations and all PCS protocol errors such as unrecognized ordered sets should be counted. Not changed in D2. Corrected in D (I) Valid Special Code_Group Table (Table 36-2) Currently, table 36-2 lists all 12 special code_groups defined in the 8B/10B transmission code. Only 5 of 12 are currently used. Should the remaining 7 be deleted? Response: Rejected. Leave table as is for reference purposes. 30. (E) Delete Fibre Channel from...fibre Channel PMD sublayer... in par (E) Delete CSMA/CD from...the CSMA/CD MAC. in par (E) f) Change 2000m to 3km. 33. (T) Add text to describe the effects of reset actions on transmission order. Response: Open. Deferred to D (T) Fig 36-11, Transmit ordered_set state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Should the two states called EPD2 be called something like EPD2_NOEXT and EPD2_EXT? 35. (T) Fig 36-11, Transmit ordered_set state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Assuming we choose the names given above in #34, shouldn't the transition from END_OF_PACKET_EXT when TX_EN=FALSE and TX_ER=FALSE go to EPD2_NOEXT, rather than EPD3? Response: Accepted in principle. This transition occurs through state EXTEND_BY_1. Page 7 of 33 March 6, 1997

8 36. (T) Fig 36-11, Transmit ordered_set state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Why does the variable transmitting go to false during carrier extension? If it really should go false, how can a collision ever occur? 37. (T) Fig 36-11, Transmit ordered_set state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Since TX_EN and TX_ER are constantly checked in the TRANSMIT_DATA state, among others, what is the purpose of the VOID(x) function in these states? Usage of the VOID(x) function is corrected for all states. Not changed in D2. Corrected in D (T) Fig 36-11, Transmit ordered_set state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 It appears the way this code is written that if there existed two packets on the GMII, Packet #1 with X bytes followed by 0 bytes of carrier extension and Packet #2 with X bytes followed by 1 or 2 bytes of carrier extension, these packets would look exactly the same to the PMA. Is this the way it should actually work? The PCS should reflect exactly the number of bytes requested by the MAC and GMII to the PMA. The problem of not transmitting the proper number of bytes is corrected in the state machine. 39. (T) Fig 36-12, Transmit code_group state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Can you explain the significance of the names of these two states: NOT_FIRST_IDLE and FIRST_IDLE_DISPARITY_OK? Response: The NOT_FIRST_IDLE is extraneous and is deleted. The original purpose was intended to allow the usage of the VOID(X) function for K28.5 which is not the first. The implementation was not correct and the original purpose is not useful. Associated changes include the elimination of the VOID(X) function in states IDLE_I1B and IDLE_I2B. Not corrected in D2. Corrected in D (T) Fig 36-12, Transmit code_group state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Should the message sento_set.indicate ever be delivered when the next state is not GENERATE_CODE_GROUPS? This message should be telling the Transmit ordered_set process that it is ready to send another ordered set of the type desired by that process. There are two states where this is not the case: CONFIGURATION_C1D and IDLE_I1B. In case of CONFIGURATION, after the message sento_set.indicate is sent for C1, the variable tx_o_set is checked for CONFIGURATION or NOT CONFIGURATION. This constitutes an implicit signal to alternate C1 and C2. In case of IDLE, the variable disparity is used to determine whether I1 or I2 should be issued and the state machine will be corrected to return to GENERATE_CODE_GROUPS after I1 or I2 is transmitted. NOTE: Not corrected in D2. Corrected in D (I) Fig 36-15, Receive code_group state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 On a packet with a corrupted SPD, it appears that you loop between the states: IDLE, CARRIER_DETECT and FALSE CARRIER for the entire packet or burst of packets, sending numerous False Carrier followed by Normal InterFrame indications across the GMII, rather than one long, continuous False Carrier indication. Is this the desired result of a corrupted SPD? Does it really matter to the MAC? Are these things counted in a MIB? Page 8 of 33 March 6, 1997

9 The operation described is accurate. Alternatively, once FALSE CARRIER is detected, the Receive process could indicate FALSE CARRIER until IDLE is detected. Fixed in D (T) Fig 36-19, Loss of Synchronization state diagram Source/Date: Benjamin Brown, Cabletron Systems, 2/5/97 Does it take 9 code_groups, with at least 1 invalid symbol for each set of three code_groups, to transition from SYNC_ACQUIRED2 to LOSS_OF_SYNC or does it require only 3 code_groups? Do you sit in each of these states for exactly 3 code_groups before deciding to move on or do you shift the new code_group into the 3_good_cgs function and get a new result? The Synchronization state machine is redrawn in D2 per PCS comment # (T) Fig 36-15, RX-code_group FSM Source/Date: Marc Bell, Madge Networks, 2/7/96 Why does the rx-code_group state-diagram use the even signal in its decision making process? The even signal is generated with the tx-machine and as such appears to have nothing to do with the rx-machine if you are implementing a full-duplex link. Should the even signal be generated within the rx-machine for this situation? The even flag is renamed as tx_even and an rx_even flag is added. Setting of the flags is performed by the appropriate state machines. Not corrected in D2. Corrected in D (T) Fig 36-19, Loss-of-Synch FSM Source/Date: Marc Bell, Madge Networks, 2/7/96 The definition of the 3_good_cgs function is ambiguous. 3_good_cgs In the Link Monitor process, this function determines whether any code violations are detected in the next three consecutive code_groups received. Values: TRUE; no code violations are detected FALSE; one or more code violations are detected This implies buffering the code_groups and making decisions on 3 code_group boundaries. If this the case then the function appears to indicate if one or more code_groups are invalid then to flag the function. This implies an OR function which renders the buffering pointless as all you are then doing is checking the code_groups one-by-one. Response: Rejected in principle. The function described is similar to that used by Fibre Channel. However, Fibre Channel makes these decisions on 3 code_group boundaries. The latter inconsistency is corrected. The implementation of the function is not suggested by this standard. 45. (E) Add references to clause 39 in addition to clause (E) Signal ordered_sets Delete this section which includes extraneous nomenclature. 47. (T) Table 36-2 For code_group K23.7, either the value specified in the Special Octet Value or Special Octet Bits column is incorrect. The Special Octet Bits value is corrected. Page 9 of 33 March 6, 1997

10 48. (E) Reword to eliminate usage of the term defined in defined ordered_set. 49. (E) Table 36-3 Add a row above /C1/ defining /C/ as alternating /C1/ and /C2/. Add a row above /I1/ defining /I/ and usage per (E) In par. 3, running disparity is defined...for a constant Config_Reg value. 51. (E) Delete extraneous nomenclature function for this and other ordered_sets. 52. (T) Source/Date: Steve Haddock, Extreme Networks, Interim Meeting, PCS Track comment, 1/27-28/97 Carrier_Extend rules are incorrect. Replacement text provided by Steve Haddock, Extreme Networks. 53. (E) In par. 2, in addition to the RX_ER signal, the RXD value...indicates the reception of an invalid code_group (E) TX_CLK should be GTX_CLK (global change). PMA signal should be inserted prior to RX_CLK. Response: Accepted: Global GTX_CLK change is made. Not corrected completely in D2. Corrected in D (E) The VOID(x) function needs a separate definition for DATA. 56. (T) Page 10 of 33 March 6, 1997

11 Does link_control affect the receiver? Response: The variable link_control is deleted. 57. (E) All occurrences of the term stream need to be examined. A better term in most instances may be MAC Frame. Response: Qualified all occurrences of the term stream to prevent ambiguity (e.g., PHY bit stream, code_group stream, etc.). 58. (E) Tables 36-9, Change Min and Max values and heading from (bytes) to (octet time). New direction from Steve Haddock via on 2/17 is to use the unit bit time. This new direction is accepted. Fixed in D2 tables 36-9 and (E) Figures 36-5 and 36-6 MAC Control is missing. Fixed in D2 figure (E) Figures 36-5 and 36-6 Figures may be redundant and may need to be combined. Fixed in D2 figure (E) Figure 36-5 Shading is incorrect. Fixed in D2 figure (E) MII Fix all instances of MII that should refer to GMII. 63. (E) Figure 36-8 The direction of the arrow for TX_CLK is incorrect. Fixed in D2 figure (E) Figure 36-8 Should Synchronization be included in the Link Monitor block? Response: Rejected in principle. Synchronization is part of the Link Monitor process and is described as such in the text of Link Monitor. Adding all the components of Link Monitor to figure 36-8 would make it too Page 11 of 33 March 6, 1997

12 busy. 65. (E) Figure 36-8 MAC control should be shown in this figure. Response: Conditionally accepted. However, this would clutter up this figure. A new figure is needed to illustrate MAC control signals. Such a figure will be graciously accepted by the editor. If a figure is not provided, this comment is rejected. 66. (T) Figure 36-9 Suggest adding timing references for delay constraints to this or a separate figure. Response: Conditionally accepted. However, this would clutter up this figure. A new figure is needed to illustrate MAC control signals. Such a figure will be graciously accepted by the editor. If a figure is not provided, this comment is rejected. 67. (E) Figure The bit ordering for the properly aligned comma+ symbol is reversed. 68. (T) Figure In blocks END_OF_PACKET_EXT and EPD2, transmitting should be set to TRUE. The variable transmitting is changed to TRUE in blocks END_OF_PACKET_EXT and CARRIER_EXREND (block renamed from EPD2 ). 69. (T) Figure The Transmit ordered_set state machine does not handle extra Carrier_Extend codes from the GMII properly (those issued by the GMII when the PCS is sending EPD1 and EPD2). Corrected by adding state EXTEND_BY_1 when TX_ER=FALSE and sento_set.indicate as output of END_OF_PACKET_EXT state. 70. (T) Figure In block TRI+RRI, the term receiving FALSE should be added. 71. (T) Figure The terms RX_DV = FALSE * RX_ER = FALSE should be changed to receiving = FALSE. 72. (E) Not Equal Symbol in state diagrams Page 12 of 33 March 6, 1997

13 The Not Equal symbol is not printing properly on all platforms. Check font usage. All occurrences of Not Equal in state diagrams are in Helvetica font, same as the text font used in the state diagrams. Only Times, Helvetica, and Symbol fonts are used in clauses 36 and (T) Figure Should the ACQUIRE_SYNC_1 and _2 block outputs from the bottom right go to the LOSS_OF_SYNC block? Response: Rejected in principle. These outputs are changed to include the rx_code_group INVALID term. The purpose of these paths is to wait for the next COMMA. It is OK to receive one or more valid DATA code_groups during this time. 74. (T) Figure Where should the SYNC_ACQUIRED block output go to? The Synchronization and Loss of Synchronization state machines are merged into a new Synchronization state machine (D2 figure 36-9). The SYNC_ACQUIRED state of the old Synchronization state machine essentially becomes the SYNC_ACQUIRED_1 state of the new Synchronization state machine. 75. (T) Figure Should the term rx_code_group COMMA instead be rx_code_group COMMA for inputs to blocks ACQUIRE_SYNC_1 and _2 and LOSS_OF_SYNC from the right? Response: Rejected. These outputs are changed to include the rx_code_group INVALID term. The purpose of these paths is to wait for the next COMMA. It is OK to receive one or more valid DATA code_groups during this time. In the LOSS_OF_SYNC block, the only output is the detection of a COMMA. 76. (T) Figures and Should the Synchronization and Loss of Synchronization state machines be combined? 77. (T) Figure Clarification of signal_status and signal_detect is required. Track III decided that SIGNAL_DETECT will be optional and the polarity will not be specified. This was decided at the 1/97 San Diego Interim meeting. As such, signal_detect (a.k.a. signal_status ) is no longer used by the PCS.The variables signal_status and sync_acquired are deleted and the variable link_status is redefined to be equivalent to synchronization acquired (i.e., link_status = FAIL is equivalent to loss of sync) 78. Comment moved to PMA section as comment # (E) 36.1 L33 Replace 1000BASE-T with 1000 Mb/s Page 13 of 33 March 6, 1997

14 80. (E) 36.1 L40 Insert balanced before cabling 81. (E) 36.1 L48-49 Delete other 1000BASE-T sublayers, 82. (E) 36.1 L49 Insert and reconciliation layer, after MAC. 83. (E) 36.1 L53-54 Delete that are embodied in the 1000BASE-X Physical sublayer (PHY). Place asterisk after sublayers. 84. (E) 36.2 L3 Replace That with which. Note: not indicated in blue in D (E) 36.2 L4 Replace 1000BASE-T with 1000Mb/s. 86. (E) 36.2 L31 Missing reference (38.2). The reference requirements are broader (e.g., copper 150-ohm balanced cabling, etc.). The reference is changed to include clauses 38 and (E) 36.2 L33 Replace the PMD with each PMD subclause, defines ; delete provides. 88. (E) 36.2 L44 Missing reference. Page 14 of 33 March 6, 1997

15 Response: Accepted in principle. This TR has passed letter ballot and is in the hands of the X3 secretariat. The reference is as complete as possible at this time. 89. (E) 36.2 L50, 36.3 L1 Insert at an observable interconnection port after implemented. 90. (E) 36.3 L29 Title should be Functions Within the PCS. 91. (E) 36.3 L32-34 Delete sentence starting with In addition, the Transmit (E) 36.3 L43-44 Delete these lines. 93. (T) 36.3 L48 No shall statement required with COL. Response: Rejected. No shall statement is present here. 94. (T) 36.4 L4 No shall statement required. Response: Rejected. No shall statement is present here. 95. (E) 36.4 L10 Title should be Use of code_groups. 96. (E) 36.4 L8 Insert It shall set ability, match, etc...as in at end of paragraph. Response: Accepted in principle. Shall is not used in this subclause. 97. (E) 36.4 L15 Page 15 of 33 March 6, 1997

16 Replace undetectable with unobservable. 98. (E) 36.4 L16 Insert The PCS functions ENCODE and DECODE shall generate, manipulate, and interpret code_groups as provided by the rules in at end of paragraph. 99. (E) 36.4 L20 Replace A transmission code is used with The PCS uses a transmission code (T) 36.4 L29-35 Delete this paragraph (T) 36.4 L53-55 Delete all after convention: Replace with Dx.y for the 256 valid data code_groups, and Kx.y for special control code_groups (T) 36.5 L1-3 Delete this paragraph (continuation of previous) (T) 36.5 L7-10 Delete this paragraph (E) 36.5 L16 Replace shall be with are (E) 36.5 L21 Replace an multi-ordered_set_group shall be with every multi-code_group_ordered_set must. Response: Accepted in principle. is is substituted for must. Page 16 of 33 March 6, 1997

17 106. (E) 36.5 L22 Insert counting from the first ENCODED code_group after my reset or power-on after position Delete Sentence beginning with Subsequent.... Response: Partially accepted. my reset replaced with a reset. The sentence beginning with Subsequent... is not deleted as it is necessary to completely specify code_group transmission. For example, if not stated, no requirement to transmit in an odd-numbered code_group position exists (E) 36.6 L22 Insert Nine before Ordered. Response: Accepted in principle. I count only eight (E) 36.6 L22 Delete single special code_group or combinations of special and data code groups Replace with one or more code_groups. Response: Rejected. This would allow single or multiple data code_groups to be defined as ordered_sets. How then would ordered_sets be distinguished from frame data? 109. (T) 36.6 L23 Replace special code_groups containing a comma with K (E) 36.6 L31-55 Delete this section (T) L43-49 Delete this section (T) L1-8 Delete this section 113. (E) L22-42 Add column: Header: Number of code_groups Row1: 4 ; R2: 4 ; R3: 2 ; R4: 2 ; R5: 1 R6: 1 ; R7: 1 ; R8: 1. Add Row: /I/ ; /I/I or /2/ as needed [Code groups column = 2 ]; Add Row: /C/ +/ C1/ and /C2/ alternates. Page 17 of 33 March 6, 1997

18 114. (E) L17 Delete sequence (E) L18 Replace The Link_configuration sequence with Continuous repetition of the ordered sets /C1 and /C2/ (E) L20 Missing reference (T) L22-25 Delete this paragraph (T) L26 Delete 1st sentence. Response: Partially accepted. A reference to the table defining /C1/ and /C2/ is required (T) L31 Delete code_group (T) L40; L25; and L1 Delete function (E) L42 Replace function with ordered set. Insert continuously and repetitively after is (E) L43, L44 Delete the and function. Page 18 of 33 March 6, 1997

19 123. (E) L7, L20, L45, 48, 52 Replace shall be with is. Note: Changes to D were inadvertently left out of D2, new subclause (E) L21 Replace group string with groups (E) L6 Missing reference (T) L15 Insert description of /DV/; use it to eliminate VOID function in state diagrams. Move the generic overview to , change the existing to Response: Rejected, VOID(x) function retained and usage corrected. Remainder of deleted and salient points moved into the corresponding subclauses of (E) L41; L46 Replace Set by the to Indicates to the ; Replace To Indicate with that. These variables are moved to clause 37 and modified as suggested by the comment (E) L41 If it is set, where is the shall? These variables are moved to clause 37 and properly defined there (E) L4 Replace Set by the link monitor process upon detection with Indicates to the Link Monitor process the reception. The variable config_match is moved to clause 37, renamed to consistency_match, and properly defined there (E) L35 Replace DATA with data. Response: Rejected. DATA is one of three possible values of the xmit flag. Page 19 of 33 March 6, 1997

20 131. (E) L45 It shall get COL. Response: Rejected. Can t locate the source anywhere near the noted occurrence (E) L51 Replace Transmit Bits process with PMA (T) L1-7 Delete this section (E) L10 Delete the first sentence of this paragraph (The Receive...) (T) L11 Delete and (T) L14-19 Delete this section (T) L24 Add from the PMA after group ; Delete the final sentence (The setting...) (E) L27 Change title to State Machine function carrier_detect (x) (E) L26 Replace providing reliable data with ready for operation. These variables are moved to clause 37 and properly defined there. Page 20 of 33 March 6, 1997

21 140. (E) L39 Delete???REF???. These variables are moved to clause 37 and properly defined there (T) L51 Why not just restart the configuration process? Response: Accepted in principle. The Link Configuration process is invoked upon loss of synchronization. However, there is hysteresis built into the Synchronization state machine to insure that synchronization is not lost upon the detection of single bit errors (E) L24 Add clause 38 after LONG WAVELENGTH: and SHORT WAVELENGTH. Corrected in D2 figure (E) L25 Add clause 39 after COPPER CABLING. Corrected in D2 figure (E) L13 Transmit block in PCS section should be called Transmit ordered_set Response: Rejected. Transmit ordered_set and code_group are integral parts of the Transmit process. Separation into the two state machines is done primarily to editorially partition the description of the function (E) L15 Transmit code_group block in PCS section needs to be inserted below the Transmit ordered-set block. Response: Rejected. Transmit ordered_set and code_group are integral parts of the Transmit process. Separation into the two state machines is done primarily to editorially partition the description of the function (E) L13 Receive block in PCS section should be called Receive code_group. Response: Rejected. The PCS Receive process simply processes code_groups (E) L35 Replace hgfedcba in ALL CAPS. Page 21 of 33 March 6, 1997

22 148. (T) L22 The terms for exit from the CONFIGURATION_C1D block are incorrect. They should read:sentcode_group.indicate AND (tx_o_set EQUAL CONFIGURATION)sentCode_Group.indicate AND (tx_o_set NOTEQUAL CONFIGURATION) (T) L1-24 Delete Fig and Did we adequately explain in and without these diagrams? The explanations are sufficient (T) Preamble replacement Source/Date: Rich Taborek, Amdahl, 2/16/97 Preamble replacement is not specified in the transmit state machines or text. Not corrected in D2. Corrected in D (E) Figures 36-7 and 36-8 Source/Date: Rich Taborek, Amdahl, 2/17/97 Figures 36-7 and 36-8 are redundant. Response: Figure 36-7 is deleted (T) Figure 36-8 Source/Date: Rich Taborek, Amdahl, 2/17/97 Figure 36-8 does not properly show the relationship of the Link Monitor process since Link Monitor performs synchronization and code_group transmission. In addition, signal_status is no longer used as an input. Response: The LINK MONITOR block is moved directly in the path between the PMA RECEIVE output and the PCS RECEIVE input. Signal_status is deleted from the figure. The figure is renumbered as D2 figure (T) Even variable Source/Date: Thomas Dineen, LSI Logic, 2/25/97 Page of lines 23 through 27 defines the even variable. A boolean set by the transmit process... Interpreted by the PMA receive process. The even variable is assigned and used in state transition terms in figure Transmit code_group state diagram on page The even variable is used in figure Receive code_group state diagram in state transition terms on page Do you mean for the same even variable to be used by both processes? I would assume that you mean to have a separate state variable for both the transmit and receive processes. I believe that this is required logically because the transmit and receive processes are logically separate. Or do you mean to have then this closely coupled? Separation should also be required because they are in different clock zones. I assume Interpreted by the PMA receive process means the receiving PMA at the other end of the link. If the variables are separated to transmit and receive where will the receive variable be initialized and controller? Presently the even variable is not assigned in figure Not corrected in D2. Corrected in D2+. Page 22 of 33 March 6, 1997

23 154. (T) Table 36.3 Source/Date: Ted Tsai, Netcom Systems, 2/24/97 Clarify running disparity for /C/ Clarified in D2 table 36-3 notes 1 and 3. Page 23 of 33 March 6, 1997

24 802.3zD1 PMA Comments and Responses 1. (T) EN_CDET Source/Date: Steve Dreyer, Seeq Technology, 1/15/97 Does the PMA assert COM_DET only during the interval when its EN_CDET input is asserted? Response: Answer: The PMA COM_DET signal is optional. COM_DET is asserted only when the PMA EN_CDET signal is active. Also see PMA comments #10 and # (E) Line 3 & 4 The PMA maps a nonaligned code_bit data path from the PMD to an aligned, ten-bit-wide data path to the PCS for Receive only. (NOT for both Transmit and Receive). 3. (E) Line 18 The reference clock should be 125MHz but not 1250MHz. 4. (T) Line it (the PMA) may realign its current code_group boundary.... The word may should be used instead of shall. 5. (T) Line The PMA sublayer may delete or modify up to four.... The words or modify is added. Note: This is an implementation issue and some Fibre Channel vendors are currently implementing the function by modifying instead of deleting the code_groups. 6. (T) Line 10 Does the EWRAP need a PCS_control.in type of primitive? Deferred to D2. 7. (T) Line 21 Does the EN_CDET need a PCS_control.in type of primitive? Deferred to D2. The PMA EN_CDET signal is optional. If used by the PCS, a primitive should be added to complete the semantics in the section of , Service Interface. Note: If the PMA leaves the EN_CDET signal always enabled, code_group alignment and code_group slipping may occur whenever a comma is detected in the rx_bit stream. Also see PMA comments #10 and # (T) Line 26 Page 24 of 33 March 6, 1997

25 Does the LCK_REF need a PCS_control.in type of primitive? Response: Answer: No, the PMA LCK_REF signal is optional. Note: Implementers may find it necessary to use this signal in order to meet the clock recovery requirements of the PMA sublayer. 9. (E) Line (i) A series of commas can result in having the comma on the odd code_group position. It is an unusual, but not an impossible condition. (ii) Other than K28.5, the code_group K28.1 and K28.7 also contain the comma pattern. Response: Answers: (i) This should never occur according to the text in D (Comma detect function) since code_group alignment and code_group slipping functions cause RX_CLK<0:1> to be stretched. (ii) Accepted. Defined in D (T) Line but it may not be used by the PCS. Usage of the PMA COM_DET signal is optional by the PCS. If used by the PCS, a service interface needs to be provided, and the signal may be used for synchronization and error checking. If not used by the PCS, synchronization is performed by searching for commas in rx_code_group<9:0>, and synchronization will likely be lost or bad data will be passed to the MAC as a result of an errant comma received during a packet. If not used by the PCS, the standard should say that...it is not used by the PCS. (as it was in D1). Also see PMA comment # (T) Line 40 & This signal may not be used by the PCS. The PMA sublayer may leave this function always enabled. Usage of the PMA EN_CDET signal is optional by the PCS. If used by the PCS, a service interface needs to be provided. If not used by the PCS, the standard should say that: This signal is optionally not used by the PCS. The PMA sublayer may shall leave this function always enabled. (as it was in D1). Also see PMA comment # (E) Lines Change Physical layer to PMA. 13. (T) Lines 32 Request to change the Iih of max 40uA to 500uA. Response: Withdrawn. 14. (E) Line 42 The ten TX signals [0:9], carry data from the PCS to PMA transmit device to be serialized to the PMD. This change was inadvertently left out of D Page 25 of 33 March 6, 1997

26 15. (E) Line 43 Change Physical layer to PMA. 16. (E) Line 53 Change Physical layer to PMA. 17. (E) Line 50 Change positive edge to rising edge. This change was inadvertently left out of D (E) Table 36-7 The tsetup should be 2 ns min and thold should be 1 ns min. Note 2 can be deleted. 19. (E) Line the received clocks may slow a fixed amount.... This change was inadvertently left out of D (I) There is no jittering tolerance for the REFCLK on the current draft. In the Fibre Channel, it is not specified because it is implementation dependent. In the Jitter Working Group Technical Report REV 1.0 DRAFT A, December 6, 1996 (Page 8 of 12), this issue is still left as implementation dependent. Response: Deferred to D2. Direction is to follow the recommendation of the Fibre Channel Jitter Study Group. 21. (T) Source/Date: Henriecus Koeman, Fluke Corporation, 1/23/97 General electrical characteristics suggested load is 10 pf. Would it not be better to specify the return loss of the receiver? In combination with the return loss property of the PHY, one could control jitter from this source. Response: Deferred to D2. Related to PMD/Optical Track III Motion #18, 1/97, which passed: Appoint a subcommittee to investigate, solve and bring the solution to the march meeting on characteristic impedance. Solution should include complete text ready to add to draft along with an accompanying motion. This be documented on the reflector at least two weeks prior to the meeting. 22. (T) Source/Date: Henriecus Koeman, Fluke Corporation, 1/23/97 Electrical characteristics of transmit interface Is it not appropriate to specify the return loss of the transmitter? Response: Deferred to D2. Related to PMD/Optical Track III Motion #18, 1/97, which passed: Page 26 of 33 March 6, 1997

27 Appoint a subcommittee to investigate, solve and bring the solution to the march meeting on characteristic impedance. Solution should include complete text ready to add to draft along with an accompanying motion. This be documented on the reflector at least two weeks prior to the meeting. 23. (T) 36.6 Source/Date: Henriecus Koeman, Fluke Corporation, 1/23/97 Environmental specifications Note that ISO/IEC does NOT contain an end-to-end link specification. The ISO/IEC link definition and associated requirements explicitly exclude the patch cables at each end. Either refer to TIA/EIA-568-A, which understandably is undesirable for international participants, or request from ISO/IEC JTC 1/ SC 25/WG 3 an end-to-end (=channel) specification. Response: Deferred to D2. Related to PMD/Optical Track III Motion #18, 1/97, which passed: Appoint a subcommittee to investigate, solve and bring the solution to the march meeting on characteristic impedance. Solution should include complete text ready to add to draft along with an accompanying motion. This be documented on the reflector at least two weeks prior to the meeting. 24. (E) ~line 18 Source/Date: John Wolcott, Intel, 1/24/ MHz 100ppm should be 125MHz +/-100ppm. 25. (E) Source/Date: John Wolcott, Intel, 1/24/97 I assume the electrical tables will be correctly inserted after presented and agreed to. Also, it is confusing to have CMOS in the titles when all of the specifications are specific to TTL. All instances of CMOS deleted. One change was inadvertently left out of D2 ( ). 26. (E) Source/Date: John Wolcott, Intel, 1/24/97 To be more specific, these signals are referenced from the midpoint of the rising edge of the transmit clock... shown in figure but not mentioned in the text. This change was inadvertently left out of D (E) Table 36-7 Source/Date: John Wolcott, Intel, 1/24/97 Units for period are incorrect. 28. (T) Source/Date: John Wolcott, Intel, 1/24/97 General comment: Will the long-haul PHY camp be required to use the delay constraint values in this section of the clause as well? If yes, then the -X designation for the PHY needs to be changed since they will probably be using an exposed GMII. Comment to be communicated to long haul copper track. 29. (E) Figure Source/Date: John Wolcott, Intel, 1/24/97 Drawing seems to have a few problems: text placement and clock line to Transmitter. Page 27 of 33 March 6, 1997

28 D1 figure replaced by D2 figure (I) PMD Signals (Clause 38 and 39) Three PMD signals are defined to be used by other 1000BASE-X sublayers and/or management: a) SIGNAL_DETECT b) TX_DISABLE c) FAULT Determine the support requirements for each of these signals. For each required signal, determine signal requirements. Response: Deferred to D (I) PMA Signals (36.3) Four PMA signals are defined to be used by other 1000BASE-X sublayers and/or management: a) -LCK_REF b) EWRAP c) EN_CDET d) CDET Determine the support requirements for each of these signals. For each required signal, determine signal requirements. Response: Deferred to D (I) PMA Jitter Tolerance Specifications (Table 36-6,7) To be added based on input from the Jitter Study Group. Response: Deferred to D2. Direction is to follow the recommendation of the Fibre Channel Jitter Study Group. 33. (I) MAC and SERDES timing budget (35.3 or 36.3) Include budget equations based on 1/97 San Diego proposal on this subject by Haluk Aytac into the relevant subclause. Deferred to D (E) Source/Date: Dave Fifield, National Semiconductor, Interim Meeting, PCS Track comment, 1/27-28/97 PMA function are incorrect. This subclause is deleted. Contents are updated and merged with (PMA sublayer.) 35. (T) Figure This figure needs to be redrawn completely. D1 figure replaced by D2 figure Page 28 of 33 March 6, 1997

29 36. (E) Examine the bit ordering for PMA bits (i.e., 0:9 or 9:0) within the document. Bit ordering is 9:0 in instances and is illustrated in D2 figure (T) Table 36.4 PMA clock signals were renamed to remove byte. However, the current signal names differ substantially from the corresponding GMII clock signals and may need to be renamed again. Mapping to GMII clock signals should also be established. PMA RC[0:1] renamed to PMA RX_CLK<0:1>. GMII RX_CLK = PMA RX_CLK<1> OR PMA RX_CLK<0>. TC renamed to GTX_CLK, same for GMII as PMA. 38. Extraneous comment deleted 39. Extraneous comment deleted 40. Extraneous comment deleted 41. (T) L15 Add info on doing Sent Code_Group.indicate. Merge from as needed. Not corrected in D2. Corrected in D (T) L30 Add info on sending messages/merge text from as needed. Not corrected in D2. Corrected in D (E) L48 Title should be: General electrical characteristics of PMA service interface. 44. (E) t(r)x_bits and t(r)x_code_group t(r)x_bits and t(r)x_code_group are defined for exactly the same purpose. One should be deleted Deleted t(r)x_bits. Replaced all occurrences with t(r)x_code_group. 45. (E) GMII RX_CLK generation from PMA RX_CLK<0> and <1> GMII RX_CLK generation from PMA RX_CLK<0> and <1> Specified in (T) PMA serial interface Source/Date: Dave Fifield, National Semiconductor, 2/17/97 The signals and electrical interface specifications for the PMA serial input and output signals are not defined. Page 29 of 33 March 6, 1997

30 Response: Deferred to D2. Signals T+, T- and R+, R- are illustrated in D2 figure but are not described in the text of D2. Page 30 of 33 March 6, 1997

31 1. (E) zD1 LC Comments and Responses Source/Date: Devendra Tripathi, XaQti, 1/15/97 Remove either from... across either the GMII. 2. (E) Source/Date: Devendra Tripathi, XaQti, 1/15/97 remove strongly from... then it is strongly recommended that.... Not corrected in D2. Corrected in D (E) 37.2 Source/Date: Devendra Tripathi, XaQti, 1/15/97 Figure 28-7 should be replaced by Not corrected in D2. Corrected in D (E) 37.3 Source/Date: Devendra Tripathi, XaQti, 1/15/97 It would better if function of... sequencing of Link_configuration >function is replaced by process. Not corrected in D2. Corrected in D (E) 37.7 Source/Date: Devendra Tripathi, XaQti, 1/15/97... shall be optional should be... will be optional because we can not be emphatic about optional things. Not corrected in D2. Corrected in D (T) Source/Date: Devendra Tripathi, XaQti, 1/15/97 The last part needs some simplicities. For example it may be enough to say that informing of offline is the only required part and completing the handshake is optional or something like that. Response: Deferred to D2. 7. (T) 37.7 Remote Fault Source/Date: Devendra Tripathi, XaQti, 1/18/97 If we want give meaning to offline and link configuration error remote faults, the local guy needs to support the same. It may be a good idea to show two more states of the link monitor state machine one in which it goes off line and sends the relevant info to the partner and in the other (may be if ability_match = false), it goes to a state where it indicates link configuration error. In either case link will not be available for transmission. Response: Deferred to D2. 8. (I) LINK_CONFIGURATION and AUTO_NEGOTIATION (Clause 37) Page 31 of 33 March 6, 1997