Re: Interface reality check
Rick:
The WAN-PHY implementation using 64/66 looks bad.
I've been looking at the WAN-PHY implementation using 64/66 with 64/66
characters imbedded in a SONET-format payload. It looks like the
implementation is going to be difficult due to the loss of word (and byte
allignment) of the 66b words relative to the OVERHEAD bytes. This will
force taking the data stream all the way back to serial between PCS1 and
PCS2. The serial stream looks like it would force the WAN-PHY PCS out of CMOS.
Cheers,
Paul
At 06:48 PM 4/5/00 -0700, Rick Walker wrote:
>
>
>Hi Brad,
>
>> "Booth, Bradley" <bradley.booth@xxxxxxxxx> writes:
>> Taking Rich's slides that he sent out last Friday, I did a couple of
tweaks.
>
>I like it. The only point I would quibble with is having the MAC RS
>generate the /A/K/R/ scrambling because it "reduce[s] EMI on the XGMII
>and XAUI".
>
>XGMII is a byte-wide interface so any scrambling of the IPG codes will
>actually cause *more* EMI rather than less. A static pattern at RS is
>the lowest possible RF energy.
>
>So, I would suggest modifying your proposal such that XGXS generates
>/A/K/R/ when receiving /I/ from MAC A's RS and converts /A/K/R/ back to
>/I/ when delivering it to MAC_B's RS layer.
>
>No one has yet articulated any compelling reason to have the MAC
>burdened with XAUI-specific scrambling. In the absence of XAUI, there
>is no need for /A/K/R/ scrambling. Let XAUI do the scrambling itself,
>and clean up afterwards, putting no extra burden on the MAC.
>
>> The concept is that the /A/, /K/ and /R/ that are used for XAUI are 10-bit
>> symbols. We can make them correspond to /a/, /k/ and /r/ which are their
>> "byte equivalents." I put that in quotes, because all /A/s decode to a
>> single /a/, all /K/s decode to a single /k/ and all /R/s decode to a single
>> /r/. The reverse is not true; /a/ is not encoded to a single /A/ (due to
>> running disparity). This is the same as in 802.3z.
>
>This is perfect.
>
>I see no sense in having separate 64b/66b /K/ and /Kb/ codes. These are
>logically equivalent and should be merged into the same symbol when
>transported across a non 8b/10b link.
>
>> I left the /O/ in, because I think that it might add some good features in
>> the future.
>
>Absolutely.
>
>The current proposal for 64b/66b has 8 general control codes, plus SOP
>and EOP signalled by type bytes. I have no intention of crippling the
>code. My point is entirely about how we standardize the usage of codes.
>
>For example, If we wanted /A/K/R/ to be transparently supported through
>all the CODECs so that it could be used for proprietary signalling
>purposes, then we should clearly state this as an objective. If the
>committee agrees to this need, then it would be fine to reserve some
>control space for proprietary vendor-specific modifications. If this is
>the goal, then it should be clearly stated and put into the "LCD".
>
>That said, I would personally prefer if we did not leave a loophole for
>proprietary implementations.
>
>If there is a serious need for out-of-band signalling, then I wish that
>the relevant parties would educate us about what is needed, and work to
>standardize such signalling. I think a general mechanism can be defined
>without opening up Pandora's box. An example of an attempt to do this
>is Osamu Ishida's XGENIE proposal which uses /O/ codes.
>
>I will be much more willing to vote for a proposal that includes a
>standardized out-of-band signalling system supported across all CODECs,
>rather than a scheme which disparages the idea of out-of-band signalling
>while simultaneously leaving loopholes for proprietary implementations.
>
>> This format would work for, or could be applied to, all the current
>> proposals we have on the table from SLP, SUPI, WWDM, WIS, Serial, MAS/PAM,
>> etc. I tried to keep this at an architectural level, not an implementation
>> level. I believe that this architecture should permit the majority, if not
>> all, of the implementations that get built.
>
>I think this is a great idea.
>
>Best regards,
>--
>Rick Walker
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx