- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'd agree that checking your timing would be the best place to start. Can you verify the clock/data relationship with a scope?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page