Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
4,288 Views

JTAG timing constraints

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_cook...  

- 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
0 Kudos
17 Replies
Altera_Forum
Honored Contributor I
493 Views

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
Altera_Forum
Honored Contributor I
493 Views

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.

Altera_Forum
Honored Contributor I
493 Views

 

--- 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.
Altera_Forum
Honored Contributor I
493 Views

@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.
Altera_Forum
Honored Contributor I
493 Views

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!
Altera_Forum
Honored Contributor I
493 Views

Hi  

 

Are you using Max 10 device? 

Can you attach the screen short of the schematic jtag configuration sheet? 

what is the voltage given on 4th pin for Jtag header? 

 

Best Regards, 

Anand Raj Shankar 

(This message was posted on behalf of Intel Corporation)
Altera_Forum
Honored Contributor I
493 Views

Hello Anand, 

 

Yes it's a Max 10, (10M08, UBGA-169, Single Supply. 10M08SAU169C8G) 

 

Pl see the attached PNG file.  

- Basically I have pull-ups on the TDI and TMS lines (10K to 2.5V), and pull-down on the TCK line (1K to GND).  

- TDO is direct to the FPGA.  

- On pin 4 of the JTAG header, 2.5V is supplied. (These first 3 points I did, as per the Guidelines document).  

- JTAG pins on the FPGA are on Bank 1B, which is at 3.3V, as this is a single supply chip. 

- The 3 configuration related resistors (nConfig, nStatus and ConfigDone) are on Bank 8 of the chip, which I am using at 2.5V and these pins have 10K resistors, pulled up to 2.5V. 

 

I have used same connections on my Prototype board and I am able to do JTAG configuration without any problems.  

 

On my newer version of the board nStatus is always staying low, though JTAG is able to read the Device ID. 

 

I have nearly spent two full days without making any further headway, despite searching a lot online for relevant info, so any tips / debug strategy would be appreciated.  

 

Thanks,
Altera_Forum
Honored Contributor I
493 Views

It seems the picture is loosing it's resolution, after attaching it.  

Perhaps some limitations due to Forum's policies..?
Altera_Forum
Honored Contributor I
493 Views

Attaching a zoomed-in view, for more clarity.. hopefully works

Altera_Forum
Honored Contributor I
493 Views

Hi  

 

1.Is JTAGEN pin of MAXa0 device handled same in both the boards? 

2.Is nSTATUS CONF_DONE nCONFIG pulled up with 10K? 

3.Is TDI and TMS pulled up? 

4.What is the status on CONF_DONE pin when nSTATUS is low? 

5.If you schematic followed all the guidelines. there should not be a problem and trace length difference will also not affect the signal properties at lower frequency so even that's fine(length difference can be 100mil to 200mil generally) 

6.Do you get message during configuration can you attach screen short of it.(put it in word and attach as word file) 

Or 

Can you write simple program (control led using switch) and load the file and check.(To recheck the programming steps)  

 

Best Regards, 

Anand Raj Shankar 

(This message was posted on behalf of Intel Corporation)
Altera_Forum
Honored Contributor I
493 Views

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: 

 

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 I
493 Views

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 I
493 Views

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 I
493 Views

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 I
493 Views

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 I
493 Views

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.p... 

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 I
493 Views

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