• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 34 subscribers
  • Views 131 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83TG720S-Q1: confíguring different loopback modes to tests the RX and TX interface

Alexander Schallert
Prodigy 60 points

Part Number: DP83TG720S-Q1

We are currently developing an interface to the DP83TG720S-Q1 on the TRION 85.

To do different tests with just one PHY we try to use the different loopback modes of the PHY.

We could manage to send test-frames generated by the PHY itself to the RX[3:0]-interface. Our timing is now working with sampling the data.

We now try to send our own data through the TX[3:0] interface and receive it on the RX[3:0]. We try to configure the digital loopback mode without data-generation, so that the PHY should use the TX data.

This does not work, could you please tell me which registers I have to configure through the MDIO interface.

  • BMCR <= 0x8000 ... HW reset
  • MII_REG_1F <= 0x8000 ...  SW reset
  • 0x018C <= 0x0001 ... turn off sleep
  • 0x1834 <= 0x4000 ... set master
  • 0x0602 <= 0x0002 ... turn on RX delay
  • 0x0430 <= 0x0090 ... set delay on RX
  • MII_REG_1F <= 0x4000 ... digital reset


  • MII_REG_16 <= 0x0104 ... turn on digital loopback
  • 0x0800 <= 0x0800 ... bit11 as described in the datasheet

when we also configure the PRBS registers we can see the generated data on the RX signals. When we want to see our TX signals it does not work. Which configuration registers do we have forgotten?

 

Thanks

Alexander

  • 0
    TI__Genius 11510 points

    Hi Alexander,

    Regarding your last point, how and where are you probing to check for the RX and TX signals?

    Best regards,

    Greg

  • 0
    Prodigy 60 points

    We found this problem, the CLK signals were not connected correctly. We can now send and receive data packages. 

    Now we see that the send-data-package and the received one are delayed by about 6µs. Why is it like that? 

    on page 15 of the datasheet we found this information:

    RECEIVE LATENCY TIMING
    ---------------------------------------------------------------------------------------------------------------------------
    SSD symbol on MDI to Rising edge of RGMII RX_CLK with assertion of RX_CTRL    |  8 μs |
    ---------------------------------------------------------------------------------------------------------------------------

    how can we make this faster?

    best regards

    Alexander

  • 0 in reply to Alexander Schallert
    TI__Genius 11510 points

    Hi Alexander,

    Glad the initial problem was fixed. Could you please clarify what timing delay you want to achieve, and for what purpose you want to go lower than the current receive latency timing?

    Best regards,

    Greg

  • 0 in reply to Gregory Kobyakov
    Prodigy 60 points

    we want to setup our new bus interface like the ethercat system but 10 times faster. so we thought to implement single pair ethernet would solve the problem. also long distances is a request of our customers. Ethercat 100Mbit -> single pair ethernet 1Gbit

    now with the first tests we have seen that the receiving bus coupler is not sending the received data immediatly to the RX-port like the sending PHY is not sending the data just when it gets the data through the TX-port.

    like it is mentioned in the data sheet it takes up to 8µs to send or decode the data from the bus.

    can this decoding time made faster?

    best regards

    Alexander