Linux/66AK2G12: Difficulty validating RGMII timing with DP83867 PHY

Jeffrey Limbocker

Part Number: 66AK2G12
Other Parts Discussed in Thread: SN74AUP1T34

Tool/software: Linux

Hello,

As mentioned in the "related post" () I have been working on a design using the 66AK2G12 and DP83867. We had a significant number of changes between the prototype run and our first production units. In the process of bringing up these units, I have run into the problem where Ethernet works at 100Mb but does not work at 1Gb. Since this issue was previously solved by adjusting timing settings, I have begun to dig into the timing on these units. These measurements are at the edge of what my scope can read, but snla243.pdf suggests that it should be sufficient. I am able to see clock and data on the RX side of the RGMII bus, but I do not see any data traffic on the TX side when running at 1Gb. I do, however, see data going both ways when running at 100Mb. I have been able to measure the timing of the RX bus and adjust it so that setup and hold are within limits, but since I see no traffic on the TX side, it is difficult to validate the timing.

Relevant info:
Processor SDK Linux 5.1
PHY is being clocked off of CLKOUT @ 25MHz
Device Tree for ethernet phy, mdio, etc matches DTS for K2G ICE, which uses this phy.
Trace lengths of all RX/TX signals are well matched with each other (<15 mils)
Ethernet CLKCTL is set such that CLKOUT puts out a 25MHz clock
Ethernet CFG is set such that the mode is RGMII. I have tried enabling and disabling IDELAY as part of my timing experiments.
Occasionally, U-Boot is able to secure a DHCP lease. When this happens, no further transfers can be made.
Sometimes DHCP requests can be seen on a Wireshark capture. This is not consistent or easily reproduced.
I have had to modify U-Boot from the reference design to eliminate the board detection code.

Please let me know what other information is needed so that we can figure this out.

Jeff

over 7 years ago

0 Yordan Kovachev over 7 years ago

TI__Guru**** 161600 points

Could you share the bootlog & your dts files?

Best Regards,
Yordan

0 Jeffrey Limbocker over 7 years ago in reply to Yordan Kovachev

Expert 2380 points

Yordan,

The attached archive contains all of the modified u-boot source files as well as a copy of the serial output from the verbose bootlog for U-Boot (added #define DEBUG to include/configs/k2g_evm.h).

Jeff4555.filesForForum.zip

0 Yordan Kovachev over 7 years ago in reply to Jeffrey Limbocker

TI__Guru**** 161600 points

Hi,

Sorry for the delay. The dts files look fine. The bootlog is good too.

I've asked the design team to help on this one.

Best Regards,
Yordan

0 Schuyler Patton over 7 years ago in reply to Yordan Kovachev

TI__Mastermind 40750 points

Hi Jeff,

Your question is falling between a couple of different support groups so a few different people might be responding. We need to dump the first registers of the MII space on the PHY from u-boot. Assuming the PHY address on the MDIO is bus is 0 in this example please dump these registers while in u-boot and attach the results:

mii dump <your phy address> <MII register>

E.g. assuming the PHY address is 0.

mii dump 0 0

mii dump 0 1

Best Regards,
Schuyler

0 Jeffrey Limbocker over 7 years ago in reply to Schuyler Patton

Expert 2380 points

Thank you Yordan.

Hi Schuyler,

Understood, looking forward to working with all of you.

I have dumped registers 0 and 1 using MII through u-boot. I have also verified that the read values are the same using MII and MDIO. The contents of the dump are below:

=> mii dump 0 0-1
0.     (1140)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:0040) 0. 6,13 =   b10    speed selection = 1000 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

