DP83TC814S-Q1: RGMII Input Timing Issue

Hi Wang, 

1: The values for Thold and Tsetup are defined through minimum requirements. The maximum possible value will depend on a few external factors and cannot be defined as such. As long as the values fall within reasonable range of the typical value of 2ns, as listed in the datasheet section 7.6, the device should function normally.

2: The waveform you attached shows the RGMII Transmit Timing Behavior with internal delay enabled. The variables listed here, Thold(shift) and Tsetup(shift) cannot be defined with maximum values for the same reasons stated above, however, Tsetup(shift) must have a minimum value of 2ns.

Best regards,

Vivaan

Hello Vivaan,

Now the MAC is set as Internal Delay Disabled).

And the TXCLK is 25MHz,  Tcys=40ns

Below is Thold Waveform:

Below is Tsetup Waveform:

Do you think it is OK?

Q3:  What is the maximum voltage these pins(TX_CLK, TX_CTRL, TX_D[3:0],RX_D[3:0], RX_CLK, RX_CTRL) can accept?

VDDMAC+0.3 V？

Now, the voltage of VDDMAC is 3.3V.

TX_CLK has large overshoot and undershoot. So we adjust the register of SOC to change the drive strength to meet Vmax<3.6V and Vmin>-0.3V.

But it occurs the issue of losing package at the moment.

If we increase the drive strength of TX_CLK, the issue disappears. But the overshoot and undershoot occurs.

Q4:  From the RGMII INPUT TIMING, we can't find out the reason of losing package.

           Below test result all meet RGMII input timing requirement.

Tcys=40ns

Thold=24.662ns

Tsetup= 14.851ns

Could you tell how to confirm the issue?

Q5: Could you give us some suggestion?

Best Regards!

Wang Jingkun

Hi Wang,

Judging from the Waveforms, we can see that both Thold and Tsetup have values that far exceed the typical value of 2ns. These values are good and meet the specifications.

The maximum voltage on the MAC interface should be VDDMAC + 0.3, as you pointed out as well. Were you able to get the value of 3.3V for VDDMAC by probing the exact voltage on the pin? If not, I would recommend you measure the pin first to rule out the possibility that VDDMAC might be a little higher than 3.3V. The absolute maximum and minimum values for VDDMAC, which can be seen in section 7.3 in the datasheet, are 2.97V and 3.63V respectively. In this case, the voltage overshoot should be within the required specifications.

Moreover, the waveform you have provided for measuring the voltage overshoot looks like it might have a little aliasing. I would also recommend trying to get a cleaner waveform signal to get more accurate readings

Best regards,

Vivaan

Hello Vivaan,

Below waveform is TX_CLK and VDDMAC.  The VDDMAC is 3.3V.

Below waveform is cleaner.

We want to know why the timing is met and has margin, but there is packet loss.

Best Regards!

Wang Jingkun

Hi Wang, 

Could you share the waveforms comparing the Clock and Data signals on TX for both the cases (with and without adjusting the voltage overshoot to meet the 3.6V requirement). How were you able to diagnose packet loss when lowering the drive strength? This will help us narrow down the issue

Best regards,

Vivaan

Hello Vivaan,

Could you share the waveforms comparing the Clock and Data signals on TX for both the cases (with and without adjusting the voltage overshoot to meet the 3.6V requirement). 

--> Please refer to below document :"RGMII_Input_Timing_Waveform-20240906.xlsx"

RGMII_Input_Timing_Waveform-20240906.xlsx

Changing TX_CLK pin setting from x6 drive strength to lower, the package loss rate will follow to higher:

     6x Drive Stength: 1034 packets transmitted, 1034 packets received, 0% packet loss

     4x Drive Stength: 1035 packets transmitted, 1035packets received, 0% packet loss

     2x Drive Stength: 1034 packets transmitted, 993 packets received, 3% packet loss

     1x Drive Stength: 965 packets transmitted, 0 packets received, 100% packet loss

