Re: Cls. 48 PCS receive state diagram
Bob, Mario,
State diagrams take precedence over text, the two are not intended to be
equivalent. The text should not be incorrect, but need not be equivalent
to the state diagrams. The intention of the text is to provide a general
guideline of PCS receive process operation.
My take on this issue is that the intention of check_end is to ensure
that errors within the packet are detected within the packet. Since the
situation described already errors out the packet at least at the PCS
level, calling the check_end function is not required.
My sense is that no change is necessary.
Best Regards,
Rich
--
Bob Noseworthy wrote:
>
> 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.
>
> ------------------------------------------------------------------------
> Name: 010426_cls48_altfig48-9-optionB.pdf
> 010426_cls48_altfig48-9-optionB.pdf Type: Acrobat (application/pdf)
> Encoding: base64
>
> Name: 010426_cls48_altfig48-9-optionA.pdf
> 010426_cls48_altfig48-9-optionA.pdf Type: Acrobat (application/pdf)
> Encoding: quoted-printable
>
> Name: 010426_cls48_altfig48-9-optionC.pdf
> 010426_cls48_altfig48-9-optionC.pdf Type: Acrobat (application/pdf)
> Encoding: quoted-printable
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Products Group
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com