Re: Error handling in 64/66: Was Re: (Another) Question Regarding Open-Loop
Hi Birdy,
Please see comments below.
Bharadwaj S Amrutur wrote:
>
> Hi David,
>
> Your pdf suggests that in the E state, check to see if the previous state
> is a T before allowing a transition from E-> S.
> This doesnt work. Consider the situation where,
> DDDDTSDD has 1 bit error in S sync, and 2 bit error in the following D and
> gets converted to
> DDDDTESD due to a 3-bit error. What you proposed will let this through.
This isn't true according to what I had in mind. The condition to go to
the S state from the E state requires that the previous value is a valid
T state. In this case (and the cases you mention below, the 1 bit error
in sync causes the previous value to not be a valid word (T or
otherwise) and the E->S transition is prevented.
Just to clarify because I think there might be some confusion, in your
example, for an E->S transition, the current state is what "appears" to
be an S, and the previous state is what was actually the 1-bit sync
error.
>
> Other similar cases are:
> ZZZZZSDDD getting converted to
> ZZZZZESDD or:
>
> DDDDDDDD getting converted to
> DDDDESDD
>
> If you really want to allow for a E->S transition, I would suggest:
> In the E state, if (prev state was also E), then allow a transition
> from E to S. Because it takes atleast 2 bit errors to be in E state for
> two consecutive cycles (in the new state m/c where we allow
> transitions from E to Z,T and D) and it would take an additional 2bit error
> to falsify a D into an S giving 4bit protection. (Maybe this is what you
> had in mind and your pdf has a typo ?) You can also do something similar
> on the T end to preserve symmetry. i.e., accept a packet in situations like
> DDDTE(E+).. , whereas the current state m/c rejects it.
>
> The question is what do we buy in return? If link bit error rates are low
> enough,
> the modified state m/c with E-> S transition will result in a negligible
> improvement
> in the packet throughput. Also the link error monitoring is only marginally
> improved.
My only concern was that if minimum IPGs are constantly being
transferred to maximize the data rate then it is possible that it would
take a significantly long period of time to exit the Error state using
the current convention (no 64b/66b Z codeword will be found for a while
if at all). By allowing a min IPG to be 9 and by allowing the T->S
transition, it seems that the schematic also allows for the possibility
that only T->S transitions are present (no T->Z->S) and thus even with a
very low BER, even one error can cause a case where we are stuck in the
Error state.
I'd just like some reasurance that this can't happen, either because the
state m/c won't allow it to, or because we can be reassured that it is
impossible to ONLY receive min IPGs and T->S transitions. (I actually
prefer modifying the state m/c rather than making a restriction like
this...)
Please let me know if this is a valid concern, or if I've neglected to
account for something. Thanks.
-Dave
>
> Regards,
> Birdy
>