DP83867IR: RXERR and TXERR in RGMII, full-duplex mode

Hi Takahashi-san,

These error bits will be asserted on RX_ER or TX_ER condition, sampled on falling clock edge.

For example on RX-side - if receive data is valid with no receive error:

Clock rising edge -> RX_CTRL = High (indicates valid data)
Clock falling edge -> RX_CTRL = Low (indicates no receive error)

If receive data is invalid with receive error condition:

Clock rising edge -> RX_CTRL = Low (indicates invalid data)
Clock falling edge -> RX_CTRL = How (indicates receive error)

Do I understand your question correctly? If you are referring to RX_ER / TX_ER pins and not RX_CTRL, these are not applicable to RGMII.

Thank you,
Evan

Hi Evan-san,

Thank you for your reply.

I apologize for the lack of explanation.

I would like to know the relationship between RXERR and TXERR assertion and duplex.

Can RXERR and TXERR be asserted high even in full-duplex mode?

The customer's understanding is that RXERR and TXERR can only be asserted high in half-duplex mode.

Hi Takahashi-san,

I am checking to confirm this.

Atsushi Takahashi said:

The customer's understanding is that RXERR and TXERR can only be asserted high in half-duplex mode.

Can you share more information about where this understanding comes from?

Our device is compliant with RGMII specification, but I cannot find any supporting information in spec to suggest RX_ER / TX_ER cannot be asserted in full duplex:

/cfs-file/__key/communityserver-discussions-components-files/138/6661.RGMIIv1_5F00_3.pdf

Thank you,
Evan

Hi Evan-san,

Sorry for my late reply.

The customer think that since collisions don't occur in full duplex, RX_ER/TX_ER are not asserted.

Is this understanding incorrect?

Please let me know if there are any specifications that would cause the error bit to be asserted for reasons other than collisions.

Hi Takahashi-san,

Collision is not the only condition of RX_ER/TX_ER flag. Any time PHY is unable to decode an invalid signal, error will flag.

Thank you,
Evan

Hi Evan-san,

Thank you for your reply.

1) I would like to know some concrete examples of errors other than collisions.

Is my understanding of the following correct?

- Errors caused by noise on the transmission path

- Incorrect frame format (alignment, size)

- CRC error

- Buffer overflow

- Invalid pattern detection

2) What document can I find more information about error flags?

If it's IEEE 802.3, please point me to the appropriate section.

Atsushi Takahashi said:

- Errors caused by noise on the transmission path

- Incorrect frame format (alignment, size)

- CRC error

- Buffer overflow

- Invalid pattern detection

I agree with these possible causes for error flagging. I will check standards and look for more supporting information.

Thank you,
Evan

Hi Evan-san,

Do you have any update?

If you know where we can find more information about the error flags, I would appreciate it if you could tell me.

Hi Takahashi-san,

Apologies, it is taking extended time to review standard and confirm. Do you have access to 802.3 standard?

Please expect feedback within 1-2 days.

Thank you,
Evan

Hi Evan-san,

Thank you for your response.

It was very helpful.

I look forward to your continued support.