Re: Link Status encodings
Rich,
Thanks so much for keeping this issue moving forward.
Let me pick up the ball a moment and run, if I may.
You mention that
> 3) The choice of data codes need not satisfy any hamming distance
> requirements if the rule requiring the recognition of 3 successive Pulse
> Ordered-Sets is observed.
When a XAUI link is used between 2 DTEs, there is no
guarantee of getting Pulse Ordered-Sets (POS - oh,
this shouldn't cause too much confusion for all the
WAN folks :) more often than every 32 columns. This
is due to the fact that POSs can only follow As and
As can randomly occur from 16 to 32 columns apart.
I propose the following for detection methodology at
the RS:
1) Detection of LF/RF is true when at least 3 LF/RF
POSs occur within 96 columns. Reception of the
RF/LF POS or a packet resets the counter. This
could also be changed to any data or control
character other than an LF POS or Idle. Upon
detection of 3 LF/RF POS, the RS transitions
to the LF state or RF state. While not in the
LF or RF states, the RS strips POS and replaces
them with Idle to the MAC.
2) While in the LF state, the RS responds by
sending the RF POS and ignoring MAC data. It
also sets LINK STATUS = False. It stops sending
data to the MAC.
3) While in the RF state, the RS sets LINK
STATUS = False. It stops sending data to the MAC.
4) To remain in the LF/RF state, the RS must receive
at least 1 LF/RF POS every 64 columns. This allows
for noise to corrupt, at worst, every other LF/RF
and the RS will remain in this state.
Comments?
Ben
Rich Taborek wrote:
>
> Pat,
>
> I was actually working on this per request from Ben Brown. I'd like to
> discuss agreements reached in Tampa followed by proposed criteria for
> code selections and then should all encodings for all interfaces. Please
> note that I was developing the /K/D/D/D/ structure "on-the-fly" in Tampa
> and acknowledge several inconsistencies as you point out. I apologize
> for the errors.
>
> Agreements reached in Tampa from taborek_2_1100:
> - Leveraging 10GFC Signal Ordered-Set
> - Same Format As Start Delimiter: /K/D/D/D/
> - RS Alternates Signal With Idle Continuously
> - 8b/10b Continuous Signal after every ||A||
> - Recognized Upon 3 Consecutive Signal Occurrences
> - 8b/10b, 64b/66B, XGMII, XSBI, SUPI, WIS, etc. Compatibility
>
> Proposed criteria for code selection:
>
> 1) The proposed protocol neither matches 10GFC Signal nor Sequence
> protocol. 10GFC Signal is signaled once, at any time during Idle.
> Sequence is signaled continuously and alternatively with Idle and is
> mutually exclusive with frame transmission. Therefore, it should be a
> third Ordered-Set type, I'll call it Pulse for lack of a better name for
> the moment. Please feel free to submit your choice of name.
>
> 2) The choice of value of /K/ should not conflict with values chosen for
> any other Ordered-Set or the Start Delimiter. This leaves out
> /K28.7/=Start, /K28.2/=FC Signal and /K28.6/=FC Sequence. To prevent
> confusion with all other Ordered-Sets used by 10GE, the value of /K/ for
> Pulse should also not use: /K28.5/=/K/, /K28.0/=/R/, /K28.3/=/A/,
> /K29.7/=/T/ and /K30.7/=/E/. Please note that the /K28.6/=FC Sequence is
> new for 10GFC and is a change from the baseline proposal.
>
> I'd like to propose /K28.4/ to identify the Pulse Ordered-Set. It's
> really a toss up between /K28.4/ and /K23.7/. Both codes are balanced,
> allowing them to be added or removed from a 10-bit stream without
> affecting the running disparity of the stream (e.g. can replace an /R/
> if need be). Please note that the same must be true of all data codes
> code the Pulse Ordered-Set to achieve full functionality. /K28.4/ comes
> first in the list, so my choice is /K28.4/ and is a code previously
> reserved for LSS in walker_1_0700.
>
> 3) The choice of data codes need not satisfy any hamming distance
> requirements if the rule requiring the recognition of 3 successive Pulse
> Ordered-Sets is observed.
>
> For data codes, I'd like to be as simple as possible. Given that the
> Pulse Ordered-Set can be denoted as /K28.6/D2/D2/D3/,
> I propose the following encodings for D1 through D3:
>
> D1 - x'00' --|
> D2 - x'00' --V-> Fault Message
> D3 - bits 0-5: Reserved for future use (e.g. bit 5 = Break Link, etc.)
> bit 6: Remote Fault
> bit 7: Local Fault
>
> Encodings for all interfaces:
>
> +----------------------------------------------+
> | | | | | 64b/66b |
> | Lane | XGMII | XGMII | 8b/10b or | 10GBASE-R |
> | ID | T/RXC | T/RXD | 10GBASE-X | x/y |
> +------+-------+-------+-----------+-----------+
> | 0 | 1 | 0x9c | K28.4 | 0b0000 |
> | 1 | 0 | 0x00 | D0.0 | N/A |
> | 2 | 0 | 0x00 | D0.0 | N/A |
> | 3 | 0 | 0x0n | Dn.0 | N/A |
> +----------------------------------------------+
>
> Notes:
>
> 1) The data value in lane 3 represents all possible encodings of the RF
> and LF bits. Since these bits are mutually exclusive, the applicable
> values are 0b00, 0b01 and 0b10.
>
> 2) x/y locations are illustrated in walker_1_0700 slide 19. Other values
> reserved for x/y are as follows:
> 0b1111 for FC Signal
> 0b0101 for FC Sequence
>
> 3) Complete details on 64b/66b frames associated with Pulse, FC Signal
> and FC Sequence Ordered-Sets are included in walker_1_0700 slide 19.
>
> 4) All encodings are transported transparently trhough the WIS, XSBI and
> SUPI.
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> Richard Taborek Sr. Phone: 408-845-6102
> Chief Technology Officer Cell: 408-832-3957
> nSerial Corporation Fax: 408-845-6114
> 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> Santa Clara, CA 95054 http://www.nSerial.com
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------