New Contributor
New ContributorAs per the suggestion, I installed Quartus Prime Pro 25.1-129 and created a simple project to verify the behavior. The design includes the Remote Update IP and Clock PLL IP, as described earlier in this thread. The issue persists: the Remote Update IP returns all ones for all read data immediately after the busy signal deasserts.
Specifically, after configuration completes, I wait for the busy signal to deassert, then read the current configuration boot address and reconfiguration trigger conditions. All read data returns 0xFFFFFFFF. However, if I wait approximately 300 µs after busy deassertion, reads and writes work correctly.
The latest SignalTap capture is attached.
The latest SignalTap capture is attached. I am also attaching my sample project for your reference, so you can reproduce the issue directly. It is a minimal, working design that uses an external clock and reset with three LED outputs, Clock PLL IP, and Remote Update IP. The PLL locked signal is used as reset with proper clock domain synchronization.
If possible, could you share your project that worked as expected?
I am using a Cyclone 10 GX FPGA with part number 10CX150YF672E5G.
Regards,
Sumanth S
Regular ContributorHello Sumanth,
I am sorry we only have devkits to try.
10CX105YF672I5G - working
10CX150YF672E5G - not working
The only difference is
operating temperature Industry grade (-40'C to 100'C) is working
operating temperature Enhance grade (0'C to 100'C) is not working
From your statement, if you waited approximately 300 µs after busy deassertion, reads and writes work correctly.
So, it is not the IP is not working at all. It will be working correctly if you give some buffer around 300us after busy signal deasserts.
Is this correct?
If you give 300us buffer after busy signal deasserts, will it impact your design implementation?
regards,
Farabi
New ContributorHello Fabri,
Yes, adding ~300 µs delay after the busy signal deassertion does not cause any problem to my project from a functionality or performance perspective.
However, our main concern is understanding the actual root cause of this behavior. Specifically, we are trying to determine why there is a difference between the two part numbers (10CX105YF672I5G – industrial grade working vs. 10CX150YF672E5G – enhanced grade requiring delay), even though the functionality should ideally be consistent.
At this point, we cannot rely on a fixed or “magic number” like 300 µs without a clear technical justification. For a robust design, we need proper guidance on:
What is internally causing this delay requirement
Whether this behavior is documented or expected for certain variants
If there is a recommended way (e.g., status check or handshake) to safely determine readiness instead of using a fixed delay
Could you please provide proper direction or clarification on this?
Regards,
Sumanth S
