Re: Interface reality check
Ben,
Thanks for the compliments! I truly appreciate them coming from you.
Brown, Ben wrote:
>
> Rich,
>
> Nice job, looks like you've described all the major opinions
> of this thread. I don't see much new here (and perhaps I'm
> missing something obvious) but I think it is a great job of
> putting pictures to the words.
>
> Page 1: I agree with everything here except perhaps the /O/.
> I'd like to understand more about why this is needed.
I've included the /O/, representing "other" in support of other standards such
as Fibre Channel and InfiniBand with common parts, for other OAM&P functions for
Ethernet WAN access and WAN applications, and for other unforeseen extensions to
10 GbE since I believe that we shouldn't assume that we have all link control
functions covered. Both 8B/10B and 64B/66B proposals currently support
additional control codes which may be required to provide /O/ support for the
purposes described above.
> Page 2: I agree with everything here except the following:
> This applies for any serial PCS, 64b/66b or other. I think
> this is the picture that I envisioned when I started this
> thread and what I understand is the picture that Mr. Rick
> Walker is in support of based on his most recent comments.
> The WWDM encoding may be identical to XAUI or may be
> something else completely. Either way, I'd like to
> see this specified with the encodings supported/
> required by RS only. Even XAUI is specified this way.
> XAUI requires /A/K/R/ for a further encoding of the
> IDLE stream but it takes /I/ as input (along with all
> the others /S/T/d/E/RF/BL/). Our debate is where the
> /A/K/R/ gets stripped off after XAUI.
I'm not sure I understand exactly what you're disagreeing with on page 2 since
its intention was to show your view: "Serial PHY, 64B/66B PCS, XGXS never
forwards /A/K/R/." Page 2 clearly show /A/K/R/ being stripped off and translated
back to /I/ by the XGXS adjacent to the PCS in Device A.
Our debate has also focused on only the Serial PHY and only on 64B/66B coding.
I'd like to keep our debate focused on these elements only. I believe that this
coding debate is applicable to and independent of other PHY's and encodings, but
I'd like to focus on the PHY/PMD we started with, especially since it is
endorsed by a significant cross section of IEEE 802.3ae Task Force members.
Can you please explain your disagreement with page 2 with respect only to the
Serial PHY with a 64B/66B PCS.
> Page 3: I think that this is the picture you've been in
> support of and the one that the current 64b/66b proposal
> describes. I don't agree with this picture.
If you'll allow me to twist your words: I believe that you agree that the
picture accurately represents my previous view of XAUI/XGXS and PCS operation
for the Serial LAN PHY with 64B/66B encoding. Your disagreement is with this
mode of operation, not the picture. I know it's a minor point, but I am trying
to accurately portray our debate in pictures since words are apparently not
working.
> Page 4: A minor twist to page 3.
Wow! This comment boggles my mind!
This picture is the heart of the presentation and illustrates a solution to
problems exemplified in page 2, call it Ben's picture, and page 3, call that one
Rich's picture. I must not have done a good job on the picture in page 4 or
maybe they all look too similar.
This page shows control codes being generated by the transmitting RS and
modified by the transmitting XGXS, if present. Control codes are then
transparently transported by the PCS and over the medium. All control codes not
specified by 10 GbE are translated to Idles by the RS. The latter translation
occurs in a manner analogous to that of the 1000BASE-X PCS Receiver.
> Page 5 & 6: I don't see any difference between these 2 pages.
> I agree with this.
I included these for completeness. They illustrate the "reverse" or Device B to
Device A path analogy to Pages 2 and 3, respectively.
> Page 7: A minor twist to 6 & 7. Though subtle, I don't like
> this but I could probably be convinced by using the same
> arguement that allows the 1000Base-X receive state machine
> to treat "everything else" as /I/.
I'm still surprised by your comment on page 4 since Page 7 illustrate the
"reverse" or Device B to Device A path analogy to Page 4. Your statement that
"to treat "everything else" as /I/" is exactly what I had in mind. I'm offering
this as the solution to our debate. I'm open to other solutions which can
resolve our debate in a simple manner.
> I don't think any of my responses have surprised you. At this
> point in the thread, I think we know where each other stands.
> It would be interesting to hear a few others weigh in on this.
>
> Thanks for the nice pictures. This should make involvement by
> the rest of the group much easier.
That was the intention. Anyone else out there want to offer their opinions?
> 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@nortelnetworks.com
> -----------------------------------------
--
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