Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
962 Views

TSE MAC Software Reset doesn't complete

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.
0 Kudos
20 Replies
Altera_Forum
Honored Contributor I
118 Views

Are the rx and tx clock signals correctly driven? 

Is the hw reset pin deasserted?
Altera_Forum
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

Might be a data cache isssue??

Altera_Forum
Honored Contributor I
118 Views

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

Altera_Forum
Honored Contributor I
118 Views

 

--- 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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

 

--- 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
Honored Contributor I
118 Views

 

--- 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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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

Altera_Forum
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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

Altera_Forum
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
118 Views

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
Honored Contributor I
26 Views

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

Reply