Re: Question about Link Fault Signalling
I updated the figure to include Ben and Steve's comments.
Ben, your suggestion of going directly from LFstate to OK
state on receiving Idles or other valid xgmii characters makes
sense - the only potential issue is loss of the first packet : When
the local end is in LFstate, the remote end will enter into the RFstate.
By making the local end go through the RFstate before going to the
OK state (and start sending packets), we will force the local end to
send some idles prior to data, giving a chance for the remote end to
enter the OK state and receive the first packet. For the same
reason Steve, maybe we need to transition from the RFstate to
OK state on reception of as few valid characters as possible - only
4 idles (m=2) in the diagram. I am thinking that this brief transit thru
the RFstate is ok, as we would want to anyway put in hysterisis to
prevent initiation of RF diagnostics on transient errors.
Dave's comment about garbage on XGMII is interesting. This could
happen when XGMII is an exposed interface. Logically
garbage on XGMII should be treated as local fault detected by RS.
But this would mean having a decoder at the RSfront end to parse the
XGMII to see what is valid and what is not. If we dont want to
build this decoder (the MAC itself is one), then we can stay in the
current
state as Dave suggests and hope that that if this persists then the
higher
level system manager will detect (based on high number of packet errors)
and investigate.
regards,
Birdy
-----------------------------------------------------
From: Stephen.Finch@xxxxxx
Ben,
I liked the idea of going from LF to RF to OK when the RS starts
receiving either RF's or Idles. This insures that "m" Idles will be
sent before enabling packets as the exist of RF is V(m).
Birdy, Thanks for putting it down so clearly.
Ben's suggest of a LF loop back to the LF state for completeness is a
good one. I would suggest we call the states LF and RF states a
different name than the event that causes the transitions, maybe LFRcvd
and RFRcvd. I'm not stuck on the names, mind you.
The transition from V to RF has RF(p). I would suggest RF(n) as a
better value. Fast entry in to an the error states with some protection
(limited I admit, but sufficient) against false entry sounds good
I suggest that [RF|I](p) and V(m) use the same subscript: [RF|I](m).
I think the value for n should be 2. I think the value for m (and p)
should be greater than 2. I could live with 2, but 4 "feels" better and
since we are recovering from an error condition, a couple of extra
"events" extra isn't a huge enough burden to worry about.
Steve Finch
------------------------------------------------------
From: "David Gross" <dgross@xxxxxxxxxxxxxxxxxx>
Birdy,
Thanks for the diagram, it's always better to look at somehting than
imagine it :)
There is one thing though, what if an ERROR codeword(s) is(are) recieved
(which doesn't fit into any of the catagories you mention, except maybe
V)? Do we want to transition from states upon recieving ERRORs -
assuming they're considered V's, them m of them? Since the Error can be
replacing anything, including RF, I think it might make sense to stay in
the current state if they are recieved. What do you think?
-Dave
-------------------------------------------------------
Birdy,
Thanks for the picture! However, a few questions...
Why would we falsely report RF without ever detecting RF
as the transition from state LF to state RF depicts upon
the detection of IDLE. I might suggest some changes:
Change the transition from state LF to state RF by removing
the condition I.
Add a transition from state LF to state V on the condition
I (or would this be condition V?).
For completeness, I'd add a loop from state LF back to
itself on the condition LF.
Regards,
Ben
--
rsstate.pdf