RE: Cls. 48 PCS receive state diagram

["Bob Noseworthy" <ren@xxxxxxxxxxx>]

Mario,
  You are correct in pointing out a descrepancy between the text of the
draft and figure 48-9.
I am not convinced that modifying the state machine is necessary or
preferable at this point, as the text in the DECODE function could be
reworded by replacing "When decoding ||T||,..." with "When DECODE is called
from the TERMINATE state,..." and/or similar ammendments.

However, modifying the state machine would allow an accurate error count to
be made. By the current method, since check_end is not being used, errors in
or past ||T|| would not be conveyed to the MAC.
Also, by the current method, ||T|| would not be converted via the
cvrx_terminate function.  I don't believe this presents a problem as IPG
starts at /T/, but perhaps someone could correct me if I'm wrong.

State Machine modification Option A- (see attached PDF)
This is the most minor change, which allows cvrx_terminate to be called
properly, and check_end would catch any errors propagating past ||T|| -- but
since DATA_MODE_OTHER doesn't call check_end, then errors propating past /T/
in ||T|| would not be caught.

State Machine modification Option B- (see attached PDF)
Option A could be modified by adding check_end to the DATA_MODE_OTHER state,
but then check_end would be called constantly during ||Q|| reception.  That
could be avoided by adding a "Q_MODE" state that would be entered when ||Q||
is received and just call DECODE.  This should result in all errors within
the frame to be reported to the MAC.

State Machine modification Option C- (see attached PDF)
Unlike Option B which adds states, this removes two states and simplfies the
state machine.  This option still has check_end running even when ||Q|| is
being received (cvrx_terminate should only be called when ||T|| is
received).  But all errors in or past ||T|| would be conveyed to the MAC.


Thoughts?

- Bob Noseworthy and Eric Lynskey
  Co-editors of clause 48, along with those Rich and Rhett guys.

PS: Ignore the headers and surrounding text in the attached PDFs, I used my
D2.1 framemaker file as the basis for these modifications.


> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Stoltz, Mario
> Sent: Thursday, April 26, 2001 10:18 AM
> To: 'stds-802-3-hssg@xxxxxxxx'
> Subject: Cls. 48 PCS receive state diagram
>
>
>
> A question about the Clause 48 (10GBASE-X) PCS receive state
> diagram on page
> 307 of Draft 3.0:
>
> According to the state diagram, once in DATA_MODE_START state and decoding
> data, any |E| character received will lead back to the RECEIVE state. From
> there, there is no way to check for a |T| character in order to
> execute the
> check_end and cvrx_terminate functions. Normal operation is only resumed
> again once the next frame is started by the next valid |S| character which
> is detected from RECEIVE state.
>
> In the current _text_, though, the definition of the DECODE([||y||])
> function (48.2.5.1.4) states that it (the DECODE function) calls the
> cvrx_terminate and check_end functions if it decodes a |T|, no matter what
> state it is in.
> Similarly, the description of the PCS receive process
> (48.2.5.2.4) does not
> mention that the "mode during packet reception" is to be abandoned because
> of the reception of an |E| character.
>
> In this respect, the text and state diagram seem to contradict each other.
> Is this impression correct? Which behavior is the one that was
> agreed upon?
>
> Kind regards,
> Mario.

010426_cls48_altfig48-9-optionB.pdf

010426_cls48_altfig48-9-optionA.pdf

010426_cls48_altfig48-9-optionC.pdf