How were you able to diagnose packet loss when lowering the drive strength?

--> Below is test setup.  Master pings to Slave during testing.

SoC can monitor that how many packets transmitted and received.

Best Regards!

Wang Jingkun

Hi Wang, 

I would recommend setting up a MII Loopback on the Master side by writing the register 0x0000 = 0x6100. This would tell us if the packet loss is happening in the MII interface or further down the line. If the MII Loopback shows no packet loss, you could also try reverse loopback to further isolate the packet loss. More information about loopbacks can be found in section 8.3.1.5 of the datasheet.

I also wanted to make sure that the MAC is configured to enable internal delay if the PHY is in align mode, and visa versa, according to the table given below. This is an important step to meet the RGMII timing constraints.

Hello Vivaan,

Below is MII Loopback test result:

Does the registers (0x063C,0x063D,0x063E) count the data of below note?

Best Regards!

Wang Jingkun

Hi Wang,

Thank you for this information.

Jingkun Wang said:

Does the registers (0x063C,0x063D,0x063E) count the data of below note?

I was able to recreate a test setup here, and according to what I was able to measure, these registers seem to be affiliated with the MDI side, not the MAC. Was the MII Loopback set by setting register 0x0000 to 0x6100? With this Loopback enabled, the MDI side should not see any packets at all, so the registers should just read 0x0000. While testing the loopback, was the MDI side connected to anything? 

Vivaan Jaiswal said:

I also wanted to make sure that the MAC is configured to enable internal delay if the PHY is in align mode

Kindly also share what configurations the MAC and the PHY are using. (Shift or Align)

Best regards, 

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

I was able to recreate a test setup here, and according to what I was able to measure, these registers seem to be affiliated with the MDI side, not the MAC. Was the MII Loopback set by setting register 0x0000 to 0x6100? With this Loopback enabled, the MDI side should not see any packets at all, so the registers should just read 0x0000. While testing the loopback, was the MDI side connected to anything? 

1) Below is my test step:

1. Configurating the Master and Slave IP;

2. Configurating Loopback:  phytool.sh write 0x0000 0x6100
                                             phytool.sh write 0x0619 0x1004

3. Read the register: 0x063C,0x063D,0x063E,  making sure the value is 0x0000

4. Ping starts;

2) While testing the loopback, was the MDI side connected to anything?

--> Yes. Below is test setup:

3). 

Vivaan Jaiswal said:

I also wanted to make sure that the MAC is configured to enable internal delay if the PHY is in align mode

Kindly also share what configurations the MAC and the PHY are using. (Shift or Align)

--> We are confirming. I'll share the confirm result for you late.

4) As above Loopback test setup: Does the registers (0x063C,0x063D,0x063E) count the data of below note?

Best Regards!

Wang JIngkun

Hi Wang, 

The registers 0x063C, 0x063D, and 0x063E seem to count data flow for the MDI side, not the MAC. So it does not count the packets at the note highlighted in your reply, but the other side where the slave PHY is connected. I was able to confirm this on my setup here. I am trying to create a test where we can measure the packet count in a loopback to further isolate the packet loss. I will reply with the result here by EOD Monday. 

Regards,

Vivaan

Hello Vivaan,

From the datasheet, the registers reads at MAC interface RX pins.

If we don't connect slave, it can't do the xMII Loopback test.

Best Regard!

Wang Jingkun

Hi Wang, 

In the Datasheet it does mention that the register reads at MAC RX pins, however through internal testing, we have determined this is not the case and we will fix the datasheet shortly. However, I tried doing a Digital Loopback which does populate the registers with the correct information for the MAC RX pins. I would recommend trying to run a digital loopback and checking these registers to see if the number of packets transmitted matches the number of packets received and the register value. This should help us narrow down where in the datapath the packet loss occurs.

Jingkun Wang said:

