Re: XAUI and 64b/66b
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?
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 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.)
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.
Rich> 4) If indeed you still believe that the Serial PCS should
reverse-translated
Rich> XGXS codes (/A/K/R/'s) into RS codes (/I/'s) and the stream gets
all the way to
Rich> the optional Remote XGXS adjacent to the Remote PCS, this XGXS
must regenerate
Rich> the XGXS codes to support XAUI. It's much simpler to not do thia
translation
Rich> twice.
Ben> I would argue that implementations which do not use XAUI
Ben> won't have to do it at all. Another disagreement.
Rich> No. Here we agree. The operative word is "implementation". So long
as an
Rich> implementation can properly translate its received control codes
properly to
Rich> pass to the RS it would be deemed compliant.
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
-----------------------------------------