DP83867IR: Loop back failed, I want to know if it can be adjusted to the clock falling edge trigger data?

Hi Aniruddha,

The current scene is two mutual exchanges, the sampling clock is 100M;

10M Ethernet is ok, when rx / tx clk is 2.5M

100M Ethernet does not work when rx / tx clk is 25M. At this time, rx error will be reported. It is found that rx ctrl is high at the last beat and the falling edge becomes low.

Is this what is the reason

Figure 1 is the waveform of the oscilloscope, Figure 2 is the waveform captured inside the FPGA, RX_CTRL duration, about 5738ns (71.5 RX_CLK)

Can you send me a capture for the 10M case when it is passing please?

I would like to see RX_CTRL behavior difference at the two different speeds.

Are you implementing any internal delay in the PHY or FPGA? Please check the register field of the PHY to see if the internal delay is what you want.

There is a DLL in the PHY for controlling the clock delay. 

Hi Ross

   We have spent a lot of time on debugging DP83867IR, and this PHY still fails receiving data in 100M ethernet mode.

   By capture waveform on FPGA,we find that phy RX_CTRL signal drop too early, and the high 4bit of the last byte in test packet is missing which will lead to CRC check err in MAC.

   I have take picture of 10M ethernet and 100M ethernet waveform attached in this mail，and the capture clk in FPGA is 100M，please check it and thanks a lot.

Below is 100M_ethernet_mode_with_wrong_rx_ctrl:

Below is 10M_ethernet _mode_with_right_rx_ctrl:

Thanks a lot.

BRs

Elsa Duan

Hi Elsa,

I think I see what the issue might be here.

Are you implementing any trace delay between data and clock through the track routing?

Are you implementing any delay in the PHY before the PHY transmits the RX data out?

Are you implementing any delay in the FPGA once the RX data is received?

Based on your schematic, you are operating in align mode where clock and data edges are aligned.

You need to enable some sort of delay through either the track, PHY or MAC.

Hi Ross,

1. Are you implementing any trace delay between data and clock through the track routing?

  No ,the waveform captured by FPGA is all of PHY port connected with FPGA, the delay or sync cell is placed after signal in picture. 

2. Are you implementing any delay in the PHY before the PHY transmits the RX data out?

  No,our software hasn't config any delay register of PHY.

3. Are you implementing any delay in the FPGA once the RX data is received?

  No, I only add input delay constraint for PHY RX_DATA refer to PHY RX_CLK, and then there is 4 FlipFlop which sync PHY_RX_DAT for MAC.  

4. Based on your schematic, you are operating in align mode where clock and data edges are aligned.

  This is because that the waveform is captured by 100M ref clk in FPGA, so you can't observe the async delay between PHY RX_CLK and RX_DATA. 

5. You need to enable some sort of delay through either the track, PHY or MAC.

  I can check if the first sync FlipFlop store right data by waveform, but the FPGA logic can't fix the last byte missing and PHY_RX_CTRL drop too early. 

  Up to now, I think the main problem is that PHY drop RX_CTRL too early, and the last BYTE of one packet is missing, this problem has no relation with Timing.

Can you send me a capture of the actual RX_CLK to Data and not the FPGA clock please?

For debug, please enable a reverse loopback in the PHY so that data received on the cable (MDI) will be looped back within the PHY to be transmitted back out on the MDI. This will help us understand if there is an error on the cable side or if the issue is happening on the xMII side.

Hi Ross,

I have take a picture of oscilloscope, the yellow channel is RX CLK, and the green channel is RX DATA0.

It's an urgent case for me, Looking forward to your reply.

Thanks a lot.

Hi,

Can you please enable internal delay in the PHY?

Also, what is the result of the loopback tests?

 It's urgent case. I have take a picture of oscilloscope, the yellow channel is RX CLK, and the green channel is RX DATA0.

Can you please tell me how the loopback tests ended up?

Did it pass or fail with the internal loopback. Please be specific on which ones passed and failed.

From the above, it looks like there is still no internal delay being added.

Are you sure the register is being configured properly?

Please read back the DLL register to confirm the delay is being implemented.

Hi,

 1. Can you please tell me how the loopback tests ended up?

    The PHY loopback still fail in 10M mode and 100M mode.

    While in 10M mode, the PHY can send right data received from another PHY, I have attach two picture of the RX_data, RX_ctrl refer to RX_clk. Please note that the Rx_ctrl will drop low early in 10M loopback mode, while it is ok in normal 10M mode.

 This is 10M Loopback mode:

This is 10M normal mode:

2.Did it pass or fail with the internal loopback. Please be specific on which ones passed and failed.

   We have test 10M loopback and 100M loopback in MAC,and they are all working well, so I think the MAC in our design is ok.

3.From the above, it looks like there is still no internal delay being added.

   The delay configured in PHY is only 2ns or 4ns, so this can't solve the Rx_ctrl drop early in 10M mode and 100M mode,we have try this rigster.And I will reply the read back date of DLL rigster later.

   The delay register 0x86 is configuerd as 0x77.

Thanks a lot.

Hi,

What is the  packet size? Are you using jumbo packets? Normal packet are between 64 byte to 1518 byte (including 4 byte CRC)

What is the IPG: Inter Packet Gap? Should be minimum of 960ns for 100Mbps ethernet. 

What is the crystal spec? Can you share datasheet?

-Regards

Aniruddha