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

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.

Regards,
Sumanth S