Re: Interface reality check
Ben,
Sorry for my too short explanation. I'll make it clear bellow.
At 10:41 PM -0400 00.4.2, Brown, Ben [BAY:NHBED:DS48] wrote:
> Does the regenerator you describe look something like this?
>
> PMD -> PMA -> PCS -> XGXS -> XAUI -> XGXS -> PCS -> PMA -> PMD
>
> I'm not sure this would be a device specified in the standard
> even though it uses components defined by the standard. However,
> let me see if I can follow through with your thought process.
Yes, you have drawn my regenerator perfectly. I do not care this
regenerator would be a standard device or not, since I think it
will work well simply by using components defined by the standard.
> In my opinion, the /A/K/R/ only exists between/within the
> XGXS boundaries. It is used for alignment, jitter, etc., across
> the 4-lane XAUI and has a useful purpose there. Others are of
> the opinion that /A/K/R/ can be carried past these boundaries
> with the only detrimental affect being the loss of PCS coding
> space.
I think I have understood both sides cleary. My opinion is /A/K/R/
transparency beyond the boundaries has a little practical advantages
that deserve the negligible loss of PCS control code space in 64/66.
> I think your message is referring to yet another "future idle-
> sequence". I presume this means additional codes beyond /A/K/R/
> as opposed to simply a re-ordering of these same codes. Given
> XAUI's randomness in the order of /A/K/R/, re-ordering these
> same codes would not be obvious. So, the new codes required by
> your "future idle-sequence" would require additional code space
> and, in particular, would need to be defined during the standard
> specification phase so the PCS would know what these codes are.
> To get these codes defined during the specification phase of
> the standard, you would not be making this a "future idle-
> sequence" but another "present idle-sequence" and presumably,
> this one would exist to fulfill a particular purpose that /A/K/R/
> couldn't fill.
No. Here I just consider a re-ordering of /A/K/R/.
First, I am concered that Fibre Channel may adopt different rules for
re-ordering these /A/K/R/. FC may have more powerful randomization to
reduce EMI a bit further. In this case the regenerator can enjoy this
EMI reduction if his XGXS has /A/K/R/ transparency. If not, the
regenerator only follows the 802.3ae randomization rule and can not
enjoy further EMI reduction.
Second, if we have /A/K/R/ transparency, we can debug the regenerator
at XAUI by simply inserting fixed (non-randomized) /A/K/R/ pattern into
the PMD. If we don't have /A/K/R/ transparency, inserting /I/ into the
PMD yields randomized /A/K/R/ on XAUI and hence we can not observe fixed
pattern there; this may be a little hard to maintenance.
I agree that these advantages are far from dramatic. However, in my
opinion, these are enough to deserve the loss of PCS coding space if it
is far from running out as Rich has pointed out.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg01924.html
I hope this helps you and Rich to wrap up your brilliant discussions.
Best Regards,
Osamu
> Allowing the receive state machines to treat unknown but valid
> codes as idles is one thing but I don't know how to future proof
> the transmit machines.
>
> Have I mis-understood you? Can you please shed more light on
> something I'm missing?
>
> Thanks,
> Ben
>
> Osamu ISHIDA wrote:
> >
> > Dear Ben and Rich,
> >
> > At 8:33 AM -0500 00.4.1, Brown, Ben [BAY:NHBED:DS48] wrote:
> > > Please, let's get some new blood in on this discussion! I feel
> > > like we're in a vacuum.
> >
> > I would like to add another side dish for your Guinness;
> > this is a bit reinforcement for XGXS to propagate /A/K/R/ rather
> > than having to translate them to /I/.
> >
> > I have guessed the /A/K/R/ randomization in Rich's mail to work
> > pretty well for EMI reduction, but still would like to reserve my
> > last one cent to future idle-sequence up-grade by other standard
> > such as fibre channel. Also another peculiar application
> > may utilize the /A/K/R/ sequence itself for some other purposes,
> > such as field maintenance debugging tool hinted by Mr. Edward Chang.
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg01916.html
> >
> > Once we carriers invest in a 10 Gigabit Regenerator that is a
> > pair of two Attachment Units connected back to back with XAUI
> > backboard interface, we hope the regenerator can enjoy the future
> > up-grade benefits and can carry another idle sequences without any
> > field upgrade operation.
> >
> > If XGXS on the regenerator does not propagate /A/K/R/ or any other
> > interpacket gap sequences as it is, our investment may lose strong
> > support of potential automatic field upgradability/interoperability.
> >
> > Cheers,
> > Osamu
> >
> > ---------------------------------------
> > Osamu Ishida
> > NTT Network Innovation Laboratories
> > TEL:+81-468-59-3263 FAX:+81-468-55-1282
> > ---------------------------------------