Hi, Over the years my company has made many Altera FPGA designs, and for a long time the way-of-work for JTAG constraints remained undefined and of little consequence. Then for a couple Arria V designs, JTAG instability became a hot issue (e.g. random failures when discovering the JTAG chain, using SignalTap, using SystemConsole). Our initial strategy probably was to not constrain JTAG at all (as JTAG is 'slow' and its logic is fixed), but then we would get Quartus errors regarding unconstrained ports/clocks. We then tried to find constraints recommended directly by Altera, but never could find a conclusive, complete, satisfactory answer. Based on experience we do feel that the constraints actually affect JTAG stability, and so we're still keeping an eye out for a good solution. Note that the JTAG hardware part for our designs was always rather basic, so we don't think the instability originates from there. A selection of the examples and best practices we have found and tried over the years: - Old TimeQuest cookbook: can't find it anymore - Recent TimeQuest cookbook: https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/manual/mnl_timequest_cookbook.pdf - Knowledge base item 1: https://www.altera.com/support/support-resources/knowledge-base/solutions/rd07182016_788.html - Knowledge base item 2: https://www.altera.com/support/support-resources/knowledge-base/solutions/rd04282008_867.html - Forum post: https://www.alteraforum.com/forum/showthread.php?t=56328 Some of these examples seem to contradict each other, adding to the confusion. My specific questions for Altera are: 1) What are the JTAG constraints recommended by Altera? 2) Are there any plans regarding JTAG constraints? E.g. having Quartus automatically implement them? 3) Are there any known JTAG issues for the Arria V family? If there are, are these fixed in the 10 series? Best regards, Daniel

Hello Daniel, Do you use original Altera USB Blaster? The best reliable source is TimeQuest Analyzer Cookbook that is written by Altera. In DE1-Soc I have found an example with these constraints: # for enhancing USB BlasterII to be reliable, 25MHz create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} set_input_delay -clock altera_reserved_tck -clock_fall 3 set_input_delay -clock altera_reserved_tck -clock_fall 3 set_output_delay -clock altera_reserved_tck 3 So you are not alone with JTAG problems on unconstrained designs. Actual values of constraints depends on your hardware (jtag connector to FPGA routes). Best regards, Leonardo

The weird thing is that the JTAG signals are hard, fixed paths, so it doesn't make sense that timing constraints should have any affect on them all.

--- Quote Start --- The weird thing is that the JTAG signals are hard, fixed paths, so it doesn't make sense that timing constraints should have any affect on them all. --- Quote End --- I'm inclined to agree that JTAG constraints should not affect the design at all. At best it would serve as a check that your hardware delays and clock frequency are viable i.c.w. the fixed FPGA paths. My experience tells me though that the JTAG constraints *do* affect JTAG stability.

