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.
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.
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.
New Contributor