If we don't connect slave, it can't do the xMII Loopback test.

The MDI side is not required for these loopbacks, so it should do the loopbacks without the slave connected. Can you elaborate on this as well as the shift/align modes for the MAC/PHY?

Regards,

Vivaan

Hello Vivaan,

Digital loopback test detail steps as below:

1. Read back 0x063C, 0x063D, 0x063E;

2. write 0x0016 0x0104
    write 0x0619 0x1555
    write 0x0624 0x55BF

3. Read back 0x063C, 0x063D, 0x063E;

Is it right? 

How to confirm where the package loss?

As your explain, I don't know how to do the xMII Loopback test. Could you give us the detail setting?  And which registers do use for checking incoming data?

Vivaan Jaiswal said:

The MDI side is not required for these loopbacks, so it should do the loopbacks without the slave connected. Can you elaborate on this as well as the shift/align modes for the MAC/PHY?

I don't know how to do the xMII loopback test without slave.  Could you give me the xMII Loopback test step?

Best Regards!

Wang Jingkun

Hi Wang, 

I believe the register writes to enable data generator are not needed for our purposes. We can follow the following steps. Make sure the MAC is not actively transmitting packets at this time.

1. Read 0x612, 0x613, 0x614 in this order. This clears Registers 0x063C, 0x063D, 0x063E.

2. Read back 0x063C, 0x063D, 0x063E; make sure it reads 0

3. Write register 0x0016 as 0x0104. This enables Digital Loopback.

4. Send a specific number of packets from the MAC to the PHY. These packets go through the Digital block and be routed back and received at the MAC

5. Read back 0x063C, 0x063D, 0x063E. If there is no packet loss, the values in these registers should be the same as the number of packets transmitted/received by the MAC

Doing the above steps for the different drive strengths should give us more information. 

Since the packet counter does not work for xMII Loopback, lets try doing the Digital Loopback described above to narrow down the problem. 

Regards, 

Vivaan

Hello Vivaan,

The digital loopback test result as below:

But these registers record the data of which node?

Best Regards!

Wang

Hi Wang, 

The registers seem to record the data near the digital block in the picture you sent. From this, we now know that the data being sent is being received by the PHY properly. I think the packet loss is occurring in the RX path to the MAC

Jingkun Wang said:

RGMII_Input_Timing_Waveform-20240906.xlsx

Probing the RX pins going to the MAC interface, like the waveforms provided earlier, is also useful to verify the activity on the RX pins is as expected. 

When editing the drive strength, are any other parameters being changed or affected other than TX_CLK from the MAC? Modifying this should only affect the transmission from the MAC, which seems to function fine since the PHY is able to detect all the packets sent. Somewhere in the return path the packets are not going through, which is also why I think probing the RX data/clock pins is a good idea. 

I'd suggest using the link partner to send a stream of packets to the PHY, which then goes to the MAC. During this, RX pins can be probed, and the registers 0x063C-0x063E can be read. If all the data is present in the register and the waveforms fall within the parameters, but the MAC still doesn't receive the data, we can start looking into the layout files to debug the potential problem. s

Regards,

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

Probing the RX pins going to the MAC interface, like the waveforms provided earlier, is also useful to verify the activity on the RX pins is as expected. 

--> Wang： Please refer to the document: RGMII_Output_Timing_Waveform-20241012.xlsx

RGMII_Output_Timing_Waveform-20241012.xlsx

Vivaan Jaiswal said:

When editing the drive strength, are any other parameters being changed or affected other than TX_CLK from the MAC? Modifying this should only affect the transmission from the MAC, which seems to function fine since the PHY is able to detect all the packets sent. Somewhere in the return path the packets are not going through, which is also why I think probing the RX data/clock pins is a good idea.

--> Wang:  I only changed the TX_CLK drive strength. Other parameters were not been changed.  

Although the digital loopback test now shows that packet loss occurs in the RX path.

