Timing Behavior of Remote Update IP After Reset on Cyclone 10 GX (10CX150YF672E5G)
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.
Hello, Based on your suggestion and the Intel documentation recommendation (Section 7.3.3.6, User Mode, of the Intel® Cyclone® 10 GX Core Fabric and General Purpose I/Os Handbook (C10GX51003, ID: 683775)), Implemented the reset synchronization as described.
The user logic reset release has been modified based on pll_locked(clock_ip) and the init_done signal of the twentynm_controller primitive. The reset of the user logic is now held until both pll_lock and init_done are asserted, with an additional delay of three clock cycles.
The PLL input clock is 40 MHz and the Remote Update IP clock is 10 MHz. All user logic operates in the 10 MHz clock domain.
Signal Tap data was captured during power-up by setting the trigger to the reset signal. From the capture, it is clear that init_done goes high prior to the pll_lock signal. This confirms that the logic is not attempting to read the remote update register during initialization.
To recall the issue: after reset or initialization, the remote update register provides correct values only after approximately 300 µs. If the register is accessed earlier, all bits are read as 1’s.
In the Signal Tap capture below, the logic first attempts to read the current configuration boot address from the remote update register. If the busy signal is not asserted following that command, it then attempts to read the reconfiguration trigger condition from the remote update register.
Signal Tap During Power Up trigger.
Even after using init_done for reset release, I am observing the same behavior as previously indicated. The values read from the Remote Update IP after reset (for approximately 300 µs) are always all 1’s. After 300 µs, the read values become valid.
Experimentation conducted: With the updated reset-release logic (combining the twentynm_controller primitive and the pll_locked_s signal), I held the reset for an additional 1 µs, 100 µs, and 200 µs after both init_done and pll_locked_s were asserted high. In all these cases, the Remote Update IP register read returned all 1’s.
When the reset was held for 300 µs after both signals were high, the system worked as expected and the register reads were valid.
Request to Altera Support Team:
This issue has been ongoing for nearly four months. Kindly review the observations and experimental results provided above and assist in identifying the root cause. Your support in resolving this issue at the earliest would be greatly appreciated.
In our design, the watchdog timer is enabled only while loading the application image. We use a remote IP clock with a 10 MHz frequency. The watchdog timeout value is set to 0x138, which corresponds to approximately 2 seconds.
When the current configuration is the application image, the watchdog timer (reset_timer) is reset every 3.2 milliseconds.
Note: The issue I observed occurs before the application image is triggered, specifically while reading the reconfiguration trigger conditions.
On Cyclone 10GX, the device does not immediately enter user mode after configuration. In datasheet: tCD2UM is around 175us to 830us.
The root cause of your failure migt be caused by you are reading the Remote Update Registers before the device has entered User mode. Recommendation - you must not interact with user logic until INIT_DONE goes high.
The all 1's you are observing is expected when reading any uninitialized Avalon-MM register space.
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.
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 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.
As we haven't received a response to our previous notification, this thread will be transitioned to community support. We hope all your concerns have been addressed. If you have any new questions, please feel free to open a new thread to receive support from Intel experts. Otherwise, community users will continue to assist you here. Thank you.
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 confirming. Since the example works on both devices, the IP is consistent. The difference I'm assuming seems related to timing in your design. Could you please try adding a short delay after reset or between operations and see if it helps.
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.
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.
New Contributor
