RE: Comma Characters
Rich,
Yes, with all the + and -, I mistyped one. As I said latter, "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-." 1000BASE-X makes sure there will always be comma+ characters
because there were devices that would only lock on comma+. Hopefully, few
people were misled by the typo since I included the same text you quoted
from 802.3.
For 10GBASE-X, it is fine to require that implementations such as the PCS
detect both kinds of commas. However, right now I couldn't find anything in
Clause 48 about comma detection other than references to 36.2.4.9. Clause 36
never specifically says that one is only required to detect comma+ or that
one is required to detect comma+ and comma-, but it gives a very strong hint
in 36.2.4.9 that comma+ detection is enough. For the current 10GBASE-X
signaling, in any extended duration of idle we will have both kinds of
commas so a device that only detected one polarity of comma would eventually
lock.
The strongest arguments for requiring detection of both kinds of commas are
retaining flexibility for future adapation of the code and speeding
reacquisition of sync after a bad burst error. It takes 4 commas to
reacquire lock. If one looses sync during a stream of back-to-back packets,
some IPGs may have no K's and some may have only one. So it can take more
than 4 packets to require sync on all lanes even if one detects both kinds
of commas and detecting only one kind of comma could delay it even more.
If we want to require that 10GBASE-X detectors detect both comma+ and
comma-, then we will need to make a statement to that effect in Clause 48. I
would prefer that we require detection of both polarities.
Best regards,
Pat
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Friday, December 15, 2000 8:13 AM
To: stds-802-3-hssg@xxxxxxxx
Subject: 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