Cyclone 10 GX Remote Update IP triggers reconfiguration randomly for reset signal

[Sumanth]

I have generated a remote update IP for Cyclone 10 GX with Flash combination MT25QU01G with Quartus Prime Pro 20.4 tool. 
If reset signal is sent to remote update IP, I am observing some strange behavior. It reconfigures some times. If I give reset signal 5 times, One time it reconfigures. 

As per document ug_altremote-683695-666531. It says that Asynchronous reset input to the IP core to initialize the machine to a valid state. 

Why it randomly reconfigures.

[Fakhrul]

Hi Sumanth,

Here are the key points to focus on for addressing the intermittent reconfiguration issue:

State Machine and Control Logic:

• Ensure the reset signal (RU_CONFIG) is properly de-asserted.
• Verify that the state machine transitions correctly to initiate reconfiguration.

Timing and Signal Integrity:

• Confirm that the reset signal timing meets the required specifications to avoid glitches or noise.
• Use an oscilloscope to check that the reset signal is clean and meets timing requirements.

By focusing on these aspects, you can address the root cause of the intermittent reconfiguration issue effectively. Refer to Intel® Cyclone® 10 GX user guide for more details.

Regards,

Fakhrul

[Sumanth]

Hi Fakhrul, 

Conducted some experiments with reset signal pulse width. Though the document say it is asynchronous reset signal. Earlier I had provided reset signal pulse width of 16.67 ns. ( During that time i observed random reconfiguration). I increased the reset signal pulse width to more than 100 ns. Later observed, it reconfigures for every reset signal. I have used 10MHz clock for Remote update IP. 

Is there any minimum requirement of reset signal pulse width? 
or

Any dependency between Remote update IP clock and reset signal? 

[Fakhrul]

Hi Sumanth,

Sorry for the delay. To address your query:

1. Purpose of Reconfiguration: If your aim is to trigger reconfiguration, it is best to initiate it by pulling the nCONFIG pin low to at least the minimum tCFG low-pulse width. This method is more reliable and avoids the dependency on the reset signal within the IP core, which primarily resets the IP core itself rather than triggering a full reconfiguration.
2. Reset Signal Pulse Width: While the reset signal within the Remote Update IP is asynchronous, your observation that increasing the pulse width to more than 100 ns results in consistent reconfiguration suggests that the shorter pulse width might not have been reliably detected. Ensuring a longer pulse width (as you have done) seems to provide the necessary stability.
3. Clock Dependency: The 10 MHz clock for the Remote Update IP should generally be sufficient. However, any asynchronous reset signal must be synchronized with the clock to avoid metastability issues. This synchronization might explain why a longer reset pulse width results in more reliable operation.

For your specific application, I recommend continuing with the longer reset signal pulse width if you choose to use the IP core's reset signal. However, for more robust reconfiguration, using the nCONFIG pin as suggested is the best practice.

Please let me know if you need any further assistance.

Best regards,

Fakhrul

[FvM]

Hi,
reset input isn't the intended input to trigger a reconfiguration, it's reconfig input. All remote update IP ports need to meet timing constraints, as any FPGA IP. Reset e.g. is an asynchronous input that need to be released synchronous to clk, otherwise arbitrary erratic behaviour may be observed. Nothing specific to remote update.

If you e.g. consider to trigger reconfig with a push button, the signal should be debounced and synchronized to clk.

[Sumanth]

Thanks for the detailed information.

[Fakhrul]

I’m glad that your question has been addressed, I now transition this thread to community support. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.