This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867CS: size-dependent packet loss with minimum IPG

Part Number: DP83867CS
Other Parts Discussed in Thread: DP83867CR,

We'd like to understand the minimum IPG supported by this part.  Based on a forum post for the similar DP83867CR (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/935578/dp83867cr-rgmii-minimum-idle-per-ipg), it appears it may be 12B.  I see some room for interpretation, but I would argue 802.3 requires 8B support for 1000BASE-T.

Specifically, we're seeing issues with 10B IPG which we can influence, but not fully resolve with changes to the VTM_IDLE_CHECK_CNT_THR register field.

With an external Ethernet tester configured for 12B IPG, we see packet loss for packet sizes modulo 4 of 2 and 3 (for instance, 64/65B are functional, 66/67B fail).  Functional sizes show an IPG of 10B (on our IP's Rx GMII interface), so we believe the tester is encroaching the IPG.  This is with the default VTM_IDLE_CHECK_CNT_THR value of 0x5.

When we decrease VTM_IDLE_CHECK_CNT_THR to 0x4 (based on the presumed 10B IPG), we see loss only for packet sizes modulo 4 of 3 (for instance, 64-66B are functional, 67B fails).

We further decreased VTM_IDLE_CHECK_CNT_THR to 0x3 (undocumented) and see infrequent errors, (as yet) uncorrelated to packet size.

Thanks for your help!

Chad

  • Hello 

    Thank you for the query.

    If i read through the query, you are looking to understand the minimum IPG supported by the device.  Please let me know if my understanding is correct.

    I believe the thread you have linked has the answer but based your clarification would help to review further.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    That's correct.  Per the datasheet (VTM_IDLE_CHECK_CNT_THR documentation), we expected the part to support <12B, but we seem to be running into the issues I described.

    Specifically in regard to the linked thread, we'd like to understand the minimum supported IPG in SGMII mode with VTM_IDLE_CHECK_CNT_THR set to 0x4.

    Thanks,

    Chad

  • Hello Chad,

    Thank you for the inputs.

    See below and seems like this is what you are observing. Lower IPG may not be supported in all modes and all packer sizes.

    The IEEE standard for IPG is 12 bytes. The DP83867 does not support a lower IPG in all modes below that. In normal operation the DP83867 will support a minimum IPG of 12 bytes and can support lower in some packets settings but because this is outside the IEEE standard not all settings can be tested. 

    What IPG and packet requirements are you looking at,  for the device  to perform: is the below requirements you are looking for

    Specifically in regard to the linked thread, we'd like to understand the minimum supported IPG in SGMII mode with VTM_IDLE_CHECK_CNT_THR set to 0x4.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    Thanks for your help!  Correct, we'd like to understand the limits in SGMII mode with VTM_IDLE_CHECK_CNT_THR set to 0x4 for arbitrary packet size.  We presently have imperfect visibility, but it seems our external tester is producing a 10-11B IPG when we configure for 12B.

    I think there's a little room for interpretation w.r.t. the physical layer, but 802.3 does specify an 8B minimum for 1Gb/s at the MAC (NOTE 3 in sec. 4.4.2 of 802.3-2018) and our external tester seems to support this.

    Thanks,

    Chad    

  • Hello Ched, 

    Thank you for the inputs. Let me check if there is any data that exists.

    Would it be possible to provide me some inputs on the use case and the need to reduce the IPG.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    This is an ASIC prototyping application and we'd like to support an arbitrary customer PHY.  Our "known good" external tester is generating <12B when we configure for 12B and 802.3 seems to allow this (down to 8B, admittedly some interpretation required).

    We'd like to understand the limits of the DP83867CS and optimal value for VTM_IDLE_CHECK_CNT_THR in order to document our limitations and maximize interoperability.

    Thanks,

    Chad

  • Hello Chad, 

    Thank you for the inputs.

    I will have to go back to design or validation to check if we have some data. I will comeback to you at the earliest possible time with any available information but do not have a timeline.

    Please let me know if you have any thoughts.

    Regards,

    Sreenivasa

  • Hello Chad, 

    We do not have additional data on the IPG delay.

    Regards,

    Sreenivasa