JTAG timing constraints

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

--- 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!

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)

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,

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

Perhaps some limitations due to Forum's policies..?

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)