Marvell 88EE1111 PHY tranciever MDIO reg configuration

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

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

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

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

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

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

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

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.