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/Pro...IExampleDesign
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 (and they are).
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...