Re: Comma Characters
Pat,
It was pointed out to me that I missed a minor detail in your note that
may be causing some confusion about the way the 1000BASE-X PCS operates.
You stated that: "the first K28.5 after a packet may contain comma- or
comma+, but all the rest will be comma-". This is not true. During the
1000BASE-X PCS Idle Sequence all Idle ordered_set with the possible
exception of the first contain a comma+. Per IEEE 802.3-1998 36.2.4.12:
"The /I1/ ordered_set is defined such that the running disparity at the
end of the transmitted /I1/ is opposite
that of the beginning running disparity. The /I2/ ordered_set is defined
such that the running disparity at the
end of the transmitted /I2/ is the same as the beginning running
disparity. The first /I/ following a packet or
Configuration ordered_set restores the current positive or negative
running disparity to a negative value. All
subsequent /I/s are /I2/ to ensure negative ending running disparity."
Please note that the /I2/ ordered-set consists of /K28.5/D16.2/, the
/K28.5/ variant issued for /I2/ is /-K28.5/ which is the variant chosen
from the "Current RD-" column of Table 36-2, and that /-K28.5/ contains
a comma+ (0b0011111).
Taking an implementation tangent for a moment, some early 1000BASE-X
SerDes, which are part of the PMA, recognized only either comma+ or
/-K28.5/. The 10GBASE-X PMA does not require comma recognition at all,
this function is moved to the PCS. Since there are no "old" 10GBASE-X
parts, the comma recognition idiosyncrasies of 1000BASE-X are not
relevant to 10GBASE-X.
I hope this clears up any residual confusion.
Best Regards,
Rich
--
pat_thaler@xxxxxxxxxxx wrote:
>
> Rich,
>
> The 1000BASE-X protocol is designed to make almost all the commas it emits
> be comma+. As you can see from the following passage from 36.2.4.12, the
> first idle at the end of a packet restores the disparity to negative and all
> following idles end with negative disparity:
>
> The /I1/ordered_set is defined such that the running disparity at the end of
> the transmitted /I1/is opposite that of the beginning running disparity. The
> /I2/ordered_set is defined such that the running disparity at the end of the
> transmitted /I2/is the same as the beginning running disparity. The first
> /I/following a packet or Configuration ordered_set restores the current
> positive or negative running disparity to a negative value. All subsequent
> /I/s are /I2/to ensure negative ending running disparity.
>
> So, the first K28.5 after a packet may contain comma- or comma+, but all the
> rest will be comma-. While sending configuration ordered sets, the K28.5s
> will alternate between odd and even but that won't be true during idle.
> Since sync is suppose to be able to be reacquired without going into
> configuration, a SERDES has to be able to lock on comma+ but isn't
> necessarily required to acquire lock on comma-. As 26.2.4.9 states, the
> 1000BASE-X coding is designed to ensure that comma+ is transmitted with
> equivalent or greater frequency than comma-.
>
> When we are sending idles and are between A's and not sending any ordered
> sets, our K28.5 disparity will alternate and we will have a 50/50 mix of
> comma+ and comma-. Still we are less heavy in comma+ and we should mention
> that difference.
>
> Pat
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Wednesday, December 13, 2000 11:20 AM
> To: HSSG
> Subject: Re: Comma Characters
>
> Brian,
>
> The history is that some old SerDes initially designed for Fibre Channel
> but slated for use in Gigabit Ethernet only supported one version of
> comma. I believe that you are correct in stating that the specific
> version was the positive comma version, also referred to as comma+ and
> corresponding to the bit pattern 0b0011111. The Gigabit Ethernet
> 1000BASE-X PCS protocol is designed to emit both comma versions in order
> to be "friendly" to all SerDes parts.
>
> Clause 48, 10GBASE-X PCS is specified to statisitically emit an equal
> number of both comma versions. The PCS implicitly requires the
> generation and detection of both comma versions. The big difference
> between 10GBASE-X and 1000BASE-X is that the 10GBASE-X does not require
> comma detection in the PMA.
>
> Personally, I don't believe that anything needs to be added to the
> Clause 48 to clarify this point since it is the "obvious" way that an
> 8B/10B protocol should work. Please go ahead and submit a comment if you
> feel otherwise.
>
> Best Regards,
> Rich
>
> --
>
> Brian Cruikshank wrote:
> >
> > In Clause 48.2.5.1.2 on page 261, the /COMMA/ is referred to being
> > defined in clause 36.
> >
> > In this section, both a positive and negative comma are defined.
> > I believe that in 1 GE devices, usually only positive commas were
> > recognized. Is this enough to be 1 GE and 10 GE compliant?
> >
> > In a IPG over 20 bytes, both commas will probably exist. In
> > sustained minimum IPG, the positive comma occurrence may be random.
> > Do positive commas occur often enough?
> >
> > Maybe this detail should be stated?
> >
> > /Brian Cruikshank
-------------------------------------------------------
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@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com