RGMII clock delays

Hi Bennie,

The DP83867 has internal delay functionality built into the device. There are registers within the device that allow you to control the amount of delay.
Do you know if your MAC uses align mode or shift mode when sending out data? Also, does the MAC have built-in internal delay on the RX path?
The DP83867 has internal delay on both RX and TX paths. The delays can also be selected using hardware bootstraps.

Kind regards,
Ross

Yes the MAC has all that... After it is programmed.
I needed to add two feet of wire to get it to initially connect so I can program it.

Also, the RGZ device has delay strapping, but unfortunately I designed in the PAP device.
Looking for a hardware delay.
I may change the device on the re-spin.

Hi Bennie,

I am having a hard time understanding what you need.

Can you please elaborate on what the issue is?

Kind regards,
Ross

Ross:
Okay.
The board is designed.
There are no delay straps on the DP8386.
There are no delay straps on the Marvell 88LX3142 with the MAC and I have no access to change the firmware.
The RGMII will not connect when we power up.
I put 2 feet of wire-wrap wire on the GTX_CLK and the RX_CLK and managed to get 100 Base-t communications.
I am asking if anyone has ever used a non-inverting logic chip as a delay for the clocks.
Thanks

Hi Bennie,

I have not used non-inverting logic chips to delay the clock lines. In theory it should work though.

Before you go down that route though, why don't you get the USB-2-MDIO GUI up and running on your computer to talk to the DP83867 and program the PHY to see if adjusting the delays fixes the issue.

The GUI is free for download and all you need is an MSP430 launchpad. All you need to do is do two flyby wires for MDIO/MDC and ensure the PHY and MSP have a shared ground reference.

www.ti.com/.../usb-2-mdio

Kind regards,
Ross

Ross:

Thanks, I have ordered the eval board.

I am not certain this is a solution as much as an opportunity to determine the delay needed.

The MDIO and MDC is already wired to the 3142 and I need to cut the traces to add this test option.

I am also not sure I can make the change and keep it through power cycle while I re-connect the MDIO/MDC.

Either way, I think I will design in the 64 pin package with the clock speed strapping on my re-spin.

Thanks

Hi Bennie,

You are correct that it is not a mitigation plan but just a debug option so it allows you to figure out the best delay for your system.

Is there then no way you can modify your driver to program the delay?

Apologies for the inconvenience. Was it not clear in the datasheet that the signals are aligned? Just want to know so we prevent this in the future and allow for the easiest integration into systems.

Kind regards,

Ross

Ross:

You have been most helpful this week.

I have the Launchpad working with the MDIO too and I can change the clock relationship with the data.

As I watch the MAC receive clock and one data line, I can see the clock running at 25 MHz, and periodically change to 125 MHz.

After three or four tries it stays at 25 MHz.

The computer shows a connection at 100 Mbps, but the Marvell 3142 does not show a connection to the Ethernet.

What should I be looking at to see if the RGMII auto-negotiation is working?

Thanks again.

Bennie

Hi Bennie,

Glad that the MDIO tool is working for you.

From what you describe, it appears that the device is trying to negotiate to 1G speed but is failing to do so and defaults down to 100Mbps speeds.

Just so I have a complete understanding of your test setup, please confirm this is what you are doing:

Marvell 3142 (RGMII MAC) <-> DP83867 (RGMII) <-> CAT5 or CAT6 cable <-> Link Partner (1G PHY)

Auto-Negotiation takes place on the cable side of the DP83867 and not on the MAC side, unless you are using SGMII, in which case both sides use auto-negotiation. For RGMII, once the cable side link is established (1G or 100M or 10M), the speed of RX_CLK will adjust accordingly. For 1G speed, RX_CLK will be 125MHz. For 100M speed, RX_CLK will be 25MHz. For 10M speed, RX_CLK will be 2.5MHz.

What is the capability of the link partner? Are it appears the DP83867 thinks the partner is a 100Mbps PHY.

When you say that the Marvell 3142 does not show a connection, does that mean that you are reading register 0x0001 in the DP83867 register set and do not see link bit being set?

Kind regards,
Ross

Hey Ross:

Thanks for staying with me.

I have been designing for over 30 years, but this is my first Ethernet experience, so treat me like a novice please.

First of all, yes the connections is as you state.

The only capabilities I have for monitoring the 3142 activity is called a Spirit tool by Marvell.

Originally, nothing worked at power up so I added about two feet of wire to each RGMII clock and the Spirit tool showed a connection from the PC to my UUT.

We could upload  3142 boot loader and firmware okay at 100 Base-T, then the trouble began.

After we flashed the firmware onto the 3142 at 100 Base-T we were instructed to re-boot to get up to 1000 Base-T.

It appeared at first that the clock delays were off so we started tweaking the delays with non-inverting buffer chips.

Now that we can change the delay with via the MDIO we thought we would be home free, but no.

Now, a simple power up caused the Marvell 3142 to boot from Flash and we suspect the flashed firmware device driver is not recognizing the PHY ID and not talking properly.

We have the SDK to write our own device driver and have done that, but we have now lost the ability to hold the configure button low and load from the firmware via Ethernet as we did before. 

If I watch the RGMII clocks with a configure power cycle, the GTX_CLK goes low and stays low during the entire boot and the computer never shows a connection in the bottom right.  The RX_CLK starts at 2.5 MHz, and periodically pulses 125 MHz, the 25 MHz.  the RX_CLK then stays stable at 25 MHz.

If I watch the clocks with a simple power cycle the TX_CLK comes up at 25 MHz thought-out, and the RX_CLK starts at 2.5 MHz and periodically samples 125 MHz a few times, then changes to 25 MHz and locks on immediately, the computer shows a 100 Base-T connection in the bottom right.  The Marvell Spirit tool shows no contact with the UUT though even if I go through the full range of delays.with the MDIO tool.