But now we found two countermeasures can solve the issue:

Countermeasure_1:  Increasing drive strength,  but the overshoot issue occurs and overs the PHY's maximum requirement.

Countermeasure_2: PHY enables the internal delay and changes the MAC's TX_CLK output  (Invert changed to Normal) (Without increasing TX_CLK drive strength)

Below is MAC's TX_CLK output waveform in two output setting: (below is first data when ping starts)

Invert Output:  MAC outputs D[0-3]/ CTRL after CLK falling edge

Normal Output: MAC outputs D[0-3]/ CTRL after CLK rising edge

We are very confused why the loopback test shows that the problem occurs in the RX PATH, but the TX PATH countermeasures can solve the problem.

Best Regards!

Wang

Hi Wang, 

Due to this new information, I think that the TX_CLK drive strength wasn't the cause. I believe this ties into my earlier question about shift/align modes. The data hadn't been lost, but instead it was harder to decipher. 

Vivaan Jaiswal said:

Can you elaborate on this as well as the shift/align modes for the MAC/PHY?

The MAC and PHY need have complimentary modes for the communication to function properly. I think that there might be a RGMII delay mismatch originally, a symptom of which is packet loss. This also explains why adding an internal delay would help fix the packet loss by adding clock skew to help correct the mismatch and enables more accurate sampling of the data. I think counter measure 2, listed in your reply, is the correct way to proceed. 

Best Regards, 

Vivaan

Hello Vivaan,

But I did not find any non-compliance with PHY requirements before modification.

Why did it cause the package loss?

Another question, why does the digital loopback test show packets lost in the RX path?

Best Regards!

Wang

Hi Wang,

RGMII Timing is an important metric that must be met to ensure no packet loss occurs. I believe that the data was being sent at the same time as the TX_CLK earlier, which is why it wasn't being sampled properly. By introducing the internal delay, the PHY ensures that the rising edges of the data and the clock are not at the same time, allowing for some room for setup and hold times. A more detailed explanation can be found here. 

In the Digital Loopback test, we see that the packets are being received by the PHY, but not received back by the MAC. This, in addition to the RX waveforms you provided, tells us that the data is being received and transmitted by the PHY, so the packets must be getting "lost" after leaving the PHY on the RX path. 

Jingkun Wang said:

I did not find any non-compliance with PHY requirements before modification.

I believe the timing requirement was being violated. By the data and clock signals switching at the same time, in some instances it did not provide sufficient setup/hold times for correct sampling. Enabling the internal delay on the PHY should take care of this though, as you mentioned as well. 

Best Regards,

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

RGMII Timing is an important metric that must be met to ensure no packet loss occurs. I believe that the data was being sent at the same time as the TX_CLK earlier, which is why it wasn't being sampled properly. By introducing the internal delay, the PHY ensures that the rising edges of the data and the clock are not at the same time, allowing for some room for setup and hold times. A more detailed explanation can be found here.

The PHY also supports the internal delay disabled. Could you explain the potential reason that causes the issue from below waveform.

Vivaan Jaiswal said:

In the Digital Loopback test, we see that the packets are being received by the PHY, but not received back by the MAC. This, in addition to the RX waveforms you provided, tells us that the data is being received and transmitted by the PHY, so the packets must be getting "lost" after leaving the PHY on the RX path.

So we can see the packages were 100% received by PHY.  I think the test result indicates TX path doesn't have any issue.

We really can't understand the relationship between this loopback test result and the countermeasures. 

Best Regards!

Wang

Hi Wang, 

Let's look at the TX and RX channels separately.

The TX channel brings the data from the MAC to the PHY.  As explained in this link, also mentioned in my last reply, the configurations of the MAC and PHY Rx and TX channels must be complimentary, that is, if the MAC is in shift mode, the PHY must be in align mode, or visa versa. Since the digital loopback tests confirm that the TX part of the datapath works as expected because we are able to see 100% of the packets being received by the PHY. This means that the settings for the TX path of both the MAC and the PHY are complimentary.

