• State
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 67 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DP83822I: Extra-long packet causes descrambler to lose lock

Gordon Leather
Prodigy 100 points
Part Number: DP83822I


We are experimenting with very long (non-802.3 compliant) packets over 100BASE-T physical layer, and see the descrambler on the destination PHY loses lock after ~18,600 octets of payload.

The DP83822 PHY is configured as RMII Master, elastic buffer bypass (recovered clock mode), and the recovered 125MHz clock is appearing as expected on RX_D3.

For this test, every nibble sent to the PHY is 0x2, which should provide perfect DC-balance after the PCS (4B/5B code “10100”).

Cables are good, there is no EMI interference, tested in lab conditions.

The system performs perfectly when sending legal Ethernet frames.

 

  1. Given an ideal incoming signal, what could cause the descrambler to lose lock?
  2. Should it in theory be possible to transmit / receive an infinite packet, at the PHY level?

 

Best regards,
Gordon

  • 0
    TI__Mastermind 19716 points

    Hi Gordon, 

    What is the ppm of the XI clock into DP83822?


    If it is 100ppm, this can be the reason why the descrambler is losing the lock.
    Theoretically, the PHY can receive/transmit an infinite length of packet but this is not realistic because of RMII FIFO and FIFO has a max size it can support on the PHY. 

    Best,
    J

  • 0
    Prodigy 100 points

    Hi J,

    Thank you for the quick response.  The XI clock is 20ppm.

    My understanding is that the RMII FIFO is not used in RMII recovered clock mode. Isn't this configuration to allow a synchronous Ethernet configuration?

    Reg 0x0017 is set to 0x0021, so b6 (RMII Recovered Clock Async FIFO Bypass) is '0' which bypasses the FIFO. 
    We see the 50MHz RX_CLK output from the DP83822, indicating the PHY recognises the configuration.
    There is no indication of RX FIFO Overflow or Underflow (b[3:2]) when we read the register.

    For that matter, there are no fault indications showing in the entire register map after the lock-loss occurs, other than the de-scrambler lock loss bit (reg 0x0010, b9).

    Best regards,
    Gordon

  • 0 in reply to Gordon Leather
    TI__Mastermind 19716 points

    Hi Gordon, 

    I see. Your understanding is correct that RMII FIFO is not used in the RMII recovered clock mode. Only configuration needed for syncE is the 125MHz to be outputted. 

    The PHY was only tested up to 13.5k bytes of packet so the current size of packet you are testing may be too big for our PHY. 

    Please refer to the link below on what our PHY was tested up to:
    DP83867CS: Jumbo Frame support - Interface forum - Interface - TI E2E support forums

    Best,
    J

  • 0 in reply to J
    Prodigy 100 points

    Hi J,

    Thank you.  I appreciate we are pushing the part beyond spec - but am still curious as to what could cause the de-scrambler to lose lock.  It seems to consistently fail at 18.6kB, irrespective of buffer size or other parameters we have played with, so the issue feels digital rather than analogue. 

    Are there any internal counters that reset the de-scrambler, that could cause lock-loss?

    Best regards,
    Gordon

  • 0 in reply to Gordon Leather
    TI__Mastermind 19716 points

    Hi Gordon, 

    Unfortunately, there are no internal counters that I am aware of that can cause descrambler to lose lock. It does seem to be an analog issue, and I suspect there may be an internal buffer for descrambler that is overflowing. And such overflow may cause the PHY to consistently fail at 18.6kB. I suggest to keep the packet size within 13.5kB as that was the max packet size validated on our end. 

    Best,
    J