Re: Question about Link Fault Signalling
Birdie,
I agree with Ben's suggestion of going directly from state LF to state
OK upon condition Vm. My reasoning is that condition Vm means that the
Fault condition and/or message no longer exists. When this happens, the
Link Status bit changes from FAIL to OK. I presume that there is some
inherent delay in the issuance of Packets across the link which has just
become operational. This delay is filled with Idles since there's
nothing else to transmit. The potential loss of a packet is this
scenario is pathological and Ben's suggestion makes the state machines
simpler and more straightforward. Note that Ben's suggestion also
removes the condition I from the transition from state LF to state RF.
I suggest that "error" be included in V along with idle, start, data and
terminate. Error should not be considered a Fault condition and should
not invoke LF/RF protocol. Fault conditions denote a more serious class
of errors than do error control codes on the XGMII.
Best Regards,
Rich
--
"Bharadwaj S. Amrutur" wrote:
>
> 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.
-------------------------------------------------------
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