@Leonardo: The latest cookbook example for JTAG is lot more extensive than your example. It also includes fitter-specific constraints, implying these *do* have effect? --- Quote Start --- if { $use_fitter_specific_constraint && [string equal quartus_fit $::TimeQuestInfo(nameofexecutable)] } { # Define a different set of timing spec to influence place-and-route # result in the jtag clock domain. The slacks outside of FPGA are # maximized. } --- Quote End --- Our JTAG hardware routing is nothing special, and we always use USB Blaster I which only supports 6 MHz. Considering each clock cycle is a whopping 166 ns, I find it hard to believe that JTAG constraints could pose an issue at all, but they do. I conclude then that the constraints (sometimes adversely) affect the FPGA logic.

Hello All, I wonder if there's been any further progress or a 'definite conclusion' on this matter? I recently did a prototyping-board and ran into JTAG configuration issues, mainly the value of VCC, to which the pull up resistors had to be pulled up (as per Max 10 'Pin Guidelines' document). These were the resistors on the 4 JTAG signals and the 3 configuration resistor (nConfig, nStatus and ConfigDone pins). After I fixed these issue on the proto board, JTAG configuration always worked on my one proto board and still does. I made same fixes on new version of boards (new pcb layout), though 1 or 2 of the JTAG signal likely increased slightly in trace-length, but really no other change. Unfortunately on the new version board (tried only one board yet), JTAG configuration is failing with nStatus always staying low, indicating that JTAG FSM is stuck in the 'reset' state. However I am able to read the 'device ID' when trying to configure, so I assume JTAG signals on the FPGA are working. Here are some other points: - TCK frequency is 6MHZ (As per other info out there, I could change that to 16 or 24MHz as I am using Blaster-II, using 'jtagconfig' utility in the command line, but I have been unable to do that. Nevertheless 6MHz is the slowest rate, but I wanted to try faster rates on my Proto board so see how fast I can go, where it is working. The new boards are 'nearly identical' in terms of JTAG trace-lengths and trace-widths). - I am using USB-Blaster II (Rev B. The ribbon cable length on it is about 8 inches. I read somewhere reducing it a lot may help but have not tried it yet. - I not using 'diodes and caps' on the JTAG lines, as recommended by Altera / Intel to suppress 'voltage overshoot', on either of the boards. However Altera documents states that they are Only needed if JTAG connector supply (jtag connector pin# 4) is Over 2.5V and I am only using 2.5V supply on both the boards. - I am using a UBGA chip, so cannot probe FPGA pins directly, but since I am able to get Device ID, I am assuming JTAG pins are alive and working Thanks a lot!

JTAG timing constraints | Altera Community

17 Replies

Altera_Forum
Honored Contributor
8 years ago
OP (with the Arria V) reporting in.

--- Quote Start ---
I wonder if there's been any further progress or a 'definite conclusion' on this matter?
--- Quote End ---

I made a separate support ticket for this issue; Altera's response can be summarized as follows:
Not the whole JTAG controller is hard IP, therefore timing constraints are vital.
This is are the currently recommended constraints: https://www.altera.com/support/support-resources/knowledge-base/tools/2016/why-do-i-see-jtag-problems-when-using-the-signaltap-ii-logic-ana.html
There are no known Arria V issues related to our issue.

Our strategy is to try out these new constraints on future designs. We haven't gotten around to testing them on the affected design. Thus no progress or definite conclusion from our side.
Altera_Forum
Honored Contributor
8 years ago
Hello Anand,

Thanks for trying to help.

1. JTAGEN on both boards is pulled up (10K to 3.3V)
2. All three pins pulled up to 2.5V using 10K Res. (They are on bank 8, where the VCCIO is 2.5V I referred sec 1.1.2 of the Max 10 'Pin connection guidelines' document)
3. TDI and TMS also pulled up by 10K but to 2.5V, as per the same sec 1.1.2 of the 'Pin connection guidelines' document. (I did not use diodes / caps on the JTAG lines (on either of the documents) to prevent 'voltage overshoot' problem, since as per the documents it is recommended, when JTAG supply is over 2.5V)
4. CONF_DONE also stays low, along with nStatus. Only nConfig goes high, which is expected.
5. I followed 'Pin connection guidelines', the 'Max 10 Design Guidelines' and the 'Board Design Guidelines AN114' documents, for both the boards.
6a) I just tried loading the 'sof' file and it got loaded on the very first attempt! Here's the message I get..
"info (209060): started programmer operation at wed dec 06 09:34:30 2017
info (209016): configuring device index 1
info (209017): device 1 contains jtag id code 0x031820dd
info (209007): configuration succeeded -- 1 device(s) configured
info (209011): successfully performed operation(s)
info (209061): ended programmer operation at wed dec 06 09:34:31 2017"
6b) However I really need to load the POF file and this is the message I am still getting...
lo and behold.. I got it configured the first time using the POF file!!
I am using the 'exact same' setup I used yesterday evening before leaving work. Did not even move a wire, except for plugging the power connector back on! I only started with the SOF file today (which I never tried on this newer board), before the POF file.
So there's something really erratic / intermittent, which is bad as these boards are for commercial use!!
This is very similar to the comments posted at the start of this post, that JTAG configuration reliability is becoming erratic :-| !
This person (daniel@3t.nl) stated.. “jtag instability became a hot issue (e.g. random failures when discovering the jtag chain, using signaltap, using systemconsole).”

For the past two days, when using the POF file, I would only read the Device ID and then get error message something like "Error 16328: Put the device in User mode .."
Unfortunately I had to clear my browser cache and don't recall the exact message. If it re-appears I would post it.

Thanks,
Altera_Forum
Honored Contributor
8 years ago
Hello Anand,

Thanks for trying to help.

