Re: XAUI and 64b/66b
Joel,
Rick Walker's latest 64b/66b proposal carries the XAUI
encodings (A, K, R, S, D, etc.) instead of XGMII encodings
(I, S, D, EOP, ERROR). I had a problem with this since, at
the time, I was of the opinion that XAUI was supposed to
be some kind of transparent XGMII extender. Rich Taborek and
I exchanged about 20 emails via the reflector and kind of
compromised on allowing 64b/66b to carry both XGMII and XAUI
encodings to be more flexible.
Granted, this is just a compromise between the 2 of us and
only about 200 more people need to be convinced.
XAUI still uses 8b10b encoding. The serial LAN (may) still
use 64b/66b encoding. This discussion was merely in reference
to the support of the information carried across the LAN.
Again, I was under the impression that 64b/66b need not
carry the /A/K/R/... idle stream required by XAUI. Rich
has agreed with this but feels there are more reasons, as
listed in a previous note, that makes it worthwhile to have
the capability of carrying this extra information. I've
compromised to this end.
Now, let's climb back up the ladder and broaden our perspective.
I started this thread on a rainy Sunday afternoon when I was
sitting here trying to understand how all the proposals worked
instead of playing in the mud, tending to my cattle. I found
what I felt was a deficiency in the 64b/66b proposal and have
spent a few weeks trying to sort that out. This does not mean
that I'm automatically providing my support to 64b/66b, this
compromise merely makes it palatable should it be accepted.
However, as chair of the Logic track for this task force, I'm
very interested in any proposal that appears to be a complete,
end-to-end proposal. The schedule is too tight to be spinning
wheels at this point in the process.
Jonathan Thatcher, and others, began asking questions about SLP. I
trust at the next meeting there will be a much more comprehensive
presentation for SLP including alignment, bit ordering, overhead
capacity and how it can fit into a UniPHY just as easily as
64b/66b. Anything less than this will make it very difficult to
remain in the running. Remember Jonathan's rule: Proposals need
to be explained at least 3 times to even the most intelligent
people for them to understand it and endorse it. There are only
2 meetings left. You've got to do it right and you've got to do
it soon.
Ben
Joel Goergen wrote:
>
> Ben,
>
> aaaaahhhhhhhh :). My head is starting to hurt :)!
>
> Are you saying we just use 64b/66b rather then 8b10b all the way through from the mac
> to the phy? Why not do this or why do this?
>
> Sorry for perhaps reading this wrong .... but you have to admit, we need video
> reflectors :).
>
> Take care
> Joel
> ----------------------
> "Brown, Ben [BAY:NHBED:DS48]" wrote:
>
> > Rich,
> >
> > I saw this mapping in another email last night but I guess I
> > was confused as I didn't think it solved our problem. This
> > appears to be a map of XGMII or XAUI codes to 8b10b code-groups.
> > This does not appear to be a map of XGMII or XAUI codes to
> > 64b/66b codes. I've already seen the mapping to XAUI. I'm
> > waiting to see the mapping to 64b/66b.
> >
> > Rich Taborek wrote:
> > >
> > > Great! I think we have a deal! at least between us. Here's a proposal from Mr.
> > > Don Alderrou of nSerial for codes for the RS, XGMII and XAUI. I believe that
> > > only the 64B/66B mapping for Idle is missing. Idle would be coded as an
> > > additional 64B/66B 7-bit line code. Hopefully this will keep you from bugging me
> > > except for telling me that my next Guinness is up because I'm a LIGHTWEIGHT ;-)
> > >
> > > RS/XGMII RS Code Data Corresponding XGXS/XAUI Codes
> > > Code Name XD<7:0,K> Code name(s)
> > > ------------- -------------- -------------------------
> > > DATA (D) xxx xxxxx,0 Dxx.y
> > > IDLE (I) 000 00111,1 K28.5/K, K28.0/R, K28.3/A
> > > SOP (S) 111 11011,1 K27.7/S
> > > EOP (T) 111 11101,1 K29.7/T
> > > ERROR (E) 111 11110,1 K30.7/E
> > >
> > > ALT_SKIP (R) 000 11100,1 K28.0/R
> > > ALT_B_SYNC (Kb) 001 11100,1 K28.1/Kb
> > > ALT_unused1 010 11100,1 K28.2
> > > ALT_ALIGN (A) 011 11100,1 K28.3/A
> > > ALT_unused1 100 11100,1 K28.4
> > > ALT_SYNC (K) 101 11100,1 K28.5/K
> > > ALT_unused3 110 11100,1 K28.6
> > > ALT_unused4 111 11100,1 K28.7
> > > ALT_B_SKIP (Rb) 111 10111,1 K23.7/Rb
> > >
> >
> > And as for the lightweight part, I know better. I was sitting
> > there but it wasn't me that made that statement...
> >
> > 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
> > -----------------------------------------
>
> --
> Joel Goergen
> Member of Technical Staff
> High Speed Communications VLSI Research
> Bell Laboratories, Lucent Technologies
> 10250 Valley View, Suite 113
> Eden Prairie, MN, 55344
>
> Email: goergen@xxxxxxxxxx
> Direct: (612) 996-6932
> Cell: (612) 670-5930
> Fax: (612) 996-6995
--
-----------------------------------------
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
-----------------------------------------