New ContributorI use QuartusPro25.3 , Device is AGILEX 7 , I found it often report error when in the "retiming " stage，
Sometime I just modify my design to add some debug signal ， and it report error ，error massage is as below ， Is any one can help , thanks
Super ContributorCan you attached your design here for investigation?
New ContributorSorry ， I can't attach my design ，sometimes just change some debug signal and it report error ,
modify debug signal like below ( F-tile RX related signal )
wire [7:0] DBGO_FPGA_RX_06H = {
//rx_set_locktodata[1],edp_pll_lock[1],rx_is_lockedtodata_sys1,rx_is_lockedtoref_sys1, //4 bit use this error
rx_ready_sys1,rx_ready_sys0,rx_is_lockedtodata_sys1,rx_set_locktodata[0], //4 bit use this ok
rx_is_lockedtodata_sys0,rx_reset_ack_sys0,rx_reset_sys0,edp_reset_cdr[0]} ;
should I update QuatrusPro to 26.1
Super ContributorWithout the design, it will be hard to root cause the problem. Is that fine that you attached the design privately with NDA sign?
Super ContributorIs there further queries? If no, we shall close the thread.
New ContributorHey there! I’ve run into similar headaches with Agilex 7 designs in the newer Quartus Pro versions, and honestly, the "retiming" stage can be one of the most temperamental parts of the entire compilation flow.
Agilex 7 relies heavily on the Hyperflex architecture, and the retiming engine is designed to aggressively move registers across combinational logic to hit those high clock frequencies. One specific point you mentioned—that it reports an error even when you just add some simple debug signals—is actually a classic symptom of how the tool handles "unmovable" logic. When you add a debug core or tap into a signal for Signal Tap, you are often implicitly adding constraints or "preserve" attributes. This effectively tells the retiming engine, "You can't move this register because I need to sample it exactly here." If the engine was previously relying on moving that specific logic to close timing, it can sometimes just give up and throw a generic error instead of a helpful timing report.
I remember a project a while back where I was constantly fighting these "random" STA failures during the retiming phase. My personal insight from that experience was that I had to be much more selective about where I was placing my debug taps. If you tap into a high-speed path that the retiming engine is actively trying to optimize, you're essentially breaking the tool's ability to do its job.
Another thing to look at, which might sound unrelated but has saved me before, is your actual workstation hardware and the compilation database health. Agilex designs are massive, and Quartus Pro 25.3 is very hungry for I/O throughput. I used to run my build environment on an older workstation using some legacy server-grade gear—specifically a few 400GB 3.5-inch SATA 6GBPS SSDs I’d salvaged. While they were "invincible" in terms of durability, the 6GBPS interface eventually became a bottleneck for the massive database writes that happen during the retiming and routing stages. I noticed that if the disk latency spiked during a heavy write phase, Quartus would occasionally throw these weird internal errors that looked like design bugs but were actually just I/O timeouts or database sync issues. If your design is hitting a wall, it’s worth making sure your temp directories are on your fastest possible drive.
Have you tried checking the "Retiming Limit" settings in your synthesis options, or perhaps excluding your debug logic from the retiming optimization entirely to see if that bypasses the error? It would be interesting to see if the error persists if you use a "Virtual Pin" for those debug signals instead.
Super ContributorThis appears less like a true STA issue and more like a Hyper-Retiming sensitivity on Agilex 7, where even a small debug change can affect register movement, especially when tapping F-tile RX status or control signals such as rx_set_locktodata, edp_pll_lock, or rx_is_lockedtoref; the most practical recommendation is to avoid driving the debug bus directly from these raw signals and instead capture registered or synchronized copies first, as this usually helps prevent retiming conflicts, and also perform a clean rebuild to rule out any stale compilation database effects.
