Marvell 88EE1111 PHY tranciever MDIO reg configuration

[Altera_Forum]

I'm trying to troubleshoot PHY for my dual Ethernet design on the DE2-115 Cyclone IV board. (I have to load my *.elf file twice for some reason for my design to work).  

 In trying to figure out what's I notice that the DE2-115 uses the Marvell 88EE1111 PHY Tranciever chip. As per IEEE 802.3 2015, MDIO registers 0-15 are standard, but 16-31 are manufacture dependent. Does anyone have any leads on configuring Marvell 88EE1111? The "datasheet" on their website is only a product brief and does not describe what the registers do.    I noticed in an excerpt from the Altera University TSE example (below), register 20 is written to in order to set up delay for input/output clk, but neither Altera nor Marvell provide any further information on why they chose this value or what it means. // Write to register 20 of the PHY chip for Ethernet port 2 to set up delay for input/output clk *(tse + 0xB4) = *(tse + 0xB4) | 0x0082;

[Altera_Forum]

This is the top level module 

 module tse_tutorial(  // Clock  input CLOCK_50,    // KEY  input [0: 0] KEY,    // Ethernet 0  output ENET0_MDC,  inout ENET0_MDIO,  output ENET0_RESET_N,    // Ethernet 1  output ENET1_GTX_CLK,  output ENET1_MDC,  inout ENET1_MDIO,  output ENET1_RESET_N,  input ENET1_RX_CLK,  input [3: 0] ENET1_RX_DATA,  input ENET1_RX_DV,  output [3: 0] ENET1_TX_DATA,  output ENET1_TX_EN );   wire sys_clk, clk_125, clk_25, clk_2p5, tx_clk;  wire core_reset_n;  wire mdc, mdio_in, mdio_oen, mdio_out;  wire eth_mode, ena_10;   assign mdio_in = ENET1_MDIO;  assign ENET0_MDC = mdc;  assign ENET1_MDC = mdc;  assign ENET0_MDIO = mdio_oen ? 1'bz : mdio_out;  assign ENET1_MDIO = mdio_oen ? 1'bz : mdio_out;    assign ENET0_RESET_N = core_reset_n;  assign ENET1_RESET_N = core_reset_n;    my_pll pll_inst(  .areset (~KEY[0]),  .inclk0 (CLOCK_50),  .c0 (sys_clk),  .c1 (clk_125),  .c2 (clk_25),  .c3 (clk_2p5),  .locked (core_reset_n)  );     assign tx_clk = eth_mode ? clk_125 : // GbE Mode = 125MHz clock  ena_10 ? clk_2p5 : // 10Mb Mode = 2.5MHz clock  clk_25; // 100Mb Mode = 25 MHz clock    my_ddio_out ddio_out_inst(  .datain_h(1'b1),  .datain_l(1'b0),  .outclock(tx_clk),  .dataout(ENET1_GTX_CLK)  );     nios_system system_inst (  .clk_clk (sys_clk), // clk.clk  .reset_reset_n (core_reset_n), // reset.reset_n  .tse_pcs_mac_tx_clock_connection_clk (tx_clk), // eth_tse_0_pcs_mac_tx_clock_connection.clk  .tse_pcs_mac_rx_clock_connection_clk (ENET1_RX_CLK), // eth_tse_0_pcs_mac_rx_clock_connection.clk  .tse_mac_mdio_connection_mdc (mdc), // tse_mac_mdio_connection.mdc  .tse_mac_mdio_connection_mdio_in (mdio_in), // .mdio_in  .tse_mac_mdio_connection_mdio_out (mdio_out), // .mdio_out  .tse_mac_mdio_connection_mdio_oen (mdio_oen), // .mdio_oen  .tse_mac_rgmii_connection_rgmii_in (ENET1_RX_DATA), // tse_mac_rgmii_connection.rgmii_in  .tse_mac_rgmii_connection_rgmii_out (ENET1_TX_DATA), // .rgmii_out  .tse_mac_rgmii_connection_rx_control (ENET1_RX_DV), // .rx_control  .tse_mac_rgmii_connection_tx_control (ENET1_TX_EN), // .tx_control   .tse_mac_status_connection_eth_mode (eth_mode), // .eth_mode  .tse_mac_status_connection_ena_10 (ena_10), // .ena_10   );   endmodule

[Altera_Forum]

Perhaps I'm missing something, but you don't seem to have ENET0 connected. You have the ENET0 MDC lines, but not ENET0_TX_DATA etc.

[Altera_Forum]

Is there any update on how to get the phy chips to work?

[Altera_Forum]

--- Quote Start ---  Is there any update on how to get the phy chips to work?  --- Quote End ---    What sort of system are you trying to create? I got it to work in VHDL using the Altera Tri Mode EMAC and 10/100 mode. If you are doing it some other way (eg via C code in a processor) that won't help much.   Do you have the 88E1111 datasheet? If not, you need to get that from Marvell.

[Altera_Forum]

--- Quote Start ---  What sort of system are you trying to create? I got it to work in VHDL using the Altera Tri Mode EMAC and 10/100 mode. If you are doing it some other way (eg via C code in a processor) that won't help much.   Do you have the 88E1111 datasheet? If not, you need to get that from Marvell.  --- Quote End ---    Marvell is a very secretive company. They will not release full device data sheets without forcing you to sign an NDA, and they will in my experience never sign NDAs with individuals, only with companies that they expect to purchase reasonable dollar volumes of parts.  Terasic made a HUGE blunder designing a Marvell part into their development board, because Marvell will NEVER release a full datasheet for their part.  Only those folks designing fully proprietary hardware that they would not even consider releasing schematics for should consider using Marvell parts.  Just my 2c. I used to work for a very big company in Silicon Valley and even we had to jump thru hoops to get detailed datasheets for Marvell parts.

[Altera_Forum]

--- Quote Start ---  Marvell is a very secretive company. They will not release full device data sheets without forcing you to sign an NDA, and they will in my experience never sign NDAs with individuals, only with companies that they expect to purchase reasonable dollar volumes of parts.  Terasic made a HUGE blunder designing a Marvell part into their development board, because Marvell will NEVER release a full datasheet for their part.  Only those folks designing fully proprietary hardware that they would not even consider releasing schematics for should consider using Marvell parts.  Just my 2c. I used to work for a very big company in Silicon Valley and even we had to jump thru hoops to get detailed datasheets for Marvell parts.  --- Quote End ---    I'm not a fan of Marvell either and we did not use them on our own board. But, for whatever reason, many many devel boards use this Phy and you often have no choice but to get it working.

[Altera_Forum]

--- Quote Start ---  I'm not a fan of Marvell either and we did not use them on our own board. But, for whatever reason, many many devel boards use this Phy and you often have no choice but to get it working.  --- Quote End ---    Why any vendor that is producing development boards would use a part that they CANNOT provide full documentation for is beyond me. It makes no sense.  That being said, it is interesting to note that ALL of Marvell senior management shown at: http://www.marvell.com/company/leadership/ are new to the company in 2016 or later. Complete overhaul of the senior management in the last 18 mos or so. So maybe things might change. Or more likely not.

[Altera_Forum]

--- Quote Start ---  What sort of system are you trying to create? I got it to work in VHDL using the Altera Tri Mode EMAC and 10/100 mode. If you are doing it some other way (eg via C code in a processor) that won't help much.   Do you have the 88E1111 datasheet? If not, you need to get that from Marvell.  --- Quote End ---    We are currently trying to configure it with VHDL and it is successful in configuring the TSE but are unsuccessful in configuring the PHYs. We are trying to trigger a device over Ethernet and accept data for a custom application.

[Altera_Forum]

--- Quote Start ---  We are currently trying to configure it with VHDL and it is successful in configuring the TSE but are unsuccessful in configuring the PHYs. We are trying to trigger a device over Ethernet and accept data for a custom application.  --- Quote End ---    I've attached some code that worked for me. It's a bit of junk code with all sorts of things I was playing around with. It's easier for me to tell you the lines to look at than to try and clean it up.   The EMAC is generated in 10/100 only mode and we hardwired the speed to 100 Mbit full-duplex. The CLK was 50 Mhz. We used MII to talk between the FPGA and Phy. If you are using gigabit, you will need to make appropriate changes (will require the 88E1111 datasheet), but the basics of talking to the Phy should work. Suggest getting it to work in 10/100 first.   Line 246 begins the EMAC declaration.   Line 352 are the register specifications.   Line 431 begins the Phy registers. Note that you should add 0x80 to the Phy register to get the value that should be written to the EMAC. For example, infamous Phy register 20 is 0x80 + 0x14 = 0x94.   This code is probably much more fancy than it needs to be in a final system, but it was useful when making all sorts of tests to try and figure out how this ridiculous Phy chip works.   The EMAC state machine types start on line 475.  Line 533 is the set of values we write to the EMAC.  Line 709 is important. The mdio line needs to be tristated when acting as an input.   The EMAC configuration logic begins on line 781.   As I recall, the long waits on lines 836 and 844 were a key to get the whole thing working.   I'd recommend adding code to read back the Phy registers to make sure you are even communicating with it at all (see line 887).   I'd also recommend using SignalTap to see how the external lines are changing.   As others have said, if this is for your own board, avoid the 88E1111. Despite Marvell's "customer hostile" attitude, I would have used it if it were the best choice. But by almost any criteria (ie cost, speed, size, power and especially ease of use), there are better ones out there. This code was for a devel board. We changed to another vendor's Phy for our own board and it was a trivial matter to get it working.

[Altera_Forum]

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.

[Altera_Forum]

--- 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.