1.     (796d)                 -- PHY status register --
  (8000:0000) 1.15    =     0    100BASE-T4 able
  (4000:4000) 1.14    =     1    100BASE-X  full duplex able
  (2000:2000) 1.13    =     1    100BASE-X  half duplex able
  (1000:1000) 1.12    =     1    10 Mbps    full duplex able
  (0800:0800) 1.11    =     1    10 Mbps    half duplex able
  (0400:0000) 1.10    =     0    100BASE-T2 full duplex able
  (0200:0000) 1. 9    =     0    100BASE-T2 half duplex able
  (0100:0100) 1. 8    =     1    extended status
  (0080:0000) 1. 7    =     0    (reserved)
  (0040:0040) 1. 6    =     1    MF preamble suppression
  (0020:0020) 1. 5    =     1    A/N complete
  (0010:0000) 1. 4    =     0    remote fault
  (0008:0008) 1. 3    =     1    A/N able
  (0004:0004) 1. 2    =     1    link status
  (0002:0000) 1. 1    =     0    jabber detect
  (0001:0001) 1. 0    =     1    extended capabilities


=>

This output is the same whether or not I am connected to a gigabit or 100Mb connection.

Jeff

0 Schuyler Patton over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 40750 points

Hi Jeff,
Thanks for the post. I have a couple of other things to ask for. After discussing internally usually the issue with what you are experiencing is as you suggest an issue with timing.

- In your DTS file which other timings have you tried? Also is there where you are adjusting the timings or are you doing a different method? Are you sending messages to the PHY outside of the driver.

ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;

- If you can boot into Linux what does ethtool -S <interface> show? We need to see the interface statistics. Example would be:

ethtool -S eth0

Is there any difference in the behavior U-Boot and Linux? Do you see a link reported with ethtool eth0? The same behavior of being able to acquire occasionally an IP address but no other traffic shows up on Wireshark.

Best Regards,
Schuyler

0 Jeffrey Limbocker over 7 years ago in reply to Schuyler Patton

Expert 2380 points

Schuyler,

I have been changing the timing using the DTS primarily. I have tried a number of delays, ranging from 250ps to 3ns. This proved to be a very slow process, so I decided to try to measure the signals. I have also enabled and disabled the internal delay in the MAC on the K2G, but this did not fix the issue. On an earlier revision of the board, disabling internal delay was the answer, but that does not seem to be fixing it here. I have not been sending anything to the PHY manually. All communication has been done by the driver.

Another thing I have noticed:
I have tried to validate that the timing settings are being set by the driver using MDIO read. When I attempt to read the delay register using `mdio read netcp@4000000 86` I get 0x6F. Register 0x32 reports 0x0 as well. I believe these should be getting set by the driver, but do not appear to be.

I can boot Linux using the 100Mb connection, but I don't think that will get you the statistics you are looking for. I have not yet figured out how to use the filesystem on MMC. Once I get that going I can boot into Linux without the ethernet connection and get statistics information.

0 Rex Chang over 7 years ago in reply to Jeffrey Limbocker

TI__Guru 50170 points

Hi, Jeffrey,

Sorry for the slow response. I had several internal discussions on the issue, and all agree that it looks like timing issue.

TI PHY team indicated that "as you pointed out, the typical problem when RGMII works in 100M and not in 1G is the delay settings. You may still be having these issues.

It seems like you are scoping the lines and finding no data being transmitted on the TX side. Now this may just be that the MAC isn’t receiving anything valid to respond to. Or it could be that TCP/IP is causing back-off because data errors are being encountered. Data errors likely coming from improper RGMII delay timing.

You mentioned trying to adjust the timing delay, and the first thing TI PHY team would check is the use of the extended register space access method, or else you may be making changes to registers you're not intending. The method for extended registers is captured in the 867 DS section 8.4.2.1 Extended Address Space Access.

Proper extended register space access can be verified by reading register 0x22. The response of the PHY, when not using the proper access method, is 0x2000 if reading register 0x22. The correct response to reading 0x22 with the proper method is 0x718(or something like this, our documentation on default setting is sort of dicey) on DP83867.

