Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistenc ies

I think that in this case the Draft should be written
in a better way. Following this thread, I think that
the term "detect a local fault" is defined in a very
general and not accurate way. And even you admitted
that there is an un-necessary duplication. You may fix
it or not; But the problem is not "misreading the
spec" as you wrote. As a matter of fact, I think it
was read very carefully. I think that you should be
thankful for such comments.


> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1)
> 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
> 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
> 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
> fault condition is
> detected.
> Regarding your question about the apparent
duplication of local fault
> reporting bits. I have never understood why in
> register 1 we have a
> bit that indicates that the receive link is up while
> 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
> the other still
> is latched.) The duplication has fallen below my
> 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
> 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
> 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 

Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger