Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Cls. 48 PCS receive state diagram




Mario,

I like C without the additional changes. There isn't any problem with check
end being called during ||Q|| reception. Actually, if there is a disparity
in the column after the ||Q||, it can be the result of errored bits in the
||Q|| so check_end is applicable. Check_end isn't essential after a ||Q||
because the RS will not recognize a ||Q|| until it has seen three matching
ones, but it certainly doesn't hurt.

Secondly, RX<=DECODE([||y||]) wouldn't be right for Idle because decoding y
would produce a column of A, K or R. We want to replace the A, K or R column
with a column of idle.

Pat

-----Original Message-----
From: Stoltz, Mario [mailto:mario.stoltz@xxxxxxxxx]
Sent: Friday, April 27, 2001 1:00 AM
To: 'Bob Noseworthy'; stds-802-3-hssg@xxxxxxxx
Cc: Eric Lynskey
Subject: RE: Cls. 48 PCS receive state diagram



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.