After you know the changes you are making to the PHY are real and effective, you can adjust the timing delays as required. Only thing to note here is that the timing delays should only be performed in 1 of the 3 typical ways per RGMII group(RX and TX). Either make the delay in the receiver, the transmitter, or the PCB traces. It happens often that the delay is set at both transmitter and receiver.

From the registers it looks like he has a link up, so we don’t think his PHY HW is an issue."

I also had a discussion with hardware engineer who had some questions including the routing. He will post his questions in this thread.

Rex

0 Bill Taboada over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 42545 points

Hi Jeff,
Just a few additional questions for clarification.
You stated that you were not seeing any traffic on the TX interface to check timing. Does that mean you never see the K2G try to set the TXEN signal in 1Gb mode?
How are you limiting the transfer speed when operating in 100Mb mode? Are you connecting to Ethernet test equipment and forcing in to negotiate to 100Mb?
You've mentioned MII a few times. Just to be clear, you are operating both the 100Mbit and 1Gbit using RGMII, correct?
You mentioned that this was a spin of a prototype board. Was the prototype operating at 1Gbit?
Sorry for the basic questions but I want to have a clear picture of your issue.
Regards, Bill

0 Jeffrey Limbocker over 7 years ago in reply to Bill Taboada

Expert 2380 points

Rex,

Thank you for your response. I have verified, using the suggested extended register access method, that the delay registers are being set according to the DTB. I have also used this method to experiment with different timing options, following the instructions in the RGMII timing budgets app note (SNLA243). I think I have TX side timing that is agreeable per the specifications. Pictures are attached. photosForForum.zip

Bill,

Answers to your questions:
1. You stated that you were not seeing any traffic on the TX interface to check timing. Does that mean you never see the K2G try to set the TXEN signal in 1Gb mode?
- K2G does set TXEN sometimes. It seems to only be set when successful DHCP lease is obtained (perhaps). I have not tested this exhaustively, but I do not see it being set frequently. Other than that, I seem to only see clock on the TX interface. When I set up the PHY to automatically generate random data and loopback to RGMII, I see a 25 MHz clock on the TXCLK line. I see what looks like decent timing (and 125 MHz clock) on the RX side. (pictures attached). Setting timing registers to 0x66 gives good setup/hold from what I can measure on my scope. 0x77 also seems to be within range. This is measured on RX lines according to the snla243.pdf timing budget guide.

2. How are you limiting the transfer speed when operating in 100Mb mode? Are you connecting to Ethernet test equipment and forcing in to negotiate to 100Mb?
I have a managed switch that has a port set at 100Mb and a port set as 1Gb. I have also limited the speed using a 100Mb switch. Both of these are in an attempt to get the PHY to autonegotiate as 100Mb.

3. You've mentioned MII a few times. Just to be clear, you are operating both the 100Mbit and 1Gbit using RGMII, correct?
We are using RGMII as our MAC interface. The references to MII were with respect to the U-Boot command `mii`.

4. You mentioned that this was a spin of a prototype board. Was the prototype operating at 1Gbit?
The prototype did operate at 1Gbit after disabling internal delay in the MAC. (using BOOTCFG_ETHERNET_CFG)

Hardware changes from prototype to production:
Changed from 66AK2G12ABY100 from 66AK2G12ABY60 (upgrade to 1 GHz). Updated 0.9V power supply to 1.0V operation. No noticeable instabilities caused by this change. Running at 600MHz and 1GHz seem to behave the same.
Added copper pour to bottom layer copper for GND beneath PHY. Bottom layer is not adjacent to any high speed signals.
Minor trace length changes, mostly to RX side. All changes <= 5 mils.
Trace length spread for RX changed from 15 mils to 17 mils.
Trace length spread for TX did not change (5 mils).
Prototype phy ran off of crystal. Production runs off of K2G Generated 25 MHz CLKOUT.

Software behavior (U-Boot) running the PHY with specified delay:

Set timing to 0x66
DHCP worked first time.
Ping worked 8 times in a row, failed on 9th.

