|
Comment #
|
Reason for removal from EZ
|
|
161
|
OK in principle removing -V1 but -T1 should be -T1/V1
|
|
64
|
Cannot delete this. This tells the bit order in a RS symbol. Page 102 line 7 tells the symbol order and not the bit order of the symbol.
|
|
180
|
For the low speed path it needs to indicate interleaverDepth and PrecodeDepth in addition to OAMen so that the high speed transmitter can comply with the high speed
receiver request
|
|
70
|
This was a clarifying remark on what to do with the OAM field during training. If this is not there then the question becomes is the OAM active during training.
If so when should it be active. When should the receiver be active? Setting to all 0s clarifies and simplifies all this.
|
|
129
|
Related to 70 and 192
|
|
192
|
The suggested remedy is even more clarifying vs comments 70 and 129.
|
|
133
|
The remedy is not quite true. See figure 201-12 in page 98.
The training frame is send in place of the aggregated 64/65.
THe 65 bits are placed per figure 201-16. But there is no sense of mapping XGMII to 65-bits as discussed in the PCS section.
|
|
127
|
Are we removing figure 201-16 in its entirety, or just the bottom half of the diagram. I prefer the figure as is. However if we want to remove the bottom half
then the "65-bit infofield" label in the diagram should be change to "65-bit infofield control block"
|
|
96
|
We should keep this section here. Perhaps say something like: PMA_state<7:6> greater than 01 is reserved for future use.
|
|
113
|
The remedy is not 100% correct. Propose reject.
Page 120 line 37 defines the SEND_S signal precisely for LEADER.
For the FOLLOWER it is a single SEND_S pulse following reception of SEND_S pulse from the LEADER.
|
|
197
|
Is this EZ bucket item simply replacing the text in the remedy or accepting the PDF contents wholesale?
|