DP83TG720S-Q1: Packet-loss in slave mode

Hi Yuto,

Can you please share the schematic and layout. I will have a look. 

We can conduct loopback testing to determine where the packet errors are stemming from. Please enable analog loopback in the DP83TG720 and let me know if there are any errors. This will tell us if the SGMII interface is problematic or if it is the MDI side.

Thanks,

David

Hi David,

1. Please check the attached files for layout and schematics. Please give us your comment.

2. Could you please tell me how to do "loopback"?

Regarding the loopback, we have tried "1.Analog loopback" following the method described in D/S 7.3.1.3.3. But all received data was "0" both MAC packets and PRBS stream method.
I have checked several e2e thread which have same issue but not sure how to resolve the issue.

Best regards,
Yuto

Hi Yuto,

I will look at the schematic and layout and get back to you tomorrow. 

In the meantime, can you share a register dump of 0x0 - 0x1F, 0x608, 0x60A, 0x45D.

By loopback, I meant analog loopback as you have seen in the datasheet. Packets should be generated and checked by the MAC, not the PHY. 

Can you please also share how many packet errors are you receiving? What is the bit error rate (BER)?

Thanks,

David

Hi David,

Please find the feedback from the customer. There are several questions and answer to your question.

****
Let me share the register dump to:
Reg 0x0 = 0x0140
Reg 0x1 = 0x0145
Reg 0x2 = 0x2000
Reg 0x3 = 0xa284
Reg 0x4 = 0x0000
Reg 0x5 = 0x0000
Reg 0x6 = 0x0000
Reg 0x7 = 0x0000
Reg 0x8 = 0x0000
Reg 0x9 = 0x0000
Reg 0xa = 0x0000
Reg 0xb = 0x0000
Reg 0xc = 0x0000
Reg 0xd = 0x4001
Reg 0xe = 0x8001
Reg 0xf = 0x0000
Reg 0x10 = 0x0085
Reg 0x11 = 0x000b
Reg 0x12 = 0xe400
Reg 0x13 = 0x0200
Reg 0x14 = 0x0000
Reg 0x15 = 0x0000
Reg 0x16 = 0x0100
Reg 0x17 = 0x0000
Reg 0x18 = 0x3008
Reg 0x19 = 0x0400
Reg 0x1a = 0x0000
Reg 0x1b = 0x0000
Reg 0x1c = 0x0000
Reg 0x1d = 0x0000
Reg 0x1e = 0x0000
Reg 0x1f = 0x0000
Reg 0x608 = 0x027b
Reg 0x60a = 0x0d26
Reg 0x45d = 0x2000

write Reg 0x16 = 0x0108 to enter Analog loopback mode, and write Reg 0x619 = 0x1555 to send packets from Data Generator? How does Inbuilt data-generator work?
As a test, I sent a ping command from my PC without entering loopback mode, and I could confirm that Reg 0x63C was counting up.

Iperf sends packets and detects 3/53500 as an error.
Iperf -c 192.168.10.2 -u -I 1 -t 600

[ 3 ] 0.0-600.0 sec 75.0 MBytes 1.05 Mbits/sec
[ 3 ] sent 53501 datagrams
[ 3 ] Server Report:
[ 3 ] 0.0-600.0 sec 75.0 MBytes 1.05 Mbits/sec 0.011 ms 3/53500 (0.0056%)
[ 3 ] 0.0-600.0 sec 1 datagrams received out-of-order

****

Best regards,
Yuto

Hi Yuto,

We can determine where the source of errors are coming from by enabling analog loopback and running iperf command again. If there are the same number of errors, the issue can be determined to be on the SGMII path. If there are no errors after enabling analog loopback and running iperf, the errors lie on the cable side of the PHY. Please enable analog loopback (without write to 0x619) and run the iperf command again.

I cannot see the values of several components on the schematic. Can you make these value visible and re-share, such as C4, C15, R41, R42, R43. Can you also share the layout image of the full SGMII traces?

Thanks,

David

Hi David,

Is re-post the image, is it visible? FYI, C4=0.1uF/25V, C15=4700pF/50V, R41=1k, R42=1k, R43=100k.
Also attached layout images.

For loopback, we found that even if writing Reg 0x16=0x108, it seems to be not in loopback mode since we can read Reg 0x16=0x100 after writing.
Can you let me know how to get into loopback mode?

As of now, we have done the process below but not sure we can make it.
[Process / Code]
Write Reg 0x1f = 0x8000 <- Hardware Reset
Write Reg 0x16 = 0x108
Write Reg 0x405 = 0x2800
iperf -c 192.168.10.1 -u -i 1 -t 600  <- execute iperf

[Result]
[  3]  0.0-600.0 sec  75.0 MBytes  1.05 Mbits/sec
[  3] Sent 53500 datagrams
[  3] Server Report:
[  3]  0.0-598.9 sec  75.0 MBytes  1.05 Mbits/sec   0.033 ms    1/53500 (0.0019%)

and 

Read Reg 0x63C = 0xD133 (53,555)
Read Reg 0x63D = 0x0000
Read Reg 0x63E = 0x0000

I don't know why but it is more than iperf sending packet#.

Best regards,
Yuto

Hi Yuto,

For loopback, we found that even if writing Reg 0x16=0x108, it seems to be not in loopback mode since we can read Reg 0x16=0x100 after writing.
Can you let me know how to get into loopback mode?

This is abnormal, register 0x16 should stay at 0x0108 when analog loopback is enabled. Are you able to write to other registers without issue? Can you try with digital loopback.

Also, can you please confirm you are writing the initialization script given in SNLA371?

Thanks,

David

Hi David,

Please find the comment and please give us your advise.

We can write to other register w/o any problem. We also tried digital loop back, but didn't work.

Next, we tried initialize script in SNLA371, then we could confirm the packet is sent. We confirmed that by reading 0x639-0x63A and they were counting up. But 0x63C-0x63D is still 0x0000.

The process is below which is shown in Table3-2. (executed in Slave mode)

Write Reg 0x1f = 0x8000
Write Reg 0x573 = 0x101
..........................
..........................
Write Reg 0x8be = 0x201
Write Reg 0x56a = 0x5f40
Write Reg 0x16 = 0x108
Write Reg 0x405 = 0x2800
Write Reg 0x619 = 0x1555
Write Reg 0x624 = 0x55bf
Write Reg 0x573 = 0x1
Write Reg 0x56a = 0x5f41 

We could confirm packet is sent up to this point.

Read Reg 0x639 = 0x01b5
Read Reg 0x63a = 0x0015
Read Reg 0x63b = 0x0000
Read Reg 0x63c = 0x0000

Best regards,
Yuto

Hi David,

Please find the comment from the customer. If you need more information, please let me know what you need to resolve.

Best regards,
Yuto

Hi Yuto,

The register dump you shared shows that SGMII link is up and MDI link is up. Data should be able to transfer in this case. Is my understanding correct that 0.0056% of the packets sent have errors and 99.44% are error free?

I see your SGMII lines are very long, have multiple vias, and have an in-line connector. This may be contributing to the packet loss. Note the loopback testing should be conducted without the link partner connected. Can you try this and let me know if the MAC is seeing packet errors?

Thanks,

David