|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
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 (18.104.22.168.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 > (22.214.171.124.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.