Timing Violations in JTAG Signals

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.

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

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

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?

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

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.

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

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

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

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.