I want to make sure I understand the process, correct me is I am wrong:

-  The computer negotiates the highest speed with the Ethernet PHY chip via the CAT x cable.

-  The PHY starts at 2.5 MHz on the RX_CLK and periodically bursts 125 MHz to the MAC, if that doesn't work it bursts 25 MHz to the MAC.

-  When the MAC receives the highest frequency it is programmed to support it sets the TX_CLK to that frequency and the RGMII negotiation is complete. 

-  Now it is a matter of getting the data and clock delay correct?

By the way, I have ask Marvell if there is a way to load the firmware via JTAG and hopefully bypass this start-up issue and get the updated device driver loaded.

Thanks again.

Bennie

Hi Bennie,

I hope you have continued to make progress on your system board.

I think your process is slightly off considering that the DP83867 wont change its speed based on the MAC's interface. The DP83867 will change it's connection speed only based on the capability of the link partner or through commands on the MDIO.

It sounds like the secondary boot loader of the 3142 has a device driver in it that may be using MII or RMII modes for the MAC. If the connection to the PC is negotiating to 100M, I'd suspect the secondary boot loader's device driver is setting auto-negotiation advertisement registers to 100M.

A typical behavior of boot loader Enet PHY drivers is to reset the PHY multiple times before it gives up and says no connection can be made. This may be why you are seeing the RX_CLK transitioning.

Did you completely cut the traces for MDIO/MDC between the 3142 and the DP83867 in order to get the USB-2-MDIO hardware inserted?

Best Regards,

Ross:

Another quick question for the DP83867.

We used the driver Marvell created for the DP83865 as a reference to create our driver using the Marvel SDK.

Are there many major differences between the DP83867 and the DP83867 drivers?

Thanks

Bennie

Hi Bennie,

The base registers (IEEE defined registers) will be the same between the two, but not any of the special feature registers. 

I would suggest looking for the features you are looking for in the 867 and then compare to see if the same bit and register description is same for 865. 

Kind regards,

Ross

Ross,

In the process of developing a driver for the 867 we started with a known working driver for the 865.  We did what you were suggesting in mapping the features used with the 865 to the correct registers in the 867 but have not had success.  Could we get the source code of a working driver for the 867 to compare against ours.

Bennie

Bob:

Yes, I did cut both lines.

They are jumped back now.

We have the devices running at 100 BASE T just fine.

Can you recommend any contractors in the Austin area that can provide face-to-face help?

Bennie 

Ross:
We discovered registers 0x0D and 0x0E need to be used to the extended registers and we are working great at 100 BASET.
We still cannot auto negotiate 1000 BASE T.
Can you recommend a contractor in the Austin area the we can get some face-to-face time?

Bennie

Hi Bennie,

I have not personally worked with a contractor in Texas, but we do have a TI third party member that works with 1G Ethernet in the Dallas area.

Dallas Logic:
www.ti.com/.../companyfolder.tsp

Best Regards,

Ross:

Someone passed me a presentation on the Auto-negotiation between the computer and the PHY, so I scoped out the CAT 5 signals.

I put the scope on the Twisted Pairs (TPs) and can see the Normal Link Pulses (NLP) quickly followed by 1000 BASE T data on all four TPs.

So it looks like the PHY interface to the computer is indeed auto-negotiating gigabit Ethernet.

I followed the path through the state machine and believe the MAC is not responding before the timeout and resetting the link.

 

I also looked at each RX_Data bit on the RGMII during the auto negotiation and notices that none of the data bits are changing when the RX_CLK is running at 125 MHz.

I am not sure if this may be the reason the MAC is not responding, or if the data should indeed be all Zeros.

 

Either way, this reinforces my belief that the issue is between the MAC and PHY on the RGMII.

Do you know if there is any condition that would allow the PHY to pass the clock with zero data?

Thanks

Bennie

All:

Before I declare my design with the TI DP83867 a failure I want to desperately reach out one more time for any help on troubleshooting the RGMII auto-negotiate issue.  I would appreciate any referrals anyone has to offer.\

Thanks

Bennie

Hi Bennie,

Could you elaborate what is nature of the problem and which variant of DP83867 you are using? DP83867 supports internal clock delays in RGMII mode and they have to be enabled through register 0x32 bits [1:0]. The delay value can be changed with straps or register 0x86.
The register description can be found in the datasheet.

-Regards,
Aniruddha

Aniruddha:

It looks like my original post did not take, I will re-print it.

We are using the DP83867IRPAP with MII/GMII/RGMII interface, this is a dual use board to support MII and RGMII daughter boards.

We wrote a driver for the MAC and finally have control of the clock delay setups.

Our issue now is the 1000BASE-T auto-negotiation process on power up.

I can watch the Cat 5 twisted pair and see the negotiation pulses followed by a very short burst (less than a second) of 1000BASE-T data.

This happens several times and then changes to 100BASE-T data.

I can look at the RGMII clock and data and watch the RX clock change from low frequency to 125 MHz during the very short burst.

I notice no change in the RX data during this burst, I also notice no change in the TX clock or data at this time.

After several cycles the RX clock changes to 25 MHz and stays.  The TX clock changes to 25 MHz and the computer shows a 100MHz link.

My weakness is knowing what the MAC and PHY should be doing during the auto-negotiation so I can verify (and/or fix) the issue.

I can force the MAC and PHY to 1000BASE-T in the driver and both clocks come up with 125 MHz, but there is no link between the MAC and PHY according to the MAC applications status.

I need some detailed information on the RGMII auto-negotiation, or better a contractor who can come and look at my board.

I am in Round Rock Texas.

Thanks

Bennie