DP83TD510E: MII Interface timing

Hi Mike,

Can you double check the frequency for both RX clock and TX clock?

Best,

Alon

From the scope captures I sent with the post, it is pretty clear that the RX and TX clocks are 2.5MHz (400ns).

Mike.

Hi Mike,

Sorry for the confusion. Let me align with the team on this query and get back to you on Monday. 

Best, 

Alon

Hi Mike,

I understand the issue I believe, you are seeing very low rates on the receive side, why do you think it is related to the clk spec?

As far the scope shots and information you have provided, it does still fall within spec as outlined in datasheet, so I don't believe the problem to be there. 

Best,

Alon

To answer your question, we have interfaced the 510E to a standard PHY which is working - although we did have to delay the clock there to get things working in one direction (it's using RGMII instead of MII).  The point is that the APL interface to the 510E has been proven in another design.  So, that leaves the interface to the LAN9500A, or something with the LAN9500A itself (as the USB interface is pretty straightforward).  I am also discussing this with Microchip...

I agree that the 510E seems to be doing what it is supposed to from the datasheet.  However, you didn't answer my question about how it should be interfaced to a normal MAC.  Seems that the long delay of data available on the Rx lines should be a problem on a normal MAC which is clocking data in on the rising edge of the clock!  Please address this question.

Mike.

Hi Mike,

I was wondering if you could provide a block diagram for your system. 10Base-T1L is not compliant with standard ethernet, so I am wondering how it is being accomplished here. 

I am also thinking if you can perform a reverse loopback test, we can determine the problem is not MAC interface side if the incoming throughput at link partner is good or not. 

To enable loopback mode, set register 0x0016 (BISCR) register to 0x0110, and then check incoming throughput on link partner side. 

Best,

Alon

The "Existing Design" has been validated by connecting two units back to back.  We get about 10Mbps in both directions.  However, with the diagram above it is only about 1.5Mbps when data heading toward the LAN9500A.  And actually I am using the 510E Eval board instead of the Existing Design.  The APL interface in both designs is basically the same so I don't expect that is where the issue is.

It's not easy to write to the PHY because there is no micro on the board - only the LAN9500A connected to the APL PHY.  I will have to see if there is a way to write to the PHY from the LAN9500 (it does have MDC and MDIO connected between them) - using the PC and some software.

Mike.

Hi Mike, 

Okay, I will correspond with the team, please let me know if you manage to write to the PHY.

In house we use a MSP430 LaunchPad: https://www.ti.com/tool/MSP-EXP430F5529LP

And our in house software 'USB-2-MDIO': https://www.ti.com/tool/ETHERNET-SW

In order to perform register writes on PHYs without onboard MCU. I wonder if there is a way for you to interface USB2MDIO with the LAN9500A although I have not seen this done so I do not know if it is possible. 

Best,

Alon

Microchip had a utility program to write to the PHY through the LAN9500A.  I was able to read two PHY registers to verify I got the correct values.  I then wrote to the PHY to put it in MII Loopback mode as you recommended and as expected I lost my connection through the phy to the network I was attached to.  Now I can't figure out what program to use to do a loopback test.  I need to be able to have software that runs on a PC and sends and receives packets to/from the same network port.  I tried setting two instances of Jperf up on my machine - one client and one server, but it just loops back in my machine without going out the Ethernet (USB) port.  Any ideas?

Mike.

Hi Mike,

I am not familiar with Jperf VM, I see online IPERF VM, in theory there should not be a problem to run this test through a VM through a USB Ethernet adapter, let me bring this up with the team and see if someone is more familiar with your application.

Best,

Alon

Jperf is just a GUI that runs Iperf so you don't have to figure out the command line parameters.  I can use Iperf as well.  The issue is that you only have one connection from the DUT via the USB cable which enumerates as a Network port on the PC.  If you set up an Iperf server in one window and Iperf client in another window on the computer it 'works' but the data never goes out the port (all internal within the PC) so you get 4Gbps!  I can't figure out how to setup Iperf to do loopback over one network port...

Mike.

Hi Mike,

What MAC interface are you using between LAN9500A and PC?

This is difficult to debug from afar, but we need to isolate whether the issue is with how the VM and packet sending is set up, or if the issue is with the design of the system, 

Mike Strauser said:

T

In this schematic, where are you trying to trigger the loopback, on which PHY? What MAC interface is being used? How do we know we are getting link-up?

Best,

Alon

Alon,

The LAN9500 is the MAC.  It is a bridge chip - USB connected to the PC which enumerates as an Ethernet port with the drivers they provide.  So inside the LAN9500 it has a MAC address.  It supports an internal or external phy - we have set it to external phy (which is a strap setting) so it has an MII interface to the T1L PHY.

In my diagram, I am setting the loopback up as you suggested (set register 0x0016 (BISCR) register to 0x0110) - so in the T1L PHY.  I use a utility program on the PC that Microchip provides that allows me to read and write over the MDIO interface between the LAN9500 and the T1L PHY.  I can read a couple of registers from the PHY and verify that they get the expected reset values.  Then I write to the PHY to set the loopback mode as I explained above.  At that point, I lose comms to the office network as expected due to the loopback.  I just don't know what software to run on the PC (and how to configure it) to do a loopback test over a single Ethernet port on the PC (that is not normally what you do with Iperf.

Mike.

Hi Mike, 

I am unfamiliar here with the manner in which you are setting this up as in house we use a device called SmartBits. Of course I know that is not possible here. 

I have reached out with your query.

The manner is which we recommend you to approach this, is to send the packets as raw data over the socket, and then add logic to receive it back, at which point you could compare the content received to the content sent. 

Best,

Alon

Actually it is possible.  We have a SmartBits as well.  Due to the fact that the LAN9500A requires drivers in order to enumerate as an Ethernet port, we can't directly connect it to SmartBits.  But we could connect it to a PC, connect the PC RJ45 to SmartBits, and bridge the two Ethernet ports together in the PC (Windows supports this).  As long as SmartBits supports loopback testing on a single Ethernet connection, it would work.  Does it do that?  I haven't used it but a colleague has (but not as a loopback on a single ethernet port).

Mike.

Hi Mike,

If you have SmartBits, why not connect them at the end of your system

and then enable reverse loopback at the first 510 PHY, and then in the SmartBits monitor, read the data-rates you are seeing for received and sent. 

If we see normal rates then we can determine the low data rate problem is on the LAN9500 side I would think. 

what do you think?

Moreover, you can send packets between PC and SmartBits over your system, and then see data rates on either side as well. 

Best,

Alon

Alon,

I did set up the SmartBits with the Reverse Loopback at the leftmost 510 PHY and saw normal data rates.  So the issue is either with the USB, LAN9500A, or MII interface between the LAN9500A and the 510 PHY.  

I have been unable to get SmartBits to work on the left side of the LAN9500A.  The reason is that the LAN9500A has to have drivers (in the PC) to enumerate the USB as a Network interface - so it has to be connected to the PC - can't connect directly to SmartBIts even though we have a USB port card.  I tried bridging the LAN9500 Network interface to the RJ45 ethernet port in the PC and do not get traffic thru it.  I think the Bridge is filtering packets based on IP address.  Not sure how to fix that - or what other method might work.

Mike.

Alon,

I just did another test.  I did a Speedtest on the PC while having Wireshark looking at data on the USB port used by the LAN9500A on my computer.  I saw NO USB errors.  This seems to then point to the MII interface.  When I started this post I felt like the MII interface was the issue but you have never addressed that concern.  Please refer back to the original post where I included scope captures of the MII signals.  Here is why I think there is an issue (in fact I wonder why it works at all):

Let's focus only on the RX lines (data flowing from the PHY to the LAN9500A).  The RXCLK is generated from the PHY.  The 510E datasheet says that data is valid 100-300ns AFTER the rising edge of the clock.  Why in the world does this take so long?  I know you can't change that now, but it really causes problems for us to interface a MAC to it!  From my scope captures we see RXD3 changing on the falling edge of the clock - so 200ns after the rising edge.  That falls within your chip's specs BUT I think we have an issue when the clock and data lines are just directly connected to the LAN9500A.  From the LAN9500A datasheet, it expects the data to be valid 8ns BEFORE the rising edge of the clock and hold for 9ns AFTER the rising edge of the clock.  Correct me if I am wrong but it doesn't look like this should work at all.  My questions are:  Do you concur?  What am I supposed to do about this?  Seems like I need to delay the RXCLK from the 510E to the LAN9500 by at least 308ns to meet the PHY and LAN9500A.  That's not easy to do.  I can invert the clock which will delay things 200ns, but that's not really enough.  Whatever has to be done requires adding parts to the design - need to do this in a minimal and cost effective way.

Mike.