TSE MAC Software Reset doesn't complete

[Altera_Forum]

Dear All, 

Does anyone know what could cause the MAC software reset procedure doesn't complete? I mean bit SW_RESET never get cleared.  Thank a lot in advance.

[Altera_Forum]

Are the rx and tx clock signals correctly driven? 

Is the hw reset pin deasserted?

[Altera_Forum]

Yes, hw_reset is deasserted. Which side rx, tx clock signal do you mean? PHY side or avalon streaming side?  

In the meanwhile i found a code implementation that doesn't have this problem. Do you think that PHY configuration, and then state, can have an impact on the MAC sw_reset completion?

[Altera_Forum]

Might be a data cache isssue??

[Altera_Forum]

might be, but don't have a clear idea on what to do to check it.

[Altera_Forum]

--- Quote Start ---   In the meanwhile i found a code implementation that doesn't have this problem. Do you think that PHY configuration, and then state, can have an impact on the MAC sw_reset completion?  --- Quote End ---   Do you mean you are running a different Nios code with the same fpga configuration? Or have you rebuild the fpga with Quartus, too?

[Altera_Forum]

Are you using the standard Altera drivers? What operating system? The standard drivers avoid the cache when reading that bit. 

Usually this problem is due to lack of clocks from the PHY side, so you should check that first.

[Altera_Forum]

--- Quote Start ---  Do you mean you are running a different Nios code with the same fpga configuration? Or have you rebuild the fpga with Quartus, too?  --- Quote End ---   I mean same FPGA configuration but sligthly different NIOS application code.

[Altera_Forum]

--- Quote Start ---  Are you using the standard Altera drivers? What operating system? The standard drivers avoid the cache when reading that bit. Usually this problem is due to lack of clocks from the PHY side, so you should check that first.  --- Quote End ---   I'm not using any driver and any OS. I have a single thread application.  I have two functions, PhyInit() and MACInit(). At a first glance I would have put them this order: MACInit(); PhyInit(); but in this way MAC sw_reset doesn't complete but it does if I put them in the opposite order. Do you mean that a lack of rxclock at the PHY-MAC interface could induce that problem? what does "avoid the cache" mean?

[Altera_Forum]

One of the tasks performed by sw_reset function is flushing the rx fifo. 

I don't know TSE MAC inner workings, but I guess that an uninitialized phy or a missing rx clock could prevent this operation from completing.

[Altera_Forum]

yes this problem could come from the lack of a rxclock on the interface between the MAC and the PHY. 

By "avoid the cache" I mean access the MAC registers through the IORD/IOWR macros, or uned an uncached pointer. If you just use a regular C pointer/structure to read the mac's registers then there is a good chance that you read a value stored in the CPU's data cache rather than the real register.

[Altera_Forum]

I actually use macros from triple_speed_ethernet.h to acces the MAC and PHY. I'm pretty sure they are all derived from IOWR/IORD. I would assume that an unconfigured PHY could cause the MAC sw_reset never ends. 

Thanks DAIXIWEN and Cris72.

[Altera_Forum]

What PHY chip are you using? You can put some signaltap probes on the signals between the PHY and the MAC to check if the clocks are there, and if you can spot an difference between the working and the failing design.

[Altera_Forum]

I'm using Marvell 88e1111. I will do the check this morning.

[Altera_Forum]

Hi guys, 

I checked if rxclock at RGMII interface trough Signal Tap LA. rx_clk it's always there, even after a power up and PHY is not yet initialized.

[Altera_Forum]

There seems to be a special procedure to set the driver/TSE/PHY in RGMII mode. I'm not sure this would affect the reset procedure though... Did you do it? 

http://www.altera.com/support/kdb/solutions/rd11122009_293.html

[Altera_Forum]

No, I didn't. I'm directly accessing TSE MAC register not using any driver.

[Altera_Forum]

From Altera's driver there are two interesting functions for your case/* @Function Description: Perform switching of the TSE MAC into GMII (Gigabit) mode. * COMMAND_CONFIG register is restored after reset. * @API Type: Public * @param pmac Pointer to the TSE MAC Control Interface Base address */ alt_32 tse_mac_setGMIImode(np_tse_mac *pmac) { alt_32 helpvar; helpvar = IORD_ALTERA_TSEMAC_CMD_CONFIG(pmac); helpvar |= ALTERA_TSEMAC_CMD_ETH_SPEED_MSK; IOWR_ALTERA_TSEMAC_CMD_CONFIG(pmac,helpvar); return SUCCESS; }/* @Function Description: Change operating mode of Marvell PHY to RGMII * @API Type: Internal * @param pmac Pointer to the first TSE MAC Control Interface Base address within MAC group */ alt_32 marvell_cfg_rgmii(np_tse_mac *pmac) { alt_u16 dat = IORD(&pmac->mdio1.reg1b, 0); dat &= 0xfff0; tse_dprintf(5, "MARVELL : Mode changed to RGMII/Modified MII to Copper mode\n"); IOWR(&pmac->mdio1.reg1b, 0, dat | 0xb); tse_dprintf(5, "MARVELL : Enable RGMII Timing Control\n"); dat = IORD(&pmac->mdio1.reg14, 0); dat &= ~0x82; dat |= 0x82; IOWR(&pmac->mdio1.reg14, 0, dat); tse_dprintf(5, "MARVELL : PHY reset\n"); dat = IORD(&pmac->mdio1.CONTROL, 0); IOWR(&pmac->mdio1.CONTROL, 0, dat | PCS_CTL_sw_reset); return 1; }(change mdio1 to mdio0 if you are using the first mdio register bank)

[Altera_Forum]

that's very interesting DAIXIWEN, 

I do almost the same things in my code but, in this code:  alt_32 marvell_cfg_rgmii(np_tse_mac *pmac) { alt_u16 dat = IORD(&pmac->mdio1.reg1b, 0); dat &= 0xfff0; tse_dprintf(5, "MARVELL : Mode changed to RGMII/Modified MII to Copper mode\n"); IOWR(&pmac->mdio1.reg1b, 0, dat | 0xb); tse_dprintf(5, "MARVELL : Enable RGMII Timing Control\n"); dat = IORD(&pmac->mdio1.reg14, 0); dat &= ~0x82; dat |= 0x82; IOWR(&pmac->mdio1.reg14, 0, dat); tse_dprintf(5, "MARVELL : PHY reset\n"); dat = IORD(&pmac->mdio1.CONTROL, 0); IOWR(&pmac->mdio1.CONTROL, 0, dat | PCS_CTL_sw_reset); return 1; }  there's something not clear to me, what is mdiox.reg14? I'm pretty sure it intended to be the "Extended PHY Specific Control Register" at address 20(decimal) but if you look at the chapter5 of the TSE UG in the section "PCS configuration register space" you find a different register located at 0x14(word offset) that's "if_Mode" register

[Altera_Forum]

This if_Mode register (word address 0x94) is there only if you enable the PCS. If not this address it will map to the register 0x14 of the PHY whose address is configured in mdio_addr0. 

The mdio1.reg14 (word address 0xb4) will always map to the register 0x14 of the PHY whose address is configured in mdio_addr1.  The TSE driver is probably using the mdio1 address space instead of mdio0 so that it can support the configurations with PCS enabled (as in this case the PCS registers are placed in the mdio0 space).

[Altera_Forum]

ok, now I undersand. So definitely I do the same things in my code.