Re: XAUI and 64b/66b
Ben,
Sorry about the late response to this note. I'm finally catching up.
Brown, Ben wrote:
>
> Rich,
>
> Okay, let's start over. The reason I asked this question in
> the first place was due to my understanding of what I thought
> XAUI was and how it fit into the stack. Right or wrong, I was
> under the impression that XAUI, though an extremely efficient
> ASIC interconnect (for all the reasons you've previously
> provided), was intended to be transparent to the MAC/PCS
> service interface. Given this transparency, I was confused
> when I noticed that the 64b/66b was directly encoding the
> XAUI specific control codes. This was where my mind was when
> I asked my question.
>
> Obviously, you are of a different opinion, one which I cannot
> say is incorrect, merely different from mine. A few vocal
> participants on this reflector seem to have the same opinion
> as me, others have yours. I'll leave this alone for now.
>
> Given my aforementioned state of mind, my original question was:
> "Why does the 64b/66b serial PCS REQUIRE the /A/K/R/K/R/... idle
> stream? Why can't it use the /I/s that the RS provides?" I don't
> think you've ever actually answered this for me. Is there a
> TECHNICAL REASON why it requires these codes or is this a mere
> convenience for those implementations which choose to use XAUI.
> By the way, stating that there is no technical reason and that
> it is done as a convenience is a fine answer. After all the
> discussions we've had over the past few days, I've learned a few
> things. But I really want to know the answer to this question.
> Beyond (physically) the XAUI interconnect, what advantage do
> these codes bring to the 64b/66b serial PCS?
The short answer to your questions is that it doesn't. The long answer is that
64B/66B must be capable of transporting more than /I/. If an error occurs during
/I/ 66B frame transmission, the /I/ may need to be replaced by an /E/. If Idle
Busy must be transported instead of /I/ a different code than /I/ must be
transported. This is true of the RS, XGMII and XAUI as well.
The general reasons for supporting more than /I/ over 64B/66B include Ethernet
and non-Ethernet reasons. Reasons or transport are not limited to transport to
64B/66B and include going "through" 64B/66B, over the medium and to the remote
device. The Ethernet related reasons include:
Support of control information during the IPG for Ethernet. This would include:
a) Desirability for common components with FC, InfiniBand, etc.;
b) Support of Layer 1 signaling for Optical Cross-Connects and management
thereof ala Mr. Osamu Ishida's Albuquerque proposal;
c) Support of Layer 1 signaling enabling functions such as Remote Fault and
Break Link to allow the prompt failover protocols (e.g. Busy Idle or
Ordered-Sets);
d) Possible support of Open Fibre Control protocols;
e) Support of XAUI codes in the absence of the XGMII without having to revert
to RS codes.
The non-Ethernet related reasons include the support of control information such
as delimiters and IPG control codes for
related standards such as Fibre Channel and InfiniBand;
> I disagree that it is "no more pain, overhead, etc. to have the
> Serial PCS generate /A/K/R/ instead of just /I/ from the RS". The
> simple fact of having to convert from the RS's /I/ to /A/K/R/...
> is indeed a process which requires some amount of overhead. It
> can very well be developed in <100 lines of code and perhaps a few
> hundred gates (don't quote me, I haven't tried either of these)
> but it is indeed overhead. (This is probably a larger verification
> effort than one of design and synthesis. I can already hear my DV guy
> complaining about this one - especially the randomness of the /R/.)
I have to give in to you on pain, I can't on overhead since there truly is no
additional overhead transporting either /I/ or /A/K/R. In any case, I don't
believe that this item will kick either of us "over the fence" so lets drop it
and go on to bigger ticket items related to the root issue.
> I fully agree that a XAUI interconnect scheme does not require
> an XGMII interconnect. I fully agree that, though the IEEE 802.3ae
> Layer Diagram proposed by Mr. Brad Booth shows both of these
> interconnect "layers", it does not mean both must be implemented.
> Indeed, because they are both optional, an implementation could
> actually choose to invent a completely different one and use it.
> (BTW, I followed your analogy - I'd throw away that 15' cord and
> just use the heavier one.)
I agree, and, thanks, I thought that was one of my better analogies.
> The following snippet is from your last response on this thread.
> Perhaps I'm reading your response incorrectly but does this mean
> that the 64b/66b can choose to encode /A/K/R/... OR /I/ and it
> is up the receiving side to respond correctly? I would be VERY
> tempted to talk further about this. This would mean the transmit
> side 64b/66b encoder could choose to encode with /A/K/R/... or /I/,
> depending upon whether it has a XAUI or not. If the receiving side
> connects to the MAC via a XAUI, it could transfer the /A/K/R/...
> directly or convert the /I/ to /A/K/R/... If the receiving side
> did not use a XAUI, it could convert the /A/K/R/... to /I/ or
> transfer the /I/ directly. I would love to talk more about this
> one, assuming I didn't take your response completely wrong.
There's only two ways this can work. You've identified one of the methods above.
The other would be for 64B/66B PCS to always transport /A/K/R/ whenever the RS
indicates /I/ regardless of whether or not XAUI/XGXS is present. You don't seem
to like this method though. The method above would have the XGXS sublayer
perform the translation, if required, from /I/ to /A/K/R/ whenever XAUI is
present.
> Rich> 4) If indeed you still believe that the Serial PCS should
> Rich> reverse-translate XGXS codes (/A/K/R/'s) into RS codes
> Rich> (/I/'s) and the stream gets all the way to the optional
> Rich> Remote XGXS adjacent to the Remote PCS, this XGXS must
> Rich> regenerate the XGXS codes to support XAUI. It's much
> Rich> simpler to not do this translation twice.
>
> Ben> I would argue that implementations which do not use XAUI
> Ben> won't have to do it at all. Another disagreement.
The above exchanges may be way out of context by now. You are correct in your
statement, but I'm not sure how you can disagree with mine.
If XAUI is present, it MUST transport /A/K/R/. If XAUI/XGXS is present at the
Local device, 64B/66B would transport /A/K/R/ as would the medium in the
direction of Remote device. My point is that there is NO requirement to reverse
translate from the XGXS adjacent to the PCS to insure that the PCS or medium
transports only /I/. There is no optional or mandatory XGMII defined between the
XGXS and PCS.
Best Regards,
Rich
--
> Thanks,
> Ben
>
> --
> -----------------------------------------
> Benjamin Brown
> Router Products Division
> Nortel Networks
> 1 Bedford Farms,
> Kilton Road
> Bedford, NH 03110
> 603-629-3027 - Work
> 603-624-4382 - Fax
> 603-798-4115 - Home
> bebrown@xxxxxxxxxxxxxxxxxx
> -----------------------------------------
-------------------------------------------------------
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