1. JTAGEN on both boards is pulled up (10K to 3.3V)
2. All three pins pulled up to 2.5V using 10K Res. (They are on bank 8, where the VCCIO is 2.5V I referred sec 1.1.2 of the Max 10 'Pin connection guidelines' document)
3. TDI and TMS also pulled up by 10K but to 2.5V, as per the same sec 1.1.2 of the 'Pin connection guidelines' document. (I did not use diodes / caps on the JTAG lines (on either of the documents) to prevent 'voltage overshoot' problem, since as per the documents it is recommended, when JTAG supply is over 2.5V)
4. CONF_DONE also stays low, along with nStatus. Only nConfig goes high, which is expected.
5. I followed 'Pin connection guidelines', the 'Max 10 Design Guidelines' and the 'Board Design Guidelines AN114' documents, for both the boards.
6a) I just tried loading the 'sof' file and it got loaded on the very first attempt! Here's the message I get..
"info (209060): started programmer operation at wed dec 06 09:34:30 2017
info (209016): configuring device index 1
info (209017): device 1 contains jtag id code 0x031820dd
info (209007): configuration succeeded -- 1 device(s) configured
info (209011): successfully performed operation(s)
info (209061): ended programmer operation at wed dec 06 09:34:31 2017"
6b) However I really need to load the POF file and this is the message I am still getting...
lo and behold.. I got it configured the first time using the POF file!!
I am using the 'exact same' setup I used yesterday evening before leaving work. Did not even move a wire, except for plugging the power connector back on! I only started with the SOF file today (which I never tried on this newer board), before the POF file.
So there's something really erratic / intermittent, which is bad as these boards are for commercial use!!
This is very similar to the comments posted at the start of this post, that JTAG configuration reliability is becoming erratic :-| !
The person (daniel@3t.nl) stated.. “jtag instability became a hot issue (e.g. random failures when discovering the jtag chain, using signaltap, using systemconsole).”

For the past two days, when using the POF file, I would only read the Device ID and then get error message something like "Error 16328: Put the device in User mode …"
Unfortunately I had to clear my browser cache and don't recall the exact message. If it re-appears I would post it.

Thanks,
Altera_Forum
Honored Contributor
8 years ago
Hello Anand,

On my second board, I tried the SOF first and it programmed without any issue, on the first attempt itself.

On trying the POF file, I got the following message..

Info (209060): Started Programmer operation at Wed Dec 06 17:04:27 2017
Info (209017): Device 1 contains JTAG ID code 0x031820DD
Info (209044): Erasing MAX 10 configuration device(s)
Info (209023): Programming device(s)
Info (209021): Performing verification on device(s)
Error (209048): Verify failure on device number 1
Error (209012): operation failed (83% on the 'Progress' bar)
Info (209061): Ended Programmer operation at Wed Dec 06 17:07:13 2017

On trying again, I get following message right away, as before...
Info (209061): Ended Programmer operation at Wed Dec 06 17:07:13 2017
Info (209060): Started Programmer operation at Wed Dec 06 17:07:51 2017
Info (209017): Device 1 contains JTAG ID code 0x031820DD
Info (209044): Erasing MAX 10 configuration device(s)
Warning (16328): The real-time ISP option for Max 10 is selected. Ensure all Max 10 devices being programmed are in user mode when requesting this programming option
Error (209012): operation failed
Altera_Forum
Honored Contributor
8 years ago
Could there be any Voltage regulation issue? I am using LM1117 chips for 2.5V and 3.3V supplies.
Part nos are LM1117MPX-3.3/NOPB and LM1117MPX-2.5/NOPB

Scope is showing values between 3.36 - 3.40 and 2.56 – 2.60V.

So there is about 4mV swing / ripple on each of the supply.

Thank you,
Altera_Forum
Honored Contributor
8 years ago
Hi,

--- Quote Start ---

"Error 16328: Put the device in User mode …"
Thanks,
--- Quote End ---

This error is because CRC mismatch.
1.Try to DISABLE it and program. Check session 3.6.2
https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/max-10/ug_m10_config.pdf
or
try to program using both the methods (By using on-chip ram / by using on-chip flash)
https://www.youtube.com/watch?v=0k4azmdw9sk

Best Regards,
Anand Raj Shankar
(This message was posted on behalf of Intel Corporation)
Altera_Forum
Honored Contributor
8 years ago
Figured out better way sending picture... Insert it, rather than attach it :-)
Hopefully this is better..
https://www.alteraforum.com/forum/attachment.php?attachmentid=14533

Forum Discussion

JTAG timing constraints

17 Replies

Recent Discussions

Avalon-ST configuration with Agilex 3 fails

Cyclone IV E – PLL Power Track Width Recommendation Clarification

Operating temperature for 10M08DCF256A7G

System PLL of Agliex5 PCIE example design cannot be locked after configuration

Download links not working