[802.3_SPEP2P] Clause 99 comments

["Law, David" <dlaw@xxxxxxx>]

Dear all,

With IEEE Std 802.3de-2022 now approved and published (congratulations to all !!!) I wanted to circulate, what I believe, are a few potential issues with the Clause 99. I intend to submit maintenance requests to address these items in a few weeks, any comments before I do that will be very gratefully received.

Best regards,
  David

-----

[1] SMD-S received while waiting for mPacket in Figure 99-6 Receive Processing state diagram

If the Receive Processing state diagram (see Figure 99-6) is in the CHECK_FOR_RESUME state, it is waiting for the next mPacket of a preempted packet. If, however, it receives a preemptable packet start (SMD-S) instead, and the keepSafterD variable is true, it will transition to the DISCARD_KEEP_S state. The keepSafterD variable set true indicates the implementation can process the start of a packet while discarding an errored packet.

Entering the DISCARD_KEEP_S state will call the DISCARD function which forces an FCS error (issues 32 PLS_DATA.indication to the pMAC to transfer an invalid FCS value) and then calls the pRX_DV function with the parameter FALSE. This will issue a PLS_DATA_VALID.indication primitive with the DATA_VALID_STATUS parameter set to DATA_NOT_VALID to the pMAC which will cause the pMAC to terminate the incoming packet and issue a MA-DATA.indication to the MAC client.

The state diagram will then transition to the REPLACE_SMD state through the arrow to 'A' out of the DISCARD_KEEP_S state. The REPLACE_SMD state has the action pRX_DATA(SFD). This will call the pRX_DATA function with the parameter SFD issuing eight PLS_DATA.indication primitives to the pMAC to transfer an SFD.

The problem is that while a PLS_DATA_VALID.indication primitive with the DATA_VALID_STATUS parameter set to DATA_NOT_VALID was issues to the MAC due to the DISCARD function called in the DISCARD_KEEP_S state, there is no subsequent PLS_DATA_VALID.indication primitive issued with the DATA_VALID_STATUS parameter set to DATA_VALID. The pMAC will therefore not receive the SFD or the subsequent content of the packet.

The simplest fix would seem to be to add a pRX_DV(TRUE) function call after the DISCARD function call in the DISCARD_KEEP_S state. In addition, the there is no condition on the transition from DISCARD_KEEP_S to REPLACE_SMD. Suggest it should be labelled 'UCT'.

-----

[2] SMDS_ENCODE(frame_cnt) function call in SEND_SMD_S state in Figure 99-5

The SMDS_ENCODE(frame_cnt) function produces the Start mPacket Delimiter (SMD) encoding for the start of a preemptable packet (SMD-S) using the frame count supplied. The SMDS_ENCODE function is called in the SEND_SMD_S state in Figure 99-5 'Transmit Processing state diagram' with the parameter txFrame which will produce the SMD-S value, however there is no function call to pass this value to the RS for transmission.

There are two approaches to resolve this. There first is to change the SMDS_ENCODE(txFrame) function call in the SEND_SMD_S state in Figure 99-5 to read rTX_DATA(SMDS_ENCODE(txFrame)). The second is to change the description of the SMDS_ENCODE function to include 'Produces eight rPLS_DATA.request primitives based on the 8-bit vector.' as the similar SMDC_ENCODE(frame_cnt) function does. I personally favour the latter approach.

-----

[3] Subclause 99.4.7.1 State diagram conventions

IEEE 802.3-2022 subclause 99.4.7.1 'State diagram conventions' says that 'The notation used in the state diagrams follows the conventions of 21.5.'. Subclause 21.5.1 'Actions inside state blocks' says that 'The actions inside a state block execute instantaneously. Actions inside state blocks are atomic (i.e., uninterruptible).' and 'After performing all the actions listed in a state block one time, the state block then continuously evaluates its exit conditions until one is satisfied, at which point control passes through a transition arrow to the next block.'.

There is, however, a conflict between this state diagram notation, and the time taken to complete the functions called inside some of the states in Clause 99. Take the example of the START_PREAMBLE state in Figure 99-5 'Transmit Processing state diagram'. On entry to the state the rTX_DATA function will be called with the parameter pTX_DATA. This will generate eight rPLS_DATA.request primitives based on eight pPLS_DATA.request primitives, in summary either bits will be sourced from the pMAC and passed to the RS.

While the rTX_DATA function call itself could conceptually be instantaneous, as required for an action in a state by the state diagram convention, the function itself will take a finite time to complete as the rate at which rPLS_DATA.request will be services by the RS will be determined by the bit transmit time.

The state diagram convention however states that after executing the action inside a state, the exit conditions are evaluated until one is satisfied, at which point control passes to that state. In this case the exit conditions !SFD_DET and SFD_DET are evaluated, and since only the first byte of preamble has been sourced from the pMAC, the exit conditions !SFD_DET will be true. As a result, the START_PREAMBLE state will be re-entered instantaneously and the rTX_DATA function will be called again. This will be before the RS has had a chance to service the rPLS_DATA.requests from the previous call.

There are two approaches to resolve this. There first is to add some sort of control to stop a state from being exited until any function(s) called within that state complete. This would mean adding exit conditions of the form x_done where x_done is defined as the function x having completed. The second approach would be to change the state diagram conventions for Clause 99 to say that the functions called within a state have to complete before the exit conditions from the state are evaluated. I personally favour the latter approach.

-----

[4] rRxDV variable in Figure 99-6 Receive Processing state diagram transitions

In Figure 99-6 there appears to be a typo in the transition conditions from INIT_RX_PROC to IDLE_RX_PROC and from IDLE_RX_PROC to pMAC_DATA_VALID. Both use the variable rRxDv (lower case 'v'), whereas the variable is defined as (see subclause 99.4.7.3), and used elsewhere is, rRxDV (upper case 'V').

-----

[5] Subclause 99.3.6 CRC

It appears that the mapping of the mCRC value into the CRC field is not defined. Since the mCRC value is calculated using steps a) through d) of subclause 3.2.9, it is reasonable to assume that the mapping is the same as subclause 3.2.9, but this should be stated.

-----

[6] Subclause 99.4.7.3 Variables

Just an inconstancy, but the pTX variable (pPLS_DATA.request has been received and a corresponding rPLS_DATA.request has not yet been generated) uses an upper case 'X', whereas the eTx variable (ePLS_DATA.request has been received and a corresponding rPLS_DATA.request has not yet been generated) uses a lower case 'x'.

________________________________________________________________________
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1