RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistenc ies
Pat,
>
> is latched.) The duplication has fallen below my personal
> threshold for
> raising a comment. Since in Status register 1 never has many
> bits used and
> the other bits in Status register 2 generally report static
> information such
> as abilities, it would be logical to move the receive and
> transmit local
> fault detection bits to status register 1 and to remove the
> receive link up
> bit.
>
The only concern is that the duplication may invoke some questions in an
occasional reader's mind. Besides that, you probably right by saying that it
may not worth a comment.
> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Tuesday, July 24, 2001 10:06 PM
> To: Boaz Shahar
> Cc: HSSG (E-mail)
> Subject: RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential
> inconsistenc ies
>
>
> Boaz,
>
> I agree with Rich. I notice that you consistantly misread the
> text of clause
> 45. Whenever it says "detects a local fault condition" you quote it as
> "detects an LF condition" and this seems to be the source of the
> misunderstanding. The former means that the the device has
> detected a fault
> in itself. The fault could be an inability to sync to the
> incoming signal or
> it could be an implementation dependent fault detection capability.
>
> We have no requirements (and no options) for any sublayer
> except the RS to
> detect an incoming LF signal and we specify no rules for such
> detection
> except at the RS. That is why there are no bits in Clause 45
> for "detects an
> LF signal". There are only bits that are set when a local
> fault condition is
> detected.
>
> Regarding your question about the apparent duplication of local fault
> reporting bits. I have never understood why in status
> register 1 we have a
> bit that indicates that the receive link is up while in
> status register 2 we
> have a bit that indicates it's inverse - a receive local fault. (Note
> however that, since they both latch, they may not at a given
> time contain
> inverse values. One may have been cleared by reading while
> the other still
> is latched.) The duplication has fallen below my personal
> threshold for
> raising a comment. Since in Status register 1 never has many
> bits used and
> the other bits in Status register 2 generally report static
> information such
> as abilities, it would be logical to move the receive and
> transmit local
> fault detection bits to status register 1 and to remove the
> receive link up
> bit.
>
> The bit in 5.24.12 is different than the bits in status
> registers 1 and 2 in
> two significant ways. First, it only indicates a failure to achieve
> alignment to the incoming signal while the other two bits can reflect
> implementation dependent fault detection. Secondly, it is not
> latched. The
> bits in the lane status registers represent a snapshot of the
> status of the
> receive link synchronization: the status of each lane plus
> the ability to
> deskew across the lanes.
>
> Regards,
> Pat Thaler
>
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Sunday, July 22, 2001 12:58 PM
> Cc: HSSG (E-mail)
> Subject: Re: [802.3ae] D3.1 Clause 45 and Clause 48 potential
> inconsistencies
>
>
>
> Boaz,
>
> 48.2.5.4.1, Link status detection, is general about local_fault
> conditions. It ends with: "A local_fault condition may also be
> recognized by any 10GBASE-X process upon detection of an
> error condition
> which prevents continued reliable operation, but that is beyond the
> scope of
> this standard." This definition is applicable to the 10GBASE-X PCS as
> well as both the DTE and PHY XGXS.
>
> It follows that the condition for setting management register
> bit 5.8.10
> includes "any error condition which prevents continued reliable
> operation" where that error condition is detected or recognized by the
> DTE XGXS only. Included in the preceding set of error
> conditions is the
> specific error condition that you note: "Has not synchronized and
> aligned all four receive lanes".
>
> I believe that we're on track (1.b) per your note and that the wording
> in 48.2.5.4.1 is complete.
>
> In response to your track (2) inquiry, 48.2.5.4.1 points out that the
> definition of such conditions are beyond the scope of the standard. To
> give you an idea of the possible conditions, one is that a
> PMA reference
> clock input may be non-operational, assuming one is required.
>
> Best Regards,
> Rich
>
> --
>
> Boaz Shahar wrote:
> >
> > Ben,
> > I understand your position about commenting. However,
> before commenting, I
> > think I should try to understand the intention there. I'll
> try to put my
> > question in a more direct way here, and may will submit
> another discussion
> > about the DTE-XS vs. the PHY-XS status definition bits
> later. So here are
> > the questions regarding the DTE-XS initially:
> >
> > Questions
> > (1) What is the condition for setting bit 5.8.10 ? (p.234)
> Or: What is the
> > definition of the event: "The DTE has detected a LF condition on the
> Receive
> > path"? Is this the same as: "Has not synchronized and
> aligned all four
> > receive lanes"?
> > AND:
> > (1.a) If the answer to (1) is "Yes", Do we need the
> duplication of the
> same
> > function on 3 bits: 5.1.2, 5.8.10, and 5.24.12?
> > (1.b) If the answer to (1) is "No", then what is the exact
> definition and
> > how the sentence "A local Fault condition is recognized by
> the PCS Rx
> > process whenever align_status=fail" (Clause 48 P. 307) can
> be explained?
> >
> > (2) What is the condition for setting 5.8.11 (P.233): Is that user
> defined?
> > If not what is the definition of the event: "..the DTE-XS
> Has detected an
> LF
> > condition on the Tx path"
> >
> > Thx. for your help,
> > Boaz
> >
> > > -----Original Message-----
> > > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > > Sent: Friday, July 20, 2001 1:08 AM
> > > To: Boaz Shahar
> > > Cc: HSSG (E-mail)
> > > Subject: Re: [802.3ae] D3.1 Clause 45 and Clause 48 potential
> > > inconsistencies
> > >
> > >
> > >
> > >
> > > Boaz,
> > >
> > > Boaz Shahar wrote:
> > > >
> > > > Hi there,
> > > > I would like to clarify certain things regarding LF, RF and
> > > Link Status:
> > > >
> > > > 1.Status bit 5.1.7 suppose to to be set by the transmitter
> > > if it detects a
> > > > LF sequence in its input OR set by the receiver if it
> > > detects LF in its
> > > > inputs? I think it is NOT set if the receiver detects inter
> > > lane miss
> > > > alignment condition (That is, it is not set by the receiver
> > > if the receiver
> > > > GENERATES LF as opposed to DETECTING LF). Is that so?
> > >
> > > I don't think so. Bit 5.1.7 says it is an "OR" function of bits
> > > 5.8.11 and 5.8.10. The first sentence of the 5.8.11 definition
> > > says that this bit "indicates that the DTE XS has detected a
> > > local fault condition on the transmit path". Also, the RS never
> > > generates the LF sequence so the DTE XS transmit path can never
> > > see the LF sequence. The first sentence of the 5.8.10 definition
> > > says that this bit "indicates that the DTE XS has detected a
> > > local fault condition on the receive path". I don't see any
> > > mapping from the local fault conditions in clause 48 to either
> > > of these bits. This should probably be fixed with a comment of
> > > some sort.
> > >
> > > >
> > > > 2.The term "DETECT LF" stands for detecting LF sequence in
> > > the input to a
> > > > certain function? If a receiver detects miss alignment, and
> > > generates LF as
> > > > a result, it is not said to be LF DETECTION event?
> > >
> > > I disagree. A receiver that is not in sync or alignment is
> > > certainly detecting a local fault. The definition for the DTE
> > > XS transmitter is implementation specific. Recall that transmit
> > > is in the opposite direction for the PHY XS as it is for the
> > > DTE XS or the 10GBASE-X PCS.
> > >
> > > >
> > > > 3. Status bit 5.8.11 detects LF on the transmit path of the
> > > DTE-XS. That is,
> > > > set by the transmitter when it detects an LF sequence in
> > > its input in the
> > > > DTE-XS. Bit 4.8.11 does the same for the PHY_XS. But here,
> > > transmit path
> > > > means that the PHY-XS XAUI Receiver has to set this bit.
> > > So, according to
> > > > the current definition, depending on this XGXS function,
> > > PHY-XS or DTE-XS,
> > > > this bit is set by different modules in any of the cases.
> > >
> > > This was what I was trying to say above. However, these bits
> > > are not set when upon detection of LF sequences, only when the
> > > data path is not yet operational. When the data path is
> operational,
> > > LF sequences are simply forwarded along without any mention to
> > > management until they get to the RS where they are noted.
> > >
> > > >
> > > > 4.The same is true for bits 5.8.10 vs. 4.8.10
> > > >
> > > > It would be better to define:
> > > >
> > > > 5.8.11 as Tx path LF Detection for DTE-XS
> > > > 4.8.11 as Rx path LF Detection for PHY-XS
> > > > 5.8.10 as Rx path LF Detection for DTE-XS
> > > > 4.8.10 as Tx path LF Detection for PHY-XS
> > > >
> > > > BTW this method works in all other cases of symmetrical
> > > functionality
> > > > between PHY-XS and DTE-XS because it saves a MUX in the
> > > implementation, and
> > > > more consistent.
> > >
> > > This issue has been discussed before and the draft reflects
> > > how it was settled. If you want to raise the issue again, you'll
> > > have to submit a comment against the next draft.
> > >
> > > Regards,
> > > Ben
> > >
> > > >
> > > > CLAUSE 48 Question
> > > > Section 48.2.5.4.1 defines local_fault as follows: "A local
> > > fault condition
> > > > is recognized by the PCS whenever align_status=fail".
> Combining this
> > > > definition with those in clause 45 can lead to the
> > > erroneous conclusion that
> > > > the events "Link Status Fail" and "Local fault detection"
> > > are identical. So
> > > > I think it should be changed either in 45 or in 48 (Unless
> > > this is really
> > > > the intention).
> > > >
> > > > Best regards,
> > > > Boaz
> > >
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > AMCC
> > > 2 Commerce Park West
> > > Suite 104
> > > Bedford NH 03110
> > > 603-641-9837 - Work
> > > 603-491-0296 - Cell
> > > 603-626-7455 - Fax
> > > 603-798-4115 - Home Office
> > > bbrown@xxxxxxxx
> > > -----------------------------------------
>
> ---------------------------------------------------------
> Richard Taborek Sr. Intel Corporation
> XAUI Sherpa Intel Communications Group
> 3101 Jay Street, Suite 110 Optical Products Group
> Santa Clara, CA 95054 Santa Clara Design Center
> 408-496-3423 JAY1-101
> Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
> Fax: 408-486-9783 http://www.intel.com
>