Now looking at the RX path, this is where the packet loss was an issue. This was because the MAC and the PHY were not in complimentary modes. The MAC and PHY must have been in "align" modes, which is why not all the data was being sampled properly. In this configuration, the MAC expects that the data line would have a small delay compared to the clock. By changing the PHY to the shift (Delay) mode, we correct this configuration of PHY and MAC RX channel, which formats the data with a built in delay, like the MAC is expecting.

Jingkun Wang said:

PHY also supports the internal delay disabled

Yes, the PHY supports both configurations to allow for use with different MAC interfaces. Again, the link below should illustrate this behavior in more detail.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1096129/faq-rgmii-timing---align-and-shift-mode 

Best Regards,

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

The TX channel brings the data from the MAC to the PHY.  As explained in this link, also mentioned in my last reply, the configurations of the MAC and PHY Rx and TX channels must be complimentary, that is, if the MAC is in shift mode, the PHY must be in align mode, or visa versa. Since the digital loopback tests confirm that the TX part of the datapath works as expected because we are able to see 100% of the packets being received by the PHY. This means that the settings for the TX path of both the MAC and the PHY are complimentary.

Now looking at the RX path, this is where the packet loss was an issue. This was because the MAC and the PHY were not in complimentary modes. The MAC and PHY must have been in "align" modes, which is why not all the data was being sampled properly. In this configuration, the MAC expects that the data line would have a small delay compared to the clock. By changing the PHY to the shift (Delay) mode, we correct this configuration of PHY and MAC RX channel, which formats the data with a built in delay, like the MAC is expecting.

As your answer,  we should have a countermeasure in RX path. But now we take a countermeasure on TX path to solve the issue.

We can't understand the the relationship between this loopback test result and the countermeasures. 

Loopback test indicates the issue at RX path

.Countermeasure at TX path.

Could you understand it?

Vivaan Jaiswal said:

Yes, the PHY supports both configurations to allow for use with different MAC interfaces. Again, the link below should illustrate this behavior in more detail.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1096129/faq-rgmii-timing---align-and-shift-mode 

I know the PHY and MAC configurations.

At currently, the PHY is configurated in Align mode.  And the MAC seems in shift mode (TX_CLK is invert, TX_EN/Data output after CLK falling edge).

Countermeasure: the PHY is configurated in Shift mode.  And the MAC seems in Align mode (TX_CLK is normal, TX_EN/Data output after CLK rising edge).

It seems both meet the requirement. Why does it have the issue?

Best Regards!

Wang

Hi Wang, 

I apologize about the confusion. I don't believe that the "invert" and "normal" modes refer to "shift" and "align" modes. As you mentioned, the invert mode simply makes the data aligned with the falling edge, while the normal mode keeps it at rising edge. Shift and align refer to a delay between the clock and the data lines, which is not the same as invert/normal. 

Have you tried to test the MAC in invert mode and the PHY in shift mode? That should help us better understand the functionality of normal vs invert modes on the MAC. 

Jingkun Wang said:

we should have a countermeasure in RX path. But now we take a countermeasure on TX path to solve the issue

Making the PHY use shift mode also changes the behaviour of the RX path, not just TX.

I think the MAC is configured to be on "align" mode, but we can check to make sure. What kind of MAC is being used? Do you have any documentation about the MAC interface that may point us in the right direction?

Best Regards,

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

Have you tried to test the MAC in invert mode and the PHY in shift mode? That should help us better understand the functionality of normal vs invert modes on the MAC.

At this condition,  it can't ping. 

Vivaan Jaiswal said:

I think the MAC is configured to be on "align" mode, but we can check to make sure. What kind of MAC is being used? Do you have any documentation about the MAC interface that may point us in the right direction?

