Timing Violations in JTAG Signals

[FabianL]

Hello,

I have a Arria10 FPGA design using Platform Desginer which includes a Avalon to JTAG Brdige.

I have added a jtag.sdc file to the project based on this guideline: JTAG Signals

and set all the "--customize here--" sections according to my design (see attached sdc file).

However the Timing Analyzer gives me several setup violations on JTAG signals:

-18.207	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_8	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.240	Slow 950mV 100C Model
-18.206	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_9	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.239	Slow 950mV 100C Model
-18.157	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_7	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.190	Slow 950mV 100C Model
-18.142	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_10	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.175	Slow 950mV 100C Model
-18.123	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_11	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.156	Slow 950mV 100C Model
-18.120	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_6	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.582	4.153	Slow 950mV 100C Model
-17.207	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_1	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.125	3.697	Slow 950mV 0C Model
-17.136	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_3	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.125	3.626	Slow 950mV 0C Model
-17.069	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_2	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.125	3.559	Slow 950mV 0C Model
-17.064	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_4	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.125	3.554	Slow 950mV 0C Model
-16.972	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-2.125	3.462	Slow 950mV 0C Model
-16.075	auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|atom_inst|atom~jtag_reg__nff	altera_reserved_tdo	altera_reserved_tck (INVERTED)	altera_reserved_tck (INVERTED)	33.333	-0.450	4.240	Slow 950mV 0C Model

The listed registers look similar but not identical to the security reg listing in the jtag.sdc line 86-89 which are to be ignored.

So I'm not sure if  these errors are actual errors caused, e.g. by a too high JTAG clock rate, or if these registers are just missing a respective false path due to encrypted core.

The Timing Analyzer does list the falling paths as encrypted:

Please advise how to deal with these JTAG signal in timing analysis.

Thanks

Fabian

[sstrell]

You say jtag.sdc was added to the project, but is it listed in the Timing Analyzer settings in the Settings dialog box?  Very common issue to forget to to add that there.

[Kenny_Tan]

Can you attached your design.qar file to take a look?

[FabianL]

The sdc file is active in the project and  also in the timing Analyzer settings. 

I am sorry, I cannot share my complete project, as it contains Intellectual Property of the company.

The failing paths are explicitly not covered by the .sdc constraint from the Intel Manual:

# Cut a few timing paths that are not related to JTAG logic in
# the FPGA core, such as security mode.
set_false_path -from [get_ports {altera_reserved_tdi}] -to [get_ports {altera_reserved_tdo}]
if { [get_collection_size [get_registers -nowarn *~jtag_reg]] > 0 } {
set_false_path -from [get_registers *~jtag_reg] -to [get_ports {altera_reserved_tdo}]
}

The violations are about the tdo_reg

-18.207 auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|jtagpins|int_tdo_reg~LRTM_8 altera_reserved_tdo altera_reserved_tck (INVERTED) altera_reserved_tck (INVERTED) 33.333 -2.582 4.240 Slow 950mV 100C Model

The Question is, is this intentional? and how to debug timing issues within an encrypted core?

Or are the tdo_reg constraints missing in the sdc file?

Thanks

Fabian

[Kenny_Tan]

1) Can you double check if you have missing constrain by following the below:

https://www.intel.com/content/www/us/en/support/programmable/articles/000092769.html

2) Do you have signal tap added to your design? If yes, can you temporally remove the signal tap and see if there are still timing violation?

[FabianL]

1) I did the check with the mentioned sdc template and it matches completely the design .sdc file, except for an assignment which is only valid for Stratix10. Since I'm using Aria 10 this won't be applied.

2) I don't have any signal tap in my design. The only thing I use is JTAG to Avalon Master Bridge Intel FPGA IP Version 19.1 which accesses the main Avalon system bus

best regards

Fabian

[Kenny_Tan]

Can you temporally try to remove that IP to see if that is the root cause?

[FabianL]

I just removed the IP and still have the timing errors.

