Re: Comma Characters
Pat,
I guess that most if not all Gigabit Ethernet links get enough of the
right comma variants they need, AN or no AN. Otherwise, the links would
not work. Bottom line is that comma detection works and that it is
disadvantageous to implement any 8B/10B system which recognizes only one
comma variant. The same goes for 10 Gigabit Ethernet. I don't want to
advertise, promote or hold onto bad ideas moving into the future.
Best Regards,
Rich
--
pat_thaler@agilent.com wrote:
>
> Rich,
>
> I checked for that. It only goes back to AN when loss of sync occurs for an
> extended time. See the definition of an_sync_status (page 1023 of Doorstop
> 2000). In particular, "FAIL;The variable sync_status defined in 36.2.5.1.3
> is FAIL for a duration greater than or equal to the link timer." Link timer
> is defined as 10 ms +10ms, -0ms. This is so that autonegotiation will be
> invoked for disruptions of the link that are long enough that the cable may
> have been unplugged and reattached somewhere else. If there is a brief loss
> of sync as may happen if an ugly noise burst caused loss of sync, then sync
> can be regained without going back to AN.
>
> We did intend for sync to be able to be regained without going to AN.
>
> Furthermore, mr_an_enable can be used to disable autonegotiation entirely.
> In that case, loss of sync does not cause AN to be entered.
>
> Therefore, comma detection is required to work without entering AN.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@earthlink.net]
> Sent: Thursday, December 14, 2000 11:03 AM
> To: HSSG
> Subject: Re: Comma Characters
>
> Pat,
>
> 1000BASE-X starts off with Auto-Negotiation and goes back to AN whenever
> a loss of sync occurs. AN can only complete after
> sync is acquired. AN utilizes an equal number of positive and negative
> commas. Comma detection is not required once sync is acquired.
>
> Best Regards,
> Rich
>
> --
>
> pat_thaler@agilent.com 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@earthlink.net]
> > 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@nSerial.com
Santa Clara, CA 95054 http://www.nSerial.com