The MAC is in SoC.  I can't share the document directly and I pick up the  Electrical Characteristics for Ethernet Controller:

Best Regards!

Wang Jingkun

Hi Wang,

For RGMII used in 100Mbps speed, the data is only sampled at rising edges, as opposed to 1000Mbps speed where it is sampled at both rising and falling edges. This is why the link would not work in invert mode since the device DP83TC814 is made for 100Mbps speeds. Using it in normal mode, the data should be sampled correctly. 

Moreover, from the screenshots provided, I do not see a delay spec or configuration value for the RX path, unlike the TX paths. This leads me to believe that the RX side of the MAC interface is always in "align" mode. This also explains why using the PHY in shift mode fixes the problem. 

Best Regards,

Vivaan

Hello Vivaan,

Vivaan Jaiswal said:

For RGMII used in 100Mbps speed, the data is only sampled at rising edges, as opposed to 1000Mbps speed where it is sampled at both rising and falling edges. This is why the link would not work in invert mode since the device DP83TC814 is made for 100Mbps speeds. Using it in normal mode, the data should be sampled correctly. 

--> I think in this mode (MAC: in invert mode;  PHY: in shift mode), the TX_CTRL signal cannot be sampled correctly.

MAC outputs the TX_CTRL before TX_CLK rising edge;

PHY requires the TX_CTRL after TX_CLK rising edge.

So the link would not work.

But in below mode,  I can't find any issues in timing. Could you find out the issue?

Vivaan Jaiswal said:

Moreover, from the screenshots provided, I do not see a delay spec or configuration value for the RX path, unlike the TX paths. This leads me to believe that the RX side of the MAC interface is always in "align" mode. This also explains why using the PHY in shift mode fixes the problem. 

--> I updated the timing:

From the datasheet,  the main difference of the TX timing in shift and align is the TX_CTRL:

Align mode:  TX_CTRL before TX_CLK rising edge

Shift mode： TX_CTRL after TX_CLK rising edge

TX_D9[3:0] are same. (After TX_CLK rising edge)

Is it right?

Vivaan Jaiswal said:

Making the PHY use shift mode also changes the behaviour of the RX path, not just TX.

--> Could you explain how to changes the behavior of RX path?

How to understand below RGMII transmit Encoding?

During the whole transmit,  the TX_CTRL keeps high. It means that transmit error propagation???

Best Regards!

Wang 

Hi Wang, 

Jingkun Wang said:

But in below mode,  I can't find any issues in timing. Could you find out the issue?

As mentioned in my previous comment, the PHY expects the data at rising edges, not falling edges. In this mode, the data is synchronous to the falling edge of the clock, which is why the data will not be sampled correctly.

Jingkun Wang said:

MAC outputs the TX_CTRL before TX_CLK rising edge;

PHY requires the TX_CTRL after TX_CLK rising edge.

So the link would not work.

While this configuration also does not work, it is because of the same reason, that the PHY is expecting the data to by synchronous with the rising edge, but in invert mode it is synchronous to the falling edge.

Jingkun Wang said:

I updated the timing:

Even in the updated timing, there is no configuration for RX delay on the MAC side. This means that the MAC is expecting the delay on the PHY side, which is what fixed the original problem.

Jingkun Wang said:

From the datasheet,  the main difference of the TX timing in shift and align is the TX_CTRL:

Align mode:  TX_CTRL before TX_CLK rising edge

Shift mode： TX_CTRL after TX_CLK rising edge

TX_D9[3:0] are same. (After TX_CLK rising edge)

Is it right?

No. The difference between the shift and the align modes is that in shift mode a delay is introduced between the clock (TX_CLK/RX_CLK) and the data lines (TX_D/RX_D), while in align mode the data and clock should be synchronous to the clock. Is this written in the 814 datasheet somewhere? I was not able to find anything similar to this. i would recommend reading through the following link, that I have also provided in previous comments, for a detailed explanation of shift and align modes. https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1096129/faq-rgmii-timing---align-and-shift-mode 