I also managed to create a very simple example project with basically nothing in it. It also shows timing errors related to JTAG TDO Pins, even though it's about different source nodes. Maybe that helps to analyze the problem. 

[Kenny_Tan]

After running several tests on a smaller design, we observed that violations may occur if Signal Tap has been previously enabled. Once enabled, Quartus tends to retain the configuration and automatically adds an additional module named auto_fab_0. The issue appears to be linked to the encrypted Signal Tap IP.

To address this, please ensure that all constraints are properly defined for your board. You may need to customize the constraint settings accordingly. For reference, Intel provides detailed guidance on JTAG constraints here:

JTAG Constraints File – Timing Analyzer Cookbook

If all constraints are correctly applied and aligned with your board configuration, we recommend reducing the operating frequency to 16 MHz as a next step.

https://www.intel.com/content/www/us/en/docs/programmable/683719/current/jtag-timing-constraints-and-waveforms.html

Additionally, I will further investigate whether this issue is related to a potential bug in the current version of Quartus by comparing it with older releases. I’ll follow up with more findings soon. Thanks

[FabianL]

Yes I can verify, that Quartus has added a module auto_fab_0 to the project, but the signal tap file definitely has been removed.

Is there any possibility to force Quartus to remove all signal tap remnants? 

best regards

Fabian

[FabianL]

I am a bit confused about the recommended jtag.sdc file:

in the top function set_jtag_timing_constraints the default is to use separate timing constraints for analysis and fitter. As I understand the related comment this is the recommended default:

    # If the timing characteristic outside of FPGA is well understood, and 
    # there is a need to provide more slack to allow flexible placement of 
    # JTAG logic in the FPGA core, use the timing constraints for both 
    # timing analysis and fitter; otherwise, use the default fitter timing
    # constraints.

    # ---customize here---
    set use_fitter_specific_constraint 1

However in the set_default_quartus_fit_timing_directive function the JTAG clock is fixed to 33 MHz (which is the max. Arria 10 supports)

proc set_default_quartus_fit_timing_directive { } {
    # A10 supports max 33.3Mhz clock
    set jtag_33Mhz_t_period 30

    create_clock -name {altera_reserved_tck} -period $jtag_33Mhz_t_period [get_ports {altera_reserved_tck}] 
    set_clock_groups -asynchronous -group {altera_reserved_tck} 
    # Force fitter to place register driving TDO pin to be as close to 
    # the JTAG controller as possible to maximize the slack outside of FPGA.
    set_max_delay -to [get_ports { altera_reserved_tdo } ] 0 
}

In the end this gives me the timing errors, even if I change the Blaster frequency to 16 MHz in set_tck_timing_spec 

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

    # ---customize here---
    set tck_t_period $ub2_safe_t_period

    create_clock -name {altera_reserved_tck} -period $tck_t_period  [get_ports {altera_reserved_tck}]
    set_clock_groups -asynchronous -group {altera_reserved_tck}
}

To me it seems strange to have 2 separate constraints for the same clock for analysis and fitter.

• Could you please explain what's the reason for this?
• Is it intended to adjust the clock constraint in set_default_quartus_fit_timing_directive when changing the JTAG Frequency? if yes why is it using separate functions to set the clock. If no then I still have the problem with the timing errors!

Thanks for your help

best regards

Fabian

[Kenny_Tan]

I will answer the below one by one:

Question:

Is there any way to force Quartus to completely remove all Signal Tap remnants?

Answer:

The most reliable method is to create a new Quartus project from scratch. Gradually import all your source files, settings, and constraints into the fresh project. This ensures that no leftover Signal Tap configurations or hidden assignments carry over.

[Kenny_Tan]

For your second question:

Purpose	Clock used	Why
Fitter (placement)	33 MHz	Forces the TDO register close to the boundary, to minimize external setup/hold violation risk at max supported speed.
Timing Analysis (reports)	User-set (6–24 MHz)	Matches your real USB Blaster clock so you get realistic reports/slack.

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.

[FabianL]

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

[Kenny_Tan]

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.

[Kenny_Tan]

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

[FabianL]

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