Timing Violations in JTAG Signals

For your second question:

Deep reasoning:

Placement optimization: The fitter needs to assume worst case (33 MHz) even if your real hardware (Blaster II safe mode) runs slower (e.g., 16 MHz). Otherwise, it could place logic too far inside the chip, making boundary timing fail if someone runs at higher TCK (say, another Blaster or faster debugger).
Analysis realism: You want static timing analysis (STA) to reflect the real TCK in your board setup — 16 MHz, 24 MHz, whatever you're actually using.

Even if you slow down the Blaster to 16 MHz, the fitter thinks "what if 33 MHz is used," and forces a stricter placement.

But the real problem is:
If your JTAG logic (e.g., TDO register) can't meet 33 MHz timing internally even after placement, then you get errors.
This indicates the TDO path is too long or badly routed.

Solution paths:
Accept slower timing:
Set use_fitter_specific_constraint to 0 — then fitter and STA both assume 16 MHz.
→ But this risks failure if you accidentally connect a faster JTAG programmer later! Make sure you reduce the frequencies.

About "should I modify set_default_quartus_fit_timing_directive?"
No, don't modify it. It is designed to assume 33 MHz.

From my side, I will open a support case with our developers to understand how to achieve 33 MHz operation with Signal Tap enabled. In the meantime, the recommended workaround is to use the approach described above.

Thanks a lot for the detailed answer.

Changing to 16 MHz and setting use_fitter_specific_constraint to 0 solved the timing issues.

However concerning the Signaltap remnants, I have noticed something else:

I created a complete clean project which no signaltap in it. All I added is in the QSYS file is the JTAG to Avalon Master Bridge Intel FPGA IP Version 19.1

This already gives me timing issues already at 24 MHz (with use_fitter_specific_constraint to 0) even though the Avalon Bus design is extremely basic.

It should be reproducible with the jtagTimingError.qar I've attached earlier.

best regards

Fabian

The JTAG to Avalon Master Bridge and Signal Tap both utilize the same physical JTAG interface, but they serve different purposes:

• The JTAG to Avalon Master Bridge enables communication from JTAG to the Avalon-MM bus, typically used through the System Console or host tools.
• Signal Tap, on the other hand, routes JTAG traffic through a capture core to observe internal FPGA signals during runtime.

Although they are functionally independent, both components use the shared JTAG pins and rely on the altera_reserved_tck clock internally.

The JTAG to Avalon Master Bridge introduces logic that connects directly into the system fabric and Avalon-MM control logic. It uses the altera_reserved_tck clock and interacts with core components.

Is there further question? If no, we shall close this thread.

Thanks, that helps to get things running without timing errors at least.

I would prefer keeping this thread open, until you get any response from your Intel support ticket about how to achieve 33 MHz operation with Signal Tap enabled.

best regards

Fabian

Just to let you know that I am still discussing this with the developer.. Once I got some answer, I will get back to you.

Just to clarify, the 33 MHz setting is not actually supported for the external UBII clock. The constraint you're seeing is only used to make the fitter more aggressive in meeting timing requirements — it’s not the actual operating frequency.

The real question we should be asking is: why can’t timing be met at 24 MHz, and why is it necessary to lower it to 16 MHz instead? In the template, the only section available for modification is labeled "customize here" with the code shown below:

proc set_tck_timing_spec { } {

# USB Blaster 1 uses 6 MHz clock = 166.666 ns period

set ub1_t_period 166.666

# USB Blaster 2 uses 24 MHz clock = 41.666 ns period

set ub2_default_t_period 41.666

# USB Blaster 2 running at 16 MHz clock safe mode = 62.5 ns period

set ub2_safe_t_period 62.5

Hello,

did you get any further information, why it is not possible to run the design with signal tap and USB Blaster clock period set to 24 MHz?

best regards

Fabian

This is still under discussion. However, one thing to note for Stratix 10 and Agilex 7 devices: when using a 24 MHz clock with the new template, timing closure was successfully achieved.

By the way, any reason that you want to use 24Mhz? What is the use case and application that you are using that need this frequencies for Jtag? This is just for my understanding.