We have an Arria 10 FPGA with ARM processor. In Platform Designer one of the EMACs is routed to the FPGA logic. We do not route the GMII Tx data and GTX clock directly from FPGA logic to a PHY, but we want to merge this data stream with other data and send it to a 10G optical link.
If we run the FPGA logic at the GTX clock output of the HPS system, we see each data byte of the GMII interface is sent twice. When measuring the GTX clock we see a frequency of 250 MHz. While we expect 125 MHz for a fixed 1 Gbps interface.
Can someone explain me why the GTX clock output is running at a frequency which is twice the expected frequency?
May I know which Quartus/SOC EDS version you are working on?
Also, did you have any error when compiling in Platform Designer/Qsys or in Quartus?
I am using Quartus Pro 18.0.0. I can successful build an FPGA binary without having errors. We use buildroot to build all software stuff.
I am still working to figure out this issue.
Firstly, can you double check that your design is connected correctly. Also, I could not find any information regarding data sent twice, which IP are you currently using and what is the clock frequency that you have set?
If the GTX clock output would be 125 MHz instead of the measured 250 MHz, the data would be sent once. It looks like it is sent twice because of the doubled clock frequency. I measured the gtx clock frequency by incrementing a counter in my toplevel which runs at the GTX clock. The counter runs until 125000000 is reached, toggles an IO and starts counting again from zero. The IO signal is viewed with an oscilloscope which shows me a pulse train with a high time equal to the low time of 0.5 seconds. In other words, the counter must run at 250 MHz to count to 125000000 in 0.5 seconds.
I don't see wrong connections in the Platform Designer, I just export the GTX clock to FPGA user logic together with the GMII data and control signals (txd/rxd and txen/rxen).
Do I have to change to device tree when changing clock frequencies in Platform Designer?
I apologize for getting very late to you.
The answer is yes you need a to recompile the .dtb file, preloader image, etc. if there changes in the HPS and anything connected to it. This is so because the settings binaries need to be handoff correctly to take effect.
Have you tried recompiling everything to make sure the changes is taking place?
I tried a recompile of all software stuff without success. How can I check if changes in clock frequencies in HPS are reflected in my software environment? Which file(s) are changed as result of a clock frequency change in HPS?
You can check the pll_config.h file which has the clocking configurations, refer here for more info:
I expected to find a pll_config.h file for the Arria 10, but what I can find in my buildroot software directories is:
Are you sure this is also working for Arria 10 devices? And how is the link made between Quartus and the pll_config.h file?
After the compilation for Arria 10 SoC in quartus, there is a folder called hps_isw_handoff, you can open the hps.xml using text editor and check the hps clk user0 and user 1 value, which is 400000000 in the default GHRD.
When I change the EMAC1 emac1_gtx_clk clock frequency into 125 MHz (tab "HPS Clocks and reset, Input Clocks") this frequency is not found in the hps.xml. This hps.xml file mentions the emac1_clk_hz frequency of 250 MHz which is (I assume) the value of the EMAC 1 clock frequency (tab "HPS Clocks and reset, Internal Clocks and Output Clocks").
A change in the EMAC 1 clock frequency (tab "HPS Clocks and reset, Internal Clocks and Output Clocks") is reflected in the hps.xml file. However, the tooling will give a warning: Warning: system_sd.arria10_hps_0: EMAC1 is in GMII/RGMII mode but has a 50MHz clock. 250MHz Clock is recommended. The result remains the same: gtx clock has a frequency of 250 MHz.
I apologize for the long response time due the current situation, thus I have overlooked this case. The only close fix that I could find regarding your issue, there seems to be an issue in the previous version of Quartus when changing the clock of the EMAC, and there are changes/patch made in the latest 18.1 on-ward, thus we recommend that you try to use the latest version of Quartus preferably 19.1, to see if this fixes your issue.
If further support is required, please post a response in the next few days to allow me to continue to support you. This thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.