litex-hub / litex-boards

LiteX boards files
BSD 2-Clause "Simplified" License
372 stars 283 forks source link

efinix_trion_t120_bga576_dev_kit ethernet not working #394

Open sammhho opened 2 years ago

sammhho commented 2 years ago

Hi @enjoy-digital, may I ask what's the current support status of ethernet on the Trion t120f576 dev kit? Is it supposed to be working, or what needs to be done to make it work?

Since there seems to be out-of-the-box support of ethernet here https://github.com/litex-hub/litex-boards/blob/48353735fa9471b4645cfb06557fcbdf7b4e3aaa/litex_boards/targets/efinix_trion_t120_bga576_dev_kit.py#L347

I tried to build the SoC and got a synthesis error about multiple drives on the eth_tx_rst reset signal. I looked into the code and found that reset is built here https://github.com/enjoy-digital/liteeth/blob/b0e72431234cbbf42a0f74f1a5f2bff145dfc043/liteeth/phy/trionrgmii.py#L177 from the CSR reset: self._reset = CSRStorage()

But yet the pll.create_clkout call here https://github.com/enjoy-digital/liteeth/blob/b0e72431234cbbf42a0f74f1a5f2bff145dfc043/liteeth/phy/trionrgmii.py#L161 when called with the default with_reset=True, builds a reset for the domain self.cd_eth_tx from inverting the PLL locked https://github.com/enjoy-digital/litex/blob/c401bdd7f18f769cd59ddf77320dd8c17e50178c/litex/soc/cores/clock/efinix.py#L105

So by doing pll.create_clkout with with_reset=False on line 161 I got the SoC built successfully, and ran the linux-on-litex-vexriscv on it fine. But then it won't fetch boot.json from tftp, so I booted thru serial, and within the Linux I can actually see the eth0 device and successfully set ip/netmask etc., and yet ping-ing other IPs give no response.

BTW thx for supporting Efinix! At Efinix we are also readying a RGMII ethernet adapter (via QSE sockets) for current Ti60 and upcoming Ti180 products, I guess I can help porting it to LiteX-boards if the trionrgmii code actually works.

enjoy-digital commented 2 years ago

Hi @sammhho,

properly validating RGMII on the this dev kit indeed still needs to be done. The last status was that the design was compiling fine and at least one direction was working (don't remember if this was RX or TX) and the other was not (or with errors). The issue is probably related to clk/data alignment and timings that needs to be adjusted. I could have a closer look. @fjullien also got it working, but IIRC it was requiring a hardware change. @fjullien: do you remember? Since @sammhho is from Efinix, maybe we could discuss it here directly.

Otherwise nice for the RGMII over QSE for Titanium, I'm currently working on a Titanium project with a Linux SoC on the FPGA and was looking to add Ethernet to the TI60 F225 dev kit only 2 days ago... (Only with RMII but abandoned since this would require specific hardware with the 1.8V IOs). So I would be really interested by the QSE/RGMII adapter and to collaborate in this.

fjullien commented 2 years ago

Hi,

The problem was (if I remember correctly) that the tx_ctl pin (E24) does not support DDIO. So with the current implementation, tx_ctl is not properly aligned with the clock. I had to move the signal to another location (M21) and put tx_ctl on a DDIO like others TX data.

With this modification, the RGMII worked correctly.

enjoy-digital commented 2 years ago

Thanks @fjullien.

@sammhho: Do you know how RGMII was tested on the T120 dev kit? And how you've been generating similar timings on tx_ctland tx_data without DDIO support in the tx_ctl pin? Is it a wrong understanding on our side or a pinout issue on the hardware?

sammhho commented 2 years ago

@enjoy-digital That's definitely an error in PCB design using a non-DDIO pin of the FPGA. I've heard that my colleague is revising that PCB but he's still sourcing parts, design not revised yet. The guy who have tested the T120 RGMII said he had to force it to run at 100M mode, at 25MHz clock, so that DDIO is not needed.

enjoy-digital commented 2 years ago

Thanks @sammhho for the feedback. So things make sense now. We should also probably try to force it to 100M mode then through MDIO. I'll try to do a test very soon. On board that are correctly wired, current solution should work. Supporting Titanium should only be a matter of adapting https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/trionrgmii.py to Titanium primitives. Happy to do it/test it if you can provide QSE <-> RGMII extension boards.

sammhho commented 2 years ago

@enjoy-digital Thanks a lot for your support, I emailed you (the address in enjoy-digital GitHub profile) separately on the QSE card stuffs.

AndrewD commented 1 year ago

@enjoy-digital has this been closed by the recent trion LiteEth work?