HPS EMAC DMA engine always in reset...

Hello everyone !

In my current baremetal project, I use a Cyclone V 5CSXFC6C6 and I want to use the HPS emac in RGMII.

On the board I developped, i had to use the FPGA I/O to route the GMII signals of the HPS.

My QSYS project is based on this project (for the emac management) : https://rocketboards.org/foswiki/projects/cyclonevrgmiiexampledesign

So I use QSYS "Emac interface splitter" & "gmii to rgmii adapter" module to make the GMII to RGMII conversion.

The PHY i use is the Mikrel KSZ9021RL.

To initialize HPS Emac & PHY, I use the method described in Cyclone V Hard Processor System Technical Reference Manual (cv_5v4.pdf), Ethernet Media Access Controller / Ethernet MAC Programming model.

The "EMAC FPGA interface initialization" seems to works fine in my HPS software :

• I reset the PHY

• I reset the HPS EMAC0

• I configure the EMAC0_clk to 250MHz

• I bring the PHY out of reset and I check if rx_clk is present (it is the case)

• The Qsys "gmii-2-rgmii" adaptor that I developped is running, so I assume that the corresponding clocks are correctly propagating.

• I set the EMAC0 to GMII mode

• I start the Ethernet Controller FPGA interface

• I bring the EMAC out of reset

Then, on my hardware, I have checked that both rx_clk (from PHY) and tx_clk (from EMAC) are present and are 125MHz.

According to cv_5v4.pdf, I now have to reset the EMAC0 DMA module and continue the init but my problem appears here:

For the DMA initialization, I have to reset the EMAC DMA module (Bus Mode Register, bit 0) and wait for the reset completion by pooling the same bit.

--> The issue is that the module never goes back from reset...

According to the documentation :

"The reset operation is completed only when all resets in all active clock domains are de-asserted. Therefore, it is essential that all the PHY inputs clocks (applicable for

the selected PHY interface) are present for the software reset completion."

I'm quite sure that my PHY rx_clk is present at the emac0_rx_clk_in and that emac0_clk is successfuly set to 250MHz.

Does someone have any idea of what happens here ? I think about it for some days, and I must admit that I have no more ideas...

Thank you !

PS : on a previous board, I used the same HPS code to manage the EMAC and it worked great ! The only difference is that the PHY was connected to the HPS EMAC pins and not like here to FPGA pins...