TFTP does not work.

=> tftpboot zImage
Trying netcp@4000000
. done
TFTP blocksize = 1468, timeout = 5000 ms
Using netcp@4000000 device
TFTP from server 192.168.0.14; our IP address is 192.168.0.216
Filename 'zImage'.
Load address: 0x82000000
Loading: efi_add_memory_map: 0xbcecb000 0x1 0 yes
unhandled device class: netcp@4000000 (19)
efi_add_memory_map: 0xbceca000 0x1 0 yes
send option "timeout 5"
#Server did not acknowledge timeout option!
T T T T T T T T T T T T T T T

Sometimes TFTP transfers no blocks, sometimes it transfers 5 blocks, sometimes it transfers 10 blocks, etc. Always times out.

DHCP sometimes fails like so:

=> dhcp
Trying netcp@4000000
. done
BOOTP broadcast 1
DHCPHandler: got packet: (src=37663, dst=3113, len=516) state: 3
Filtering pkt = -1
BOOTP broadcast 2
BOOTP broadcast 3
DHCPHandler: got packet: (src=137, dst=137, len=50) state: 3
Filtering pkt = -1
DHCPHandler: got packet: (src=138, dst=138, len=174) state: 3
Filtering pkt = -1
DHCPHandler: got packet: (src=138, dst=138, len=174) state: 3
Filtering pkt = -1
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3
DHCP: state=SELECTING bp_file: ""
TRANSITIONING TO REQUESTING STATE
dhcp_send_request_packet: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len = 342
DHCPHandler: got packet: (src=37663, dst=3113, len=516) state: 4
Filtering pkt = -1
DHCPHandler: got packet: (src=137, dst=137, len=50) state: 4
Filtering pkt = -1
DHCPHandler: got packet: (src=138, dst=138, len=174) state: 4
Filtering pkt = -1
DHCPHandler: got packet: (src=5353, dst=5353, len=285) state: 4
Filtering pkt = -1
BOOTP broadcast 4
DHCPHandler: got packet: (src=59955, dst=1900, len=175) state: 3
Filtering pkt = -1
DHCPHandler: got packet: (src=5353, dst=5353, len=285) state: 3
Filtering pkt = -1
DHCPHandler: got packet: (src=1534, dst=1534, len=8) state: 3
Filtering pkt = -1
BOOTP broadcast 5

DHCP sometimes succeeds like so:

=> dhcp
Trying netcp@4000000
. done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3
DHCP: state=SELECTING bp_file: ""
TRANSITIONING TO REQUESTING STATE
dhcp_send_request_packet: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len = 342
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 4
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 4
DHCP State: REQUESTING
net_boot_file_name: zImage
Initial value for argc=3
Final value for argc=3
DHCP client bound to address 192.168.0.216 (1058 ms)
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3

Thank you both for your help. I will be working the next few days on getting my SD Card driver issues sorted out so I can use the filesystem on the SD card, boot Linux, and get the ethernet statistics from Linux.

Jeff

0 Rex Chang over 7 years ago in reply to Jeffrey Limbocker

TI__Guru 50170 points

Hi, Jeff,

When you have a chance, could you also dump the link status? The link status for 10/100Mbit operation is found in reg BMSR at address 0x0001. Bit 8 specifies that the information for 1000Mbit operation is found in the extended status register 1KSCR at address 0x000F. It would be good to have that register value as well.

It will be good to have these register values for 1Gb when DHCP gets through and when it is not. If it is not too much trouble, 100Mb too for comparison.

Rex

0 Jeffrey Limbocker over 7 years ago in reply to Rex Chang

Expert 2380 points

Fullscreen regDumps.txt Download

Power-up: Delay Reg = 0x58
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0xbc02
18 - 0x0
19 - 0x1d04
20 - 0x29c7
21 - 0x7
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

Link detected.

DHCP Fail:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0xac02
18 - 0x0
19 - 0x504
20 - 0x29c7
21 - 0x10
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

