RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistencies
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