Arria 10 cannot access Transceiver ATX PLL reconfiguration interface
Hello,
I am currently try to recalibrate the Transceiver ATX PLL on an Arria 10 FPGA (10AX027E4F29E3SG) because the reference clock is not available at FPGA configuration. I use the NIOS V and connect in Qsys the reconfiguration interface with the data manager of the Nios. The NIOS clock which I also use as reconfiguration clock is 100 MHz. The system is not stuck in reset.
Qsys ATX PLL reconv
ATX PLL reconv settings
After the external clock chip has been successfully configured by the NIOS and the clock is available at the reference clock input of the transceiver, I try to access the reconfiguration interface.
Unfortunately there is nothing but 0x000000FF in the memory area of the NIOS where the reconfiguration interface should be.
ATX PLL reconv address in nios
The first step of the reconfiguration flow is to write 0x2 to 0x0:
Page 592 Intel® Arria® 10 Transceiver PHY User Guide: Request access to the internal configuration bus by writing 0x2 to offset address 0x0[7:0].
But it does not work. Can someone explain to me where I took a wrong turn? Or is there anything here that I am doing grossly wrong?
Some more informations:
Page 586 Intel® Arria® 10 Transceiver PHY User Guide: This register is available to check who controls the bus, no matter if, separate reconfig_waitrequest from the status of Avalon memory-mapped interface arbitration with PreSICE is enabled or not.
0x280[2] PreSICE Avalon memory-mapped interface control.
0x1: PreSICE is controlling the internal configuration bus.
0x0: The user has control of the internal configuration bus.
0x280[1] ATX PLL pll_cal_busy
0x1: ATX PLL calibration is running
0x0: ATX PLL calibration done
After i write 0x2 to offset address 0x0[7:0] the 0x280[2] stays at PreSICE (0x1) and i dont get the control of the bus.
Regards, LFrin
Hi,
i found the problem. It is hardware related:
I found it strange that the integrated processor, which takes care of the initial callibration, did not react. If I understand correctly, it is clocked by the 100 MHz user clock (clkusr). I checked the 100 MHz oscillator and well... it does not work. Since we don't use this oscillator for anything else, we didn't notice it earlier.
Thanks for the help, my problem is solved.
Regards, LFrin