XAUI/XGXS protocol
Kamran,
I've initiated a new thread since it's changed drastically. Please see my
comments below:
Kameran Azadet wrote:
>
> Hi Rich,
>
> here are answers to your questions:
>
> >Take SLP as an example. SLP mapped to XAUI would logically be mapped in one of
> >two ways. Theoretically, many other striping granularities, such as
> >word-striping, are possible but I fail to see any benefits in doing so:
> >
> >1) Stripe SLP frames one-by-one each of 4 lanes;
> >2) Stripe SLP frames byte-by-byte on 4 lanes.
>
> I don't know where "SLP frames" came from? SLP is a byte by byte mapping of
> packets (for instance ethernet packets). We never suggested to send frames on
> each lane. For a XAUI type interface the striping could be anything, byte or
> word striping or other schemes.
Your response is in line with my evaluation. I'm sorry about posing the question
this way, but your proposal left me no choice but to ask since you have
mentioned SLP as being a candidate for the XAUI/XGXS but there is nothing in
your Albuquerque that suggests how this may work. Your response suggesting XAUI
SLP word striping leaves me a bit confused though. I'll assume byte-striping as
suggested in your Albuquerque proposal and your first sentence in the above
paragraph until I'm corrected.
> >Obviously method (1) striping whole SLP frames on each lane does not lend itself
> >to chip-to-chip interconnect or backplane applications since the buffer sizes
> >and control logic required to buffer variable sized SLP frames encapsulating
>
> Yes, but no-one ever proposed this...
I agree. It's dropped.
> >Ethernet packets would be unwieldy. Method (2) is fatally flawed for the
> >following set of reasons:
> >
> >a) Individual Lane as well as 4-lane Link synchronization is not achievable with
> >the present SLP proposal since no deskew methodology has been proposed. Note
> >that SLP non-scrambled /A/K/R/ sequences as used by 8B/10B would create an EMI
> >exposure similar to that of 8B/10B and the the insertion/removal of /R/s would
> >invalidate the SLP T-flag (EOP indication).
>
> Regardless of whether a packet delineation scheme is scrambled or un-scrambled,
> bytes sent on four lanes can be scrambled, using EMI-optimized scrambling. In
> their SUPI proposal, Nortel presented an elegant way to do deskewing in a
> "protocol
> independent" fashion. For instance by removing one byte of idle per IPG, one
> can insert un-scrambled columns of control characters such as:
> A K R
> A K R
> A K R
> A K R
> (to be consistent with your byte striped HARI proposal). This requires an
> insert/delete FIFO. A, K and R are bytes instead of 10b words. One can remove
> a whole column of Rs without affecting the T-flag. Please note the line rate on
> each lane can be exactly 2.500 Gb/s. No rate conversion circuitry is necessary.
For one to remove a whole column of R's one must first locate the column of R's.
For an 8B/10B based XAUI/XGXS it's quite simple and low power:
1) A XAUI receiver takes in four incoming bit streams which are frequency but
not phase locked;
2) 4 separate synchronization circuits lock to either one of two 7-bit comma
patterns to achieve lane synchronization and byte alignment. Note that this can
happen on the first comma detected;
3) Parallel logic at 312.5 MHz aligns /A/ codes on all 4 lanes to deskew the
byte-striped information.
The synchronization process for SLP is significantly more complex. Please
correct me if I'm wrong. I'm going to try and design the simplest SLP
synchronization process.
ASIDE: Please note that I'm having a very difficult time comparing SLP and SUPI
to 8B/10B as XAUI/XGXS alternatives because there are no complete SLP and SUPI
XAUI/XGXS alternative proposals on the table. This is especially true for SLP.
Your statements that SLP could be byte or word striped and that the control
codes may or may not be scrambled make a world of difference when I try to
architect a working solution never mind trying to figure out how to optimize an
implementation. Therefore: I'll make another assumption here and assume that
SLP control codes are NOT scrambled.
1) A XAUI receiver takes in four incoming bit streams which are frequency but
not phase locked;
2) Since there is no way to reliably determine byte boundaries nor infer that
the bit stream is scrambled or not at this point, synchronization must occur
across 4 lanes simultaneously;
3) Synchronization involves the detection of a possible match of a 16-bit
pattern of non-scrambled data in the presence of up to 37 bits of skew = 53
bit/lane pattern match assuming an 8-bit deserializer width and implementation.
Possible infers to the relatively high likelihood that the AK pattern will
appear in a random data stream in any of the 4 lanes producing false
synchronization;
4) Deskew requires both bit and byte alignment across 4 lanes within the deskew
window.
Once the receiver is in sync, /R/ columns can be inserted or removed.
I am concerned about both the size of the pattern match and the rate at which
this match must be performed. For example, is a serial shift register used to
perform this pattern match at the bit rate? If not, the multiplexing logic used
to ensure a 4-lane simultaneous pattern match across a 53-bit space is very
unwieldy compared to 8B/10B 7-bit comma match.
I believe that the 25% overhead of 8B/10B at this level is an excellent tradeoff
against the complex and statistical nature of SLP. Note that 8B/10B requires
absolutely no rate matching since 8-bit data is transported at exactly the same
rate as 10-bit data. Both move at 312.5 MHz in chunks of 4 bytes/code-groups.
> >b) The SLP proposal does not support clock tolerance compensation as does 8B/10B
> >by the insertion/removal of /R/ columns since doing so would compromise the SLP
> >T-flag. Such a compromise increase significantly the probability of false match
> >as well as undetected packet error not to mention the complexity of the
> >synchronization logic.
>
> T-flag is not affected. Probability of false match is if I remember well, on the
> order of once every 2000 billion years for perfect match, and once every ~14
> million years for match with 3 bit error tolerance.
Your statement above greatly concerns me: "One can remove a whole column of Rs
without affecting the T-flag". It is clear that removing a column of /R/s
significantly increases the probability of false EOP, and worse yet, undetected
error since the T-flag may be reduced from 12-bytes to 8-bytes at the receiver
upon /R/ column removal. This problem does not exist with an 8B/10B-based
XAUI/XGXS. Please check your calculations.
> >c) Synchronization is slow and complex is based on the detection of multiple
> >possible control patterns as is the case of supporting other 10 GbE features
> >such as Busy Idle, or any similar special control codes which have been proposed
> >for supporting all-optical switches ((NTT Albuquerque proposal) or Fibre
> >Channel/InfiniBand specific control codes.
>
> Synchronization is not slow and complex. I also disagree with your statement
> that SLP is specific to ethernet, and can not support a large set of
> control codes. We showed that with a 4b Hamming distance one can support up
> to 16 control characters. By using a control character such as "O", one can
> create ordered set control for fibre channel (ODDDODDD...). It can support
> other control words too (up to 16).
Additional control codes such as, Busy Idle, Fibre Channel Ordered Sets, would
interrupt the /A/K/R/ Idle pattern. This is not a problem for an 8B/10B-based
XAUI/XGXS in terms of synchronization time or complexity. They are essentially
passed straight through. SLP of the other hand would have to deal with multiple
4-lane T-Flags unless you impose additional rules requiring a longer minimum IPG
for SLP or switch to a shorter T-Flag, which greatly increases the probability
of false EOP and the undetected error rate. Note that multiple T-Flags
dramatically increase the complexity of synchronization pattern match logic
since the the T-Flag pattern is essentially the synchronization pattern.
> >d) Single lane synchronization, as simple as 8B/10B comma detection, is not
> >possible since SLP requires the detection of multiple long patterns across all
> >lanes to acquire link sync. Link and system problem determination as well as
> >scalability to higher speeds are all significantly compromised.
>
> The scheme described above is scalable to other speeds.
The probability of false sync increases with an increase in lanes since SLP link
synchronization requires a pattern match across all lanes in the presence of
skew. Any 16-bit match of multiple possible T-Flag lane patterns in the data in
any lane would result in false sync.
> >e) SLP frames provide no error detection or containment capabilities for
> >transported data thereby increasing the undetected error rate of the link.
>
> 64b/66b does not provide data error detection capability. How come ethernet
> works well with 64b/66b that does not support error detection?
This entire thread does not concern 64B/66B since 64B/66B has never been
formally proposed as a coding for XAUI/XGXS. I'd like to limit this thread to
XAUI/XGXS protocol only. My point (e) is that 8B/10B provides very robust data
error detection capability and SLP provides essentially "negative" error
detection capability since false T-Flags can indeed create false "short"
packets.
> >To a lesser extent (not much less) the same general argument above applies to
> >the use of SUPI or 64B/66B as a XAUI encoding.
>
> SUPI was proposed by Nortel more as a PMD interface, not for XAUI, but I
> don't see why it couldn't work for XAUI.
For many of the same reasons I've given above comparing an 8B/10B-based
XAUI/XGXS to an SLP-based XAUI/XGXS.
> on the other hand:
>
> 64b/66b does not work for XAUI. The encoding does not allow mapping things like
> ------------------------------
> D D D T I I I S, which you can observe on a lane of HARI. Therefore 64b/66b
> is not a candidate. And I don't recall Rick Walker or Rich Dungan ever
> saying that it could be used in HARI.
Rick Walker, Don Alderrou (nSerial) and I discussed an 64B/66B-based XAUI/XGXS
in Albuquerque over lunch and concluded that it wasn't such a great idea for
many of the reasons I presented above. It is clearly more reliable than SLP
since 66B frames are very well defined and easy to check. In that sense it does
offer excellent error detection for control information including robust EOP and
SOP as well. The down sides are that 66B frames would have to be striped across
each lane increasing latency and synchronization of 66B frames on each lane is a
statistical (read: slow) process.
Note that "D D D T I I I S" is NOT a possible XAUI pattern if I interpret it
correctly. I assume that the first "D" corresponds to lane 0 and the "S"
corresponds to lane 3. To date, the only proposals on the table for 10 GbE, 10
GFC and InfiniBand all have "S" in lane 0 only. The Albuquerque 64B/66B proposal
supports all proposed XGMII and XAUI/XGXS patterns.
> Hope this clarifies a bit
To clarify things, I think I'd like to see a concise and complete SLP, SUPI or
64B/66B alternative coding proposal for XAUI/XGXS. Right now, no such animal
exists. It would be much easier for the 802.3ae committee and reflector
participants to compare such a proposal to the strongly supported 8B/10B-based
XAUI/XGXS proposal.
In closing, one related issue that you did not touch on is EMI. Reflector
traffic recently has been very high in the EMI area and I agree the concern is
well places. 8B/10B codes, especially repetitive codes sent during IPG tend to
have high EMI. Don and I have come up with some very simple solutions which I'll
share in another thread. However, in this note you proposed an SLP /A/K/R/K/...
repeating pattern which is non-scrambled. You might have Joel Goergen take a
look at this pattern at the SLP 2.5 Gbps with respect to its current 8B/10B
equivalent at 3.125 Gbps on his current test setup to see how much worse the SLP
Idle pattern is in terms of EMI. I haven't run it, but I'd be interesting in
seeing the results. The exact repeating patterns for both are as follows. Note
that I simply picked the first three control codes from slide 11 of your
presentation to represent SLP /A/K/R/ Please feel free to optimize this code
choice for EMI yourself:
SLP repeating Idle pattern:
00010111 01001110 01110100 01001110 01110100 01001110 01110100 01001110 01110100
01001110 01110100 01001110 01110100 01001110 01110100 01001110
8B/10B repeating Idle pattern:
001111 0011 110000 0101 001111 0101 001111 1010 110000 1011 110000 0101 001111
0101 001111 1010 110000 1011 110000 0101 001111 0101 001111 1010 110000 1011
110000 0101 001111 0101 001111 1010 110000 1100 001111 1010 110000 1011 110000
0101 001111 0101 001111 1010 110000 1011 110000 0101 001111 0101 001111 1010
110000 1011 110000 0101 001111 0101 001111 1010 110000 1011 110000 0101
> Regards,
>
> Kamran
--
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@nSerial.com
Santa Clara, CA 95054 http://www.nSerial.com