--- Quote Start ---
Thanks, this helps a lot. We are going to try to set it up for MII and then proceed to RGMII. We are curious as to what register values are written to the phy registers. Would you be able to send that to me?
With RGMII, the Tx and Rx clocks run at double data rate and are skewed in a specific way to process the data correctly. We are unable to see what the data looks like coming out of the Ethernet port. That is our main issue.
--- Quote End ---
I'm not sure what you mean by "what register values are written to the phy registers". If you look at the EMAC user guide Table 5-1, EMAC registers 0x80 to 0x9F are the MDIO register space. So when you write a value to EMAC register 0x81, the EMAC will write to the Phy register 0x01 and you should see the appropriate mdio lines toggling. Same for reading.
If you mean what actual values to use to setup a particular Phy mode, that of course depends on the mode. For most applications, I tend to think putting the Phy in auto-negotiation mode makes the most sense. With the 88E1111 even that depends on alot of things.
Is this your own board? I assume you have the 88E1111 datasheet. It's going to be almost impossible to use it correctly without it. This chip has a very complicated set of interactions. With any luck, it can be made to boot such that the desired mode is the default and you don't have to write anything to it. The default mode is determined by the 7 CONFIG pins on the 88E1111. Tables 28 to 30 in the datasheet shows how to set those in order to choose the desired default config. They have a scheme where each CONFIG input is connected to LED outputs in order to pick a 3-bit default value for various registers. If the default is not correct, you need to manually set the registers.
I'm afraid the datasheet is plastered with watermarks specific to our NDA with Marvell, so I can't really send things from it without violating the NDA.
You're right, SignalTap will have trouble with the DDIO lines. Normally you could add a DDIO register, but the RGMII clocks probably have to be offset. Another option is to use the netlist viewers to drill down into the core and see where the RGMII lines come in, but the EMAC is encrypted and I think will frustrate that effort.
Honored Contributor
