Re: Cls. 48 PCS receive state diagram
Mario,
The change proposed by Bob and modified by you sounds good and is likely
to be closer to what actual implementations do than what is currently
specified. Please submit a comment.
Best Regards,
Rich
--
"Stoltz, Mario" wrote:
>
> Bob,
>
> in my opinion state diagram modification option C looks the best. It is the
> most clear and structured. I would propose three minor changes, though:
> 1) make the condition for transition from RECEIVE to IDLE_MODE
> "[||IDLE||]+AUDI([||Q||])";
> 2) rename IDLE_MODE state to IDLE_OR_Q_MODE
> 3) replace the operations "RXD <= 0h07070707 and RXC <= 0b1111" inside that
> mode with "RX <= DECODE([||y||])"
> This way, we have the receive process separated into the state with
> check_end and cvrx_terminate performed (left side of diagram) and the state
> without these (right side). The problem you point out with check_end being
> constantly performed during ||Q|| reception would disappear.
> In a hardware implementation, the three state diagram modifications would
> most probably look the same way in silicon anyway. So, to me this mostly
> seems a question of clear presentation of the way the receive process is
> supposed to work.
>
> What remarks or doubts about my proposed changes above do you have - or
> should I submit a comment right away?
> Kind regards,
> Mario.
>
> -----Original Message-----
> From: Bob Noseworthy [mailto:ren@xxxxxxxxxxx]
> Sent: Donnerstag, 26. April 2001 20:55
> To: Stoltz, Mario; stds-802-3-hssg@xxxxxxxx
> Cc: Eric Lynskey
> Subject: RE: Cls. 48 PCS receive state diagram
>
> 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.
--
Best Regards,
Rich
---------------------------------------------------------
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