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

Cyclone IV GX Dev Kit - Getting Ethernet to Work

I've been trying to get the Ethernet connection to work on the Cyclone IV GX Dev Kit to work in my design and have slowly been making progress. 

 

Getting your own design working is difficult due to missing or incorrect information in the documentation so I thought I would put my finding here in the hope it will help somebody else. 

 

The ethernet PHY chip on the board is a Marvell 88E1111. The data sheet for this chip is under NDA and I have yet to get anybody to send me an NDA form let alone actually get them to send me a data sheet. However, if you search on Google including the word confidential then you might just be able to find something... 

 

config 0: LED_RX = 010 = PHY_Address[2:0] 

config 1: LED_LINK10 = 110 = {ENA_Pause, PHY_Address[4:3]} 

config 2: 2.5V = 111 = ANeg[3:1] 

config 3: LED_TX = 001 = {ANeg[0], ENA_XC, DIS_125} 

config 4: GND = 000 = {HWCFG_Mode[2:0]} 

config 5: LED_LINK10 = 110 = {DIS_FC, DIS_Sleep, HWCFG_Mode[3]} 

config 6: GND = 000 = {SEL_TWSI, INT_POL, 75/50 Ohm} 

 

Phy Address = 10010 

 

ENA_Pause = 1 = ?? 

 

ANeg = 1110 = Auto-Neg, advertise all capabilities, prefer Master 

 

ENA_XC = 0 = Crossover disabled 

 

DIS_125 = 1 = 125MHz clock disabled 

 

HWCGG_Mode = 0000 = SGMII with clock with SGMII Auto Neg to copper 

 

DIS_FC = 1 = Disable Fibre / Copper auto selection 

 

DIS_SLEEP = 1 = Disable energy detect 

 

SEL_TWSI = 0 = Select MDC/MDIO interface 

 

INT_POL = 0 = INTn signal is active high 

 

75/50 Ohm = 0 = 50 ohm termination for fibre. 

 

 

From the above, the important thing to note is that the interface is set up to SGMII rather than the RGMII mode (default) as mentioned on the circuit diagram. This is a screwup as the board is wired up as an RGMII interface. Fortunately, it is possible to switch the chip from SGMII to RGMII by sending commands over the MDC/MDIO interface. What you need to do is given here: http://www.altera.co.uk/support/kdb/solutions/rd12262011_851.html 

Unfortunately, how to do this isn't.... 

 

This is the code I've used: 

 

alt_u32 dat; printf("Hello from Nios II!\n"); // wait for PHY to reset for (i = 0; i < 100000; i++); printf("Wait over\n"); // Set PHY address for MDIO IOWR(ETH_TSE_BASE, 0x0F, 0x00000012); // Change mode to RGMII dat = (IORD(ETH_TSE_BASE, 0x80 + 27) & 0xFFF0) | 0x0000000B; IOWR(ETH_TSE_BASE, 0x80 + 27, dat); dat = IORD(ETH_TSE_BASE, 0x80 + 20) | 0x00000082; IOWR(ETH_TSE_BASE, 0x80 + 20, dat); // Reset PHY dat = IORD(ETH_TSE_BASE, 0x80 + 0) | 0x00008000; IOWR(ETH_TSE_BASE, 0x80 + 0, dat); 

 

 

At the moment, I'm just trying to get the receive logic to work so I've just enabled the receiver in the Triple Speed Ethernet (TSE) module. 

 

// Enable receive logic dat = 0x0000023B; IOWR(ETH_TSE_BASE, 0x02, dat);  

 

This gets me to the point where received packets are being decoded and dumped onto the Avalon Streaming Source output from the receive module. Unfortunately there is data corruption occurring and a few of the bits in a packet are wrong. This is where I'm currently at. However this document: http://www.altera.co.uk/literature/an/an477.pdf Page 8 suggests it could be a clock skew issue. 

 

 

 

More on problems with the dev kit here: http://www.alteraforum.com/forum/showthread.php?t=44035
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
125 Views

I would guess a timing problem if you can get it to receive a packet for looks OK for the most part, but has some bit errors. Maybe make some adjustments to your sdc, or can you shift the clock around with an rx pll?

Altera_Forum
Honored Contributor I
125 Views

The example designs don't play around with the clock so I'm trying to avoid that if possible. I'm guessing it is a timing constraint or similar that I'm missing. 

 

I have confirmed that the clock shift mentioned in AN477 is being applied. (Setting bits 1 and 7 in reg 20 does this). If I remove this setting then I don't get any valid data at all.
Altera_Forum
Honored Contributor I
125 Views

I'd agree that checking your timing would be the best place to start. Can you verify the clock/data relationship with a scope?

Altera_Forum
Honored Contributor I
125 Views

Possibly... The dev kit is a multilayer board with PHY having hidden pins and the FPGA being a bga. This makes getting a scope onto the signals difficult. There is an array of vias under the FPGA so I might be able to probe there. Something to try tomorrow.

Altera_Forum
Honored Contributor I
125 Views

Adding the following to the .sdc file seems to have sorted out my receive errors. Still some checking to be done but it does look very much improved. 

 

# Clock constraints create_clock -name "clkin_50" -period 20.000ns create_clock -name {enet_rx_clk} -period 8.000 -waveform { 0.000 4.000 } create_clock -name "enet_gtx_clk" -period 8.000ns # Automatically constrain PLL and other generated clocks derive_pll_clocks -create_base_clocks set_clock_uncertainty -rise_from -rise_to 0.020 set_clock_uncertainty -rise_from -fall_to 0.020 set_clock_uncertainty -fall_from -rise_to 0.020 set_clock_uncertainty -fall_from -fall_to 0.020 set_input_delay -add_delay -max -clock 2.500 }] set_input_delay -add_delay -min -clock 1.500 }] set_input_delay -add_delay -max -clock_fall -clock 2.500 }] set_input_delay -add_delay -min -clock_fall -clock 1.500 }] set_input_delay -add_delay -max -clock 2.500 }] set_input_delay -add_delay -min -clock 1.500 }] set_input_delay -add_delay -max -clock_fall -clock 2.500 }] set_input_delay -add_delay -min -clock_fall -clock 1.500 }] set_input_delay -add_delay -max -clock 2.500 }] set_input_delay -add_delay -min -clock 1.500 }] set_input_delay -add_delay -max -clock_fall -clock 2.500 }] set_input_delay -add_delay -min -clock_fall -clock 1.500 }] set_input_delay -add_delay -max -clock 2.500 }] set_input_delay -add_delay -min -clock 1.500 }] set_input_delay -add_delay -max -clock_fall -clock 2.500 }] set_input_delay -add_delay -min -clock_fall -clock 1.500 }] set_input_delay -add_delay -max -clock 2.500 set_input_delay -add_delay -min -clock 1.500 set_input_delay -add_delay -max -clock_fall -clock 2.500 set_input_delay -add_delay -min -clock_fall -clock 1.500 set_clock_groups -exclusive -group  

 

All I have to do now is process the received data and sort out data transmission. That could be fun.... 

 

I feel like I am getting somewhere though.
Reply