Timing Behavior of Remote Update IP After Reset on Cyclone 10 GX (10CX150YF672E5G)

If you need any further clarification, please feel free to contact me at sumanth_s@procsys.com or call me at +91 9742079856.

After successful configuration, I am reading the current configuration boot address. If it corresponds to the base image address, I then read the reconfiguration trigger conditions. These are expected to be all zeros after power-up.

In my project, based on the reconfiguration trigger conditions, I pass commands to load the application image.

The observed faulty behavior is that the current configuration boot address and the reconfiguration trigger conditions are not as expected, all bits are read as 1. I suspect that internal control register updates may be taking additional time, which could be causing this issue.

Please find the below signal tap waveform

The PLL locked signal is used as a reset for the Remote Update IP after inversion, and the reset is extended and synchronized for five additional cycles of the Remote Update clock. Later, a state machine checks that the busy signal is not asserted. Once busy is deasserted, it attempts to read the current configuration boot address and then the reconfiguration trigger condition. For all read operations, a response of all 1’s was observed. 

I was on leave for the past couple of weeks. The board is currently not free; please give me 2 days, and I will provide the SignalTap waveform.

I observed that the Remote Update IP does not respond properly after reset until approximately 300 µs. I experimented with delays of 1 µs, 2 µs, 3 µs, 4 µs, 5 µs, 10 µs, 100 µs, 150 µs and 200 µs after reset, but did not observe the expected behavior. However, after waiting for 300 µs, the IP responded as expected. This behavior is observed on 10CX150YF672E5G FGPA.

However, on 10CX105YF672I5G FGPA after reset, here we wait for the busy signal to deassert before performing any further read or write operations. The same logic was used in the 10CX150YF672E5G FGPA as well. 

In the official Remote Update IP design example, the reset command waits for 0.6 seconds and then performs the read or write operations. Between each read or write operation, it waits for 0.6 seconds before proceeding with further read or write operations.

Note: The official Remote Update IP functions correctly on both boards (10CX150YF672E5G and 10CX105YF672I5G).

In my design, I wait for the busy signal to deassert before performing any further read or write operations.

Thanks for the information. 

In the remote update IP cyclone10Gx example design they have waited for 0.6 seconds after reset and between each write operation. 
In my project I have taken care to check busy signal before the read and write commands. 

I suspect there is change in remote update IP functionality between 10CX150YF672E5G & 10CX105YF672I5G. 

For your information, If you try to trigger a reconfiguration from unprogrammed memory location of flash, it doesn't complete configuration or roll back to base image, FPGA stalls, Only way to comeout of this is programming through JTAG in 10CX105YF672I5G FPGA. 
But if you try to trigger a reconfiguration from unprogrammed memory location of flash, it roll back to base image with boot status CRC error in 10CX150YF672E5G FPGA. 

Could you please check with concern team and get back to me.

Thanks for the suggestions. 

Related to the recommendation:
In my code it is already taken care to check IP's busy signal before doing any read operation. 

During the reset, whether remote update IP will assert busy signal until initialization is complete?

Is there any other mechanism to know that remote update IP is ready?

Thank you.

Hi Sumanth,

Thank you for your question. On the Cyclone 10 GX 10CX150YF672E5G, the Remote Update IP may not respond immediately after reset because the FPGA takes up to 830 µs to complete initialization and enter user mode (as specified in the datasheet). Accessing the IP before this time can cause issues.

Recommendation:
Wait at least 830 µs after reset, or use the INIT_DONE signal to confirm the device is ready, before interacting with the Remote Update IP. This timing can differ between device variants, so always follow the longer delay for compatibility.

Let us know if you have any further questions.

Regards,
Fakhrul

FakhrulA_altera​