Link present.

DHCP worked:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0xac02
18 - 0x0
19 - 0x504
20 - 0x29c7
21 - 0x1c
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

Changed timing to 0x77
DHCP fail:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x77
15 - 0x3000
16 - 0x4040
17 - 0xac02
18 - 0x0
19 - 0x504
20 - 0x29c7
21 - 0x2b
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

DHCP Success:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x77
15 - 0x3000
16 - 0x4040
17 - 0xac02
18 - 0x0
19 - 0x504
20 - 0x29c7
21 - 0x30
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

===============================================
100Mbit
DHCP Success:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0x81
6 - 0x64
7 - 0x2001
8 - 0x0
9 - 0x300
10 - 0x0
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0x4f02
18 - 0x0
19 - 0xc40
20 - 0x29c7
21 - 0x0
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0
TFTP Success:
0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0x81
6 - 0x64
7 - 0x2001
8 - 0x0
9 - 0x300
10 - 0x0
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x0
15 - 0x3000
16 - 0x4040
17 - 0x4f02
18 - 0x0
19 - 0x0
20 - 0x29c7
21 - 0x0
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

Rex,

I went ahead and dumped the first 32 registers for the following cases:

Power-up, timing set to 0x58
DHCP Fail (1Gbit)
DHCP Success (1Gbit)
Set timing to 77, DHCP Fail
Set timing to 77, DHCP Success
100Mbit DHCP success
100Mbit TFTP Success

For brevity's sake, I will post the differences between these in the post, but include a txt file with all of the register dumps as an attachment.

At Power-up, the registers read like so:

0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0xc1e1
6 - 0x6d
7 - 0x2001
8 - 0x48c3
9 - 0x300
10 - 0x38ff
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0xbc02
18 - 0x0
19 - 0x1d04
20 - 0x29c7
21 - 0x7
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

After a DHCP Fail, registers (base 10) 17, 19, and 21 have changed.

17 - 0xac02
19 - 0x504
21 - 0x10

Upon the first DHCP success, register 21 has changed.

21 - 0x1c

I then changed the timing to 0x77. Registers 14 and 21 changed.

14 - 0x77
21 - 0x2b

Upon the next DHCP success, register 21 has changed.

21 - 0x30

This seems to be indicating an increasing number of RX errors. I then switched to the 100Mbit port. This resulted in a 1st try DHCP success. The registers are below.

0 - 0x1140
1 - 0x796d
2 - 0x2000
3 - 0xa231
4 - 0x1e1
5 - 0x81
6 - 0x64
7 - 0x2001
8 - 0x0
9 - 0x300
10 - 0x0
11 - 0x0
12 - 0x0
13 - 0x401f
14 - 0x58
15 - 0x3000
16 - 0x4040
17 - 0x4f02
18 - 0x0
19 - 0xc40
20 - 0x29c7
21 - 0x0
22 - 0x0
23 - 0x40
24 - 0x6150
25 - 0x4444
26 - 0x2
27 - 0x0
28 - 0x0
29 - 0x0
30 - 0x2
31 - 0x0

I also realized that I misspoke in my previous post. The addition of a GND plane to the bottom side of the board is not correct. We added a ferrite to the 3.3V power supply for the PHY, per a suggestion on this forum. The copper pour we added was for the 3.3V ethernet supply. I bypassed this ferrite with a piece of wire and found no change in performance. In the prototype, the 3.3V supply pins were all directly connected (with bypass caps) to the 3.3V power plane.

Jeff

0 Bill Taboada over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 42545 points

Hi Jeff,
The first oddity is that the K2G is driving a 25MHz clock on the TX_CLK signal. In 1000baseT operation. That clock should be operating at 125MHz similar to what you are seeing on the RX_CLK driven by the PHY. Based on the register dump, the PHY has negotiated to 1000baseT full duplex so I would expect the K2G to read the PHYSTS register and program the the interface accordingly. Can you check the prototype board to see if it is driving the TX clock correctly? Just to be sure that the internal PLLs are being set correctly on the production board, can you also look at the TX CLK signal in 100baseT mode and verify that it is operating at 25MHz?

