Re: Error handling in 64/66: Was Re: (Another) Question Regarding Open-Loop
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.
Other similar cases are:
ZZZZZSDDD getting converted to
DDDDDDDD getting converted to
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
the modified state m/c with E-> S transition will result in a negligible
in the packet throughput. Also the link error monitoring is only marginally
David Gross wrote:
> Hi Birdy,
> I've thought about this case some more, and I beleive we can go from the
> E state to the S state without allowing a 3-bit error condition to occur
> by simply adding a variable to the TX and RX processes respectively. If
> we have a variable which stores the previous input (eg: rx_prev <=
> rx_tobe_decoded) then we can use it as a qualifier to know whether or
> not the transition from the E state to the S state is valid. In the case
> of the 3-bit error you mentioned where a preamble error causes a jump to
> the E state, and a 2 bit error in preamble causes data to look like S,
> then the qualifier will catch this and not allow the E to S transition.
> I've attached a pdf to further descibe the implementation I was thinking
> of. The actual modifications needed are shown in red. Please let me know
> what you think, I think this may work.
> Bharadwaj (Birdy) Amrutur wrote:
> > >Yes you're right, I must have been looking at an older slide deck. But
> > >now that I see the new TX process and RX process, I have another
> > >question. If you allow for the sequence TZZZZZZZ ZZZZSDDD, what happens
> > >if you get an error somewhere. It would appear as if the condition to
> > >get out of the error state is to wait for ZZZZZZZZ, but this won't
> > >appear between frames given the above circumstance and the next frame
> > >will also be "errored". Perhaps I'm mistaken, but it would seem as if
> > >the next perfectly good frame will be trashed? Is this correct?
> > >
> > >-Dave
> > Dave, Your observation is correct. The way the state m/c is right
> > now, if there is a error, it doesnt get out of the E state till
> > a clean Z frame. A problem with this is if you have back to back
> > packets with min IPG spacing, you might end up with a S frame
> > immediately following a T frame and there wont be any intermediate
> > Z frame for a while.
> > We probably should modify the state diagram by allowing transitions
> > from E state to Z, D, or T states. (We need to disallow transition
> > from E to S to prevent a certain 3-bit error condition from
> > slipping through).
> > Regards,
> > Birdy Amrutur
> Name: SeqProcSug.pdf
> SeqProcSug.pdf Type: Portable Document Format (application/pdf)
> Encoding: base64