Jingkun Wang said:

Could you explain how to changes the behavior of RX path?

Changing the PHY to shift mode is already changing the RX and TX paths. No additional steps are required, the current countermeasure of enabling shift mode is all that is necessary. 

Jingkun Wang said:

How to understand below RGMII transmit Encoding?

For normal operation, we would expect that TX_CTRL should be high on rising edges of the clock and low on falling edges. If high on falling edges, it would indicate the presence of a transmit error. However, in the shared waveform, it is labelled as TX_DV not TX_CTRL. Is the correct pin being probed? What configuration are the devices in at the time of this waveform?

Best Regards,

Vivaan

Hi Vivaan

Vivaan Jaiswal said:

Even in the updated timing, there is no configuration for RX delay on the MAC side. This means that the MAC is expecting the delay on the PHY side, which is what fixed the original problem.

--> MAC Ethernet has registers to set delay in TX path and RX path.

Vivaan Jaiswal said:

Changing the PHY to shift mode is already changing the RX and TX paths. No additional steps are required, the current countermeasure of enabling shift mode is all that is necessary. 

-->  We need to know the detail changes in RX path when TX path changes from align mode to shift mode.

Vivaan Jaiswal said:

If high on falling edges, it would indicate the presence of a transmit error.

-->  About the TX_CTRL Coding,   datasheet defined is different from RGMII Version2.0.

https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf

I think the following is correct

TX_CTRL is high on rising edges of the clock and low on falling edges, it would indicate the Transmit error propagation. 

TX_CTRL is high on rising edges of the clock and high on falling edges, it would indicate the Normal data transmission. 

The definition in TI's datasheet： 

TX_CTRL is high on rising edges of the clock and high on falling edges, it would indicate the Transmit Error Propagation. 2

It seems to be defined in reverse. Could you have a check?

Vivaan Jaiswal said:

However, in the shared waveform, it is labelled as TX_DV not TX_CTRL. Is the correct pin being probed? What configuration are the devices in at the time of this waveform?

--> The label on the waveform was miswritten. It is TX_CTRL.  Pin_29 is probed. The waveform is tested in ping mode.

We can find the timing requirement of TX path in shift mode.  Could we refer the SPEC of RGMII V2.0?

https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf

Best Regards!

Wang

Hi Wang, 

Jingkun Wang said:

MAC Ethernet has registers to set delay in TX path and RX path

I am just a little confused since the picture references below shows in the "Note" below the TX tables that the delay is set as 0x10 along with invert or normal mode. Under the RX table, it only mentioned invert mode, and nothing about delays. Regardless, even if the MAC has a delay configuration for RX, it doesn't look like it is enabled.

Jingkun Wang said:

We need to know the detail changes in RX path when TX path changes from align mode to shift mode

The RX Path is not affected by the TX path changes. Shift and align modes can be used on both paths independently using the register 0x0602, or configured through bootstraps.

How is the delay being added on the PHY side? Is it writing register 0x0602 to some value?

I was assuming the delay was being added on the RX side. The only thing changing in these instances is the delay between the clock and data lines

Jingkun Wang said:

It seems to be defined in reverse. Could you have a check?

Yes, your understanding is correct. I have checked with the team internally and it looks like there was a mistake on the datasheet. We will correct this in the next revision, but for now TX_CTRL being high for both edges indicates error-free transmission. 

Jingkun Wang said:

Could we refer the SPEC of RGMII V2.0?

Yes. The spec for shift mode should be the same as align mode, but it looks like the specs highlighted in the standard above are the same as the ones on the datasheet, so it should be good. 

Let's take a step back and look at the full setup

Assuming the PCB traces and length matched and introduce no delays, we can have the following configurations

From my understanding, since changing the PHY from RX Align to RX Shift fixed packet loss, the MAC must be in RX Align mode, which gets us the configuration listed as number 2 in the table above. Was only the RX Shift mode activated or both RX and TX modes to fix the packet loss?

