RE: Comma Characters
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@xxxxxxxxxxxxx]
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@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