Re: Interface reality check
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