Best Regards,

Vivaan

Hello Vivaan,

The info in the website, it seemed to cause some confusion. So I created a file to manage.

You can give me the feedback in the document.

Now you can check below document: "Ethernet_Loss_Package_Issue_20241025.xlsx"

Ethernet_Loss_Package_Issue_20241025.xlsx

Best Regards!

Wang Jingkun

Hi Wang,

Here is the updated document from my side

7455.Ethernet_Loss_Package_Issue_20241025.xlsx

Best Regards,

Vivaan

Hi  Vivaan，

Below document is updated:

Ethernet_Loss_Package_Issue_20241028.xlsx

Could you use a highlighted font to show your reply?

Best Regards！

Wang 

Hi Wang, 

Kindly allow me a day to consult with my team. I will respond by EOD tomorrow.

Best Regards,

Vivaan

Hi Wang,

Ethernet_Loss_Package_Issue_20241028 (1).xlsx

Best Regards,

Vivaan

Hi Vivaan,

Ethernet_Loss_Package_Issue_20241101.xlsx

Best Regards!

Wang

Hi Wang,

5621.Ethernet_Loss_Package_Issue_20241101.xlsx

Best Regards,

Vivaan

Hi Vivaan

5621.Ethernet_Loss_Package_Issue_20241105.xlsx

Best Regards!

Wang

Hi Vivaan

What can we do next step?

Best Regards!

Wang

Hi Wang,

Apologies for the delay, I was on leave. 

5556.Ethernet_Loss_Package_Issue_20241105.xlsx

Best Regards,

Vivaan

Hi Vivaan

Ethernet_Loss_Package_Issue_20241108.xlsx

Best Regards!

Wang

Hi Wang,

The test setup is attached, along with comments

4520.Ethernet_Loss_Package_Issue_20241108.xlsx

Best regards,

Vivaan

Hi Vivaan

About transmitting a specific number of packets in MAC side, we are confirming with MAC manufacturer.  It may need some time.

Please wait a moment.

Best Regards!

Wang

Hi Wang, 

No worries, looking forward to an update from you

Best Regards,

Vivaan

Hi Vivaan

When I checked the RX path with below setting, PHY didn't send out any packets.

0x619=0x0575

0x624=0x5552

I also used the oscilloscope to measure waveform, the RX_CTRL still kept low.

Please check again the setting.

Best Regards!

Wang

Hi Wang, 

You are correct, I mixed up the MDI and MII sides. Register 0x619 should be configured to 0x1005 NOT 0x0575. Also note, register 0x619 should be programmed AFTER 0x624. I tested this out here as well and was able to receive 100 packets. Sorry about the confusion.

Best Regards,

Vivaan

Hi  Vivaan,

We have gotten the confirm result from SOC.  It has registers to record receive packets.

We try to use ping, the registers record can increase after receiving packets.

But using above method(0x624=0x5552; 0x619=0x1005),  the registers can't records anything.

Below waveform gets after registers setting. (0x624=0x5552; 0x619=0x1005)

Could you have a check?

Best Regards!

Wang Jingkun

Hi Wang,

Thank you for the information. 

Did you test this setup for both delay and no delay settings? was the result the same?

It is unusual that the MAC is not detecting any packets, the waveform also shows activity on the RX lines

Hi Vivaan，

Vivaan Jaiswal said:

Did you test this setup for both delay and no delay settings? was the result the same?

Yes. The result is same.

But using ping method,  the MAC can record the packets.

Using the method(0x624=0x5552; 0x619=0x1005),  one packet's time is about 136us.

Does it can increase the time of one packet?

Another question, the MAC manufacturer wants to know what test pattern is sent exactly with the setting (0x624=0x5552; 0x619=0x1005)?

Best Regards!

Wang Jingkun