Cyclone IV GX Dev Kit - Getting Ethernet to Work

[Altera_Forum]

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

[Altera_Forum]

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]

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]

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]

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]

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.