You also mentioned that you are using the CLKOUT signal and not the crystal on the PHY. If the crystal used for the K2G is adding too much jitter, that jitter will carry forward into the PHY. That may explain the RX errors at 1000baseT operation. Would it be possible to add the crystal to the prototype board to see if the behavior changes?

Regards, Bill

0 Jeffrey Limbocker over 7 years ago in reply to Bill Taboada

Expert 2380 points

Rex,

It appears that placing the crystal on the board fixed the issue.

The input oscillator for the K2G is within the specifications listed in the datasheet, though it does pass through two buffers on its way into the device. One buffer serves as a clock distribution buffer, and the second translates the 3.3V output of the oscillator into the 1.8V the K2G needs. If the output of the K2G CLKOUT isn't within specifications for the PHY, should we be concerned about the rest of our clock distribution?

Jeff

0 Bill Taboada over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 42545 points

Hi Jeff,
The CLKOUT signal is not the default state of that pin upon reset of the K2G. Are you configuring the pin and driving 25MHz clock out before releasing the PHY from reset?
Regards, Bill

0 Jeffrey Limbocker over 7 years ago in reply to Bill Taboada

Expert 2380 points

From what I can tell from the U-Boot source code, CLKOUT is getting enabled just before a PHY reset occurs.

Are there some tests we could run to gain some confidence in our clock distribution within the device?

Jeff

0 Bill Taboada over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 42545 points

Hi Jeffrey,
What section of the clock tree are you concerned about? Also, can you tell me more about your clocking circuit? Are you providing SYSCLK with a crystal or with an oscillator? Is the CLKOUT connection to the PHY a point-to-point connection between the K2G and a single PHY? Can you provide the schematic connections for these signal?
Regards, Bill

0 Jeffrey Limbocker over 7 years ago in reply to Bill Taboada

Expert 2380 points

Bill,

After installing the crystal fixed the ethernet problem, I decided to take a look at CLKOUT and SYSCLKOUT on an oscilloscope. I found there was some observable jitter on both of these outputs. When viewed 1us after the trigger, both clocks showed timing variations around 4ns pk-to-pk. This created some doubt regarding the cleanliness of the clocks.

We are running the SYSCLK off of an oscillator, CTS PN CB3LV-3I-24M0000. This oscillator is passing through two buffers on it's way to the K2G, one serves as a fanout, and the other is a level translator to step it down to 1.8V for the K2G. The fanout buffer is SN74LVC126AD, and the level translator is SN74AUP1T34. If this description is not sufficient, I can provide a schematic.

The CLKOUT connection is direct with a capacitive divider between the PHY and CLKOUT as suggested by the PHY datasheet. There is a screenshot of the schematic for the CLKOUT to PHY attached to one of the earlier posts in this thread.

Jeff

0 Bill Taboada over 7 years ago in reply to Jeffrey Limbocker

TI__Mastermind 42545 points

Hi Jeff,

You stated that you took measurements of the CLKOUT and SYSCLKOUT signals. Did you repeat that test for the SYSCLK input? Most of the IPs within the device are more tolerant of jitter than the Ethernet interface. The main concerns are the Ethernet subsystem, the DDR and the PCIE. Jitter on the clocks could be a result of jitter on the SYSCLK input or noise on the supply lines or the ground connections for the PLLs.

Regards, Bill

0 Bill Taboada over 7 years ago in reply to Bill Taboada

TI__Mastermind 42545 points

Hi Jeff,
We haven't heard back from you in a while. I will close this thread. You can reopen the discussion by posting if you have any other questions.
Regards, Bill

Processors

Processors forum

Linux/66AK2G12: Difficulty validating RGMII timing with DP83867 PHY