Signaltap：waiting for clock

[china_cn]

I instantiated 4 Jesd204b IP cores in the program and generated link_clk with IOPLL. When I use link_clk as a sampling signal for signaltap, signaltap shows the waiting clock. And you can see an error message on the system message: 

Data integrity error is detected during jtag communication. the signal tap result is not trustworthy.

I don't know why, can you answer that question for me.

Thank you.

[RichardTanSY_Intel]

Error (12852): Data integrity error is detected during JTAG communication. The Signal Tap result is not trustworthy. Please check the JTAG chain.

https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#msgs/msgs/echi_tdo_capture_integrity_err.htm

CAUSE: Signal Tap calculated CRC values of the data shifted out of the device once in the device at the source and once in the software as received by computer. The two CRC values don't match. The bits are corrupted during communication. The most likely cause is the signal integrity issue with JTAG chain.

This message is a clear indication that the physical JTAG chain is not properly designed that data communication cannot carried out. This is not a Quartus SW error. You will have to debug your board.

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.

[china_cn]

I'm using the Intel-ARRIA 10-GX FPGA Development Kit, which doesn't look like it's a problem for the development board. For JTAG signal constraints, I only constrain the altera_reserved_tck to 33MHz and set it to an asynchronous clock, is it possible that there is a problem with timing constraints?
Thank you

[RichardTanSY_Intel]

You can try with different project and see if the same issue occur. If issue persists, suspect maybe something wrong with the hardware.

[china_cn]

It may be because the hardware is not configured well. I use USB Blaster for downloading as described above (but there is no problem with the downloader), but using the onboard USB Blaster II works fine. I think I'll be able to debug with a USB cable in the future.
Thank you

[RichardTanSY_Intel]

Based on the KDB, does not seem to be a problem with applying a 33-MHz clock constraint to this altera_reserved_tck pin.

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

[RichardTanSY_Intel · Accepted solution]

Probably missing or incorrect timing constraints for the JTAG signals.

Can you check that these signals are correctly constrained?

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

[RichardTanSY_Intel]

Great to see that you able to find a solution to move forward! Probably you might need to further debug the problematic USB Blaster to know what goes wrong.

Since you have a solution, do you need further help in regards to this case?

Regards,

Richard

[RichardTanSY_Intel]

As you able to find a solution to move forward, I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best Regards,

Richard Tan

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.