I am using the Remote Update IP with the Cyclone 10 GX FPGA, part number 10CX150YF672E5G. I observed that the Remote Update IP does not respond properly after reset until approximately 300 µs. I experimented with delays of 1 µs and 2 µs after reset, but did not observe the expected behavior. However, after waiting for 300 µs, the IP responded as expected. Previously, I used the same Remote Update IP with a different part number, 10CX150YF672I5G, and in that case, it worked as expected with just a 10 clock cycle delay after reset. Could you please confirm if there is a specific timing requirement after reset for initializing the Remote Update IP with the 10CX150YF672E5G device? I am using Quartus Prime Pro 24.2 tool for Both version of Cyclone 10GX FPGA(10CX150YF672E5G & 10CX105YF672I5G) 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

For your information: The reset of the remote update IP is controlled by the lock signal from the PLL IP and is initiated after FPGA initialization.

In my design, I am giving reset for Remote Update IP based on lock signal from the PLL IP. Later trying to read the current configuration boot address.

Hi Sumanth, Thank you for sharing the details.Using the PLL lock signal for the Remote Update IP reset is a good approach, but please note that PLL lock does not guarantee the IP is ready. The FPGA may still be completing its initialization sequence, and the Remote Update IP needs additional time for its internal state machine to become ready.Recommendation:After releasing reset, poll the IP’s busy signal before reading the boot address. This ensures the IP is ready.Alternatively, use INIT_DONE or wait up to 830 µs after CONF_DONE for safe operation (per device datasheet). Regards,Fakhrul

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

11 Replies

Sumanth
New Contributor
8 days ago
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.
- FakhrulA_altera
  Regular Contributor
  5 days ago
  Hi Sumanth,
  
  Thank you for sharing these observations. To help us narrow down the root cause, could you please clarify a few details:
  
  Quartus Settings
  
  - Are both designs using the same Remote Update IP version and Quartus Prime Pro settings?
  
  - Is the “Auto-restart configuration after error” option enabled in both cases?
  
  Flash Content and Address
  
  - When triggering reconfiguration from an unprogrammed location, is the start address set to 0x00 or another value?
  
  - Is the factory image correctly placed at 0x20 (as recommended in the user guide)?
  
  Error Handling Signals
  
  - On the device that stalls (10CX105YF672I5G), do you see nSTATUS or any error indication toggling before the stall?
  
  - Does the watchdog timer feature play any role in your design?
  
  Clock and Reset
  
  - Is the Remote Update IP clock stable during reset and reconfiguration?
  
  - Are you using the same reset sequence for both devices?
  
  These details will help us confirm whether this is a device-level difference or a configuration setting issue.
  
  Regards,
  Fakhrul
  - Sumanth
    New Contributor
    4 days ago
    Thank you for the questions. Below are my answers:
    
    - Are both designs using the same Remote Update IP version and Quartus Prime Pro settings?
    Yes. Remote update Ip version 19.1.0
    
    - Is the “Auto-restart configuration after error” option enabled in both cases?
    Yes.
    
    - When triggering reconfiguration from an unprogrammed location, is the start address set to 0x00 or another value?
    In the project I am working on, we are using the MT25QU512 flash. The application image address is set to 0x00C00000, and the base image address is set to 0x00010000 to align with the sector boundary. This configuration is the same on both boards, and it works fine.
    
    - Is the factory image correctly placed at 0x20 (as recommended in the user guide)?
    No. I have set it to 0x00010000 to align with the sector boundary.(MT25QU512 flash). We use a different mechanism for Image updates
    
    - On the device that stalls (10CX105YF672I5G), do you see nSTATUS or any error indication toggling before the stall?
    After reconfiguration, we observed that the conf_done signal was not yet asserted.
    
    - Does the watchdog timer feature play any role in your design?
    Yes, We have a logic to reset watchdog timer before it gets timeout.
    
    Clock and Reset
    - Is the Remote Update IP clock stable during reset and reconfiguration?
    Yes
    
    - Are you using the same reset sequence for both devices?
    Yes. To work properly on 10CX150YF672E5G FPGA we have currently modified reset sequence to wait for 300us.
Sumanth
New Contributor
18 days ago
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.
FakhrulA_altera
Regular Contributor
26 days ago
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
- Sumanth
  New Contributor
  26 days ago
  For your information: The reset of the remote update IP is controlled by the lock signal from the PLL IP and is initiated after FPGA initialization.
  - Sumanth
    New Contributor
    26 days ago
    In my design, I am giving reset for Remote Update IP based on lock signal from the PLL IP. Later trying to read the current configuration boot address.
Farabi
Regular Contributor
2 months ago
FakhrulA_altera

Forum Discussion

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

11 Replies

Recent Discussions

intel_onchip_Memory II RAM: r/w doesn t work from FPGA but from HPS

Power Rating Required for RZQ Resistor on Cyclone V SE

MAX 10. No 3.0 V Schmitt Trigger I/O standard

Arria 10: Remote Update may brick FPGA and Factory Fallback won't work

Unable to program EPCQ16A on custom cyclone IV board - error during jic flashing.