88E1512 PHY can not reach Gigabit on FPGA - Page 1
Forum section: electronics / beginners

author: lk.dgironi
author_rank: Regular Contributor
timestamp: September 27, 2023, 07:59:45 am
content: Hi all,I'm working on a custom board that needs Gigabit Ethernet.It's based on the Tang Primer 20k board, so the GW2A-LV18PG256C8/I7 GoWin FPGA.As PHY I've try the Marvell 88e1512.I'm using the Alex Forencich verilog-ethernet core.Previously I was using ksz9031 but I have auto-negotiation problem on gigabit if the ethernet cable is disconnected after the PHY has been powered on (no luck asking herehttps://forum.microchip.com/s/topic/a5C3l000000BoLNEA0/t390661), so I've try moving to 88e1512.The problem is that with this last one I can't event reach the Gigabit.FPGA synthesis is the same, so it's not a code problem.Setting my PC PHY at 100Mpbs without auto-negotiation makes the board works, but the communication is not smooth, I found some packets loose.Note that I don't use MDIO and MDC, cause the FPGA talks in pure RGMII to the PHY, so I'm not able to se registers and check for internal PHY errors.My 88e1512 it's based on other FPGA boards (like the PicoZed).The problem behaviour:At 1Gbps or auto-negotiation enable on PC, I see "cable connected" at 1Gpbs but every packet send by the FPGA PHY is dropped (can't see packets on Wireshark), LED1 88e1512 is off, LED0 88e1512 if on.At 100Mbps Full Duplex with auto-negotiation disabled on PC, I see "cable connected" at 100Mpbs but most of the packet send by the FPGA PHY are not dropped, LED1 88e1512 is off, LED0 88e1512 if blinking.While the ksz9031, no packet dropped by the PC. At 1Gbps or auto-negotiation enable on PC it works at "first boot". When cable is disconnected LED1 and 2 goes off and does not negotiate untile next power off - the RST signal does nothing. At 100Mbps Full Duplex no more problem of negotiation even after the cable is disconnected.I'm lost now, don't understand why does not negotiate. I think is something about the magnetics but I don't know.

author: radiolistener
author_rank: Super Contributor
timestamp: September 27, 2023, 10:06:13 am
content: I'm used Alex Forencich core for ethernet, it works well and don't needs to read PHY register to detect current link speed, it can do it automatically by measuring clock. It automatically switch between 10/100/1000 and works very stable. If you have some issue with gigabit link, probably there is some issue with clock or phase. Another possible issue is non standard packet setting. I have the same issue when tried to reduce interframe gap or preamble between packets

author: lk.dgironi
author_rank: Regular Contributor
timestamp: September 27, 2023, 10:09:18 am
content: Thank you radiolistener.Indeed I don't think it's a firmware problem, I think it's something related to the board layout or schematic. As a matter of fact the KSZ9031 works well.The MDIO/MDC can be useful to get the PHY register and so to understand the errors if any happens, but I'm not using them too.

author: radiolistener
author_rank: Super Contributor
timestamp: September 27, 2023, 10:19:34 am
content: Quote from: lk.dgironi on September 27, 2023, 10:09:18 amit is possible that some data lines between FPGA and PHY have different electrical length and as result different phase delay. It may lead to error in data transfer. If you know phase error for each line you can provide that information for synthesis and it will add proper delay.Also you can play with clock phase, try to add some delay, may be it can help to latch correct data. Usually PHY chip has configuration for clock delay, it can be selected with proper signal combination during PHY reset. May be you're failed to setup proper clock phase configuration. It can work at 10/100M, but will fail at 1000M

author: lk.dgironi
author_rank: Regular Contributor
timestamp: September 27, 2023, 03:35:18 pm
content: Thank you,All below about the NEW board and the 88e1512.I've checked the track in my board, find below the track in milsLength on TP20k Length on Dock Signal name Total length Diff from the biggest388,12 1574 TX_EN 1962,12 835,23275,29 1574 TXC 1849,29 948,061223,35 1574 TXD3 2797,35 0473,58 1574 TXD2 2047,58 749,771069,26 1574 TXD1 2643,26 154,09319,08 1574 TXD0 1893,08 904,271329,60 2401 RX_DV 3730,6 83,281412,88 2401 RXC 3813,88 0833,36 2401 RXD3 3234,36 579,52639,87 2401 RXD2 3040,87 773,01735,89 2401 RXD1 3136,89 676,99560,73 2401 RXD0 2961,73 852,15Also I've found using the Analytic in my FPGA development environment that the the alex core trigger FCS error on each packet received (at 1Gpbs).Does that mils makes the difference? Or there's something I'm missing (like the magnetics ora anything else).Note that the "speed" signal in the alex core is correctly set to 1(100Mpbs) when my PC has 100Mpbs full duplex setted, when it's auto-negotiation speed is set to 2 (1000Mpbs). So the PHY does the negotiation in the proper way... I think

author: radiolistener
author_rank: Super Contributor
timestamp: September 28, 2023, 01:40:22 am
content: if it reports error on received packet, then there is an issue with data transfer from PHY to FPGA. Check PHY clock phase, try to shift it's phase for 90° (with PLL) or if your PHY allows phase config, try configure it to shift phase.Even a small difference in data/clock line length can cause issue at 125/250 MHz clock transfer, so you're needs to be careful. And check that you're using proper clock phase. Because PHY can do clock phase shift on their side, in such case if you're also do it on FPGA side, you will get incorrect clock. Check clock phase config on PHY.

author: lk.dgironi
author_rank: Regular Contributor
timestamp: September 28, 2023, 09:21:20 am
content: Thank you!Timing and phase was the issue. At least I think soRGMII TX => solvedI've been able to make the TX work using the clock for the ODDR (not the clock 90 phase shifted), I mean on Alex ip setting USE_CLK90 = "FALSE".RGMII RX => solvedAdding IODELAY primitive to the top module RX data lines (RGMII_rxd0, RGMII_rxd1, RGMII_rxd2, RGMII_rxd3 and RGMII_rx_ctl) solve the problemwire [3:0] RGMII_rxd_delay;wire RGMII_rx_ctl_delay;IODELAY iodelay_RGMII_rxd0_inst ( .DI(RGMII_rxd), .DO(RGMII_rxd_delay), .DF(), .SDTAP(1'b0), .SETN(1'b0), .VALUE(0) );IODELAY iodelay_RGMII_rxd1_inst ( .DI(RGMII_rxd), .DO(RGMII_rxd_delay), .DF(), .SDTAP(1'b0), .SETN(1'b0), .VALUE(0) );IODELAY iodelay_RGMII_rxd2_inst ( .DI(RGMII_rxd), .DO(RGMII_rxd_delay), .DF(), .SDTAP(1'b0), .SETN(1'b0), .VALUE(0) );IODELAY iodelay_RGMII_rxd3_inst ( .DI(RGMII_rxd), .DO(RGMII_rxd_delay), .DF(), .SDTAP(1'b0), .SETN(1'b0), .VALUE(0) );IODELAY iodelay_RGMII_rx_ctl_inst( .DI(RGMII_rx_ctl), .DO(RGMII_rx_ctl_delay), .DF(), .SDTAP(1'b0), .SETN(1'b0), .VALUE(0) );One thing left.Do you think it's better (for my next board) to math the line with within RX and TX. Different match but all the RGMII TX and all the RGMII matched in length. I mean as example RGMII_rxc, RGMII_rxd0, RGMII_rxd1, RGMII_rxd2, RGMII_rxd3 and RGMII_rx_ctl matched to 3000mils and RGMII_txc, RGMII_txd0, RGMII_txd1, RGMII_txd2, RGMII_txd3 and RGMII_tx_ctl matched to 2500 mils (number as example).

author: radiolistener
author_rank: Super Contributor
timestamp: September 28, 2023, 10:36:00 am
content: Quote from: lk.dgironi on September 28, 2023, 09:21:20 amyes, the same electrical length helps to keep stable data transfer at high clock rate and make gateware development more easy.

author: lk.dgironi
author_rank: Regular Contributor
timestamp: September 28, 2023, 10:39:14 am
content: Thank you!You save me weeks

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: September 28, 2023, 01:13:12 pm
content: thanks for sharing!