JTAG chain debugger tools scripts & JTAG clock management

--- Quote Start ---

How to synchronize my DUT internal registers and I/Os JTAG cells on the same clock? Or how can I be sure to correctly sample output pins with the JTAG chain?

--- Quote End ---

Just as you would with any other design that uses two clocks, you use clock-domain crossing logic. Eg., if its just one piece of info that needs to be transferred, you use a handshake with synchronizers, or if its lots of info, you use a FIFO.

--- Quote Start ---

Can I specify DUT clock state via JTAG and connect that signal to a normal pin (meaning non-clock dedicated pin) and then use it as clock for my DUT?

--- Quote End ---

If you have a clock for your DUT, then there is nothing special required, you simply use it. If that clock domain needs to transfer info to JTAG, then you need to use clock-domain crossing logic.

This is all taken care of in the JTAG-to-Avalon-MM bridge, which is why I suggested using it.

--- Quote Start ---

I also though of connecting the DUT clock pin to the JTAG clock, but it would be quite complicated as my DE1 connections are buried in the card plastics.

--- Quote End ---

The JTAG clock comes from the USB-Blaster, there is no option or reason to change it.

Cheers,

Dave

I investigated deeper this DUT clock control problem and I found 2 solutions proposals (http://openocd.sourceforge.net/doc/html/faq.html):

--- Quote Start ---

• solution# 1 - a special circuit
  In order to make use of this, your CPU, board, and JTAG adapter must all support the RTCK feature. Not all of them support this; keep reading!

• solution# 2 - always works - but may be slower
  Often this is a perfectly acceptable solution.
  In most simple terms: Often the JTAG clock must be 1/10 to 1/12 of the target clock speed. But what that “magic division” is varies depending on the chips on your board. arm rule of thumb Most ARM based systems require an 6:1 division; ARM11 cores use an 8:1 division. xilinx rule of thumb is 1/12 the clock speed.

--- Quote End ---

I'm searching for a simple solution to my problem, I then prefer the second one.

In my case, the JTAG clock TCLK seems to run at 6Mhz (because using a USB-Blaster cable, see source here (http://www.alteraforum.com/forum/showthread.php?t=21914)) and the DE1 board has 27 and 50Mhz oscillators. If my design uses a 27Mhz clock and a 6Mhz JTAG clock, I will not correctly sample any fast signals (one clock period wide, for instance).

Quartus II tools are able to perfectly use JTAG circuit on DE1 board, I should have the possibility to do the same.

• does someone know how quartus tools manage jtag to correctly sample all output signals, or anything else about clock synchronization on an altera development board such as the de1?

• can i specify dut clock state via jtag and connect that signal to a normal pin (meaning non-clock dedicated pin) and then use it as clock for my dut?

About the second question I'll try to use a gated clock/synchronous clock enable circuitry between the board clock and the JTAG provided clock signal, I'll keep you updated!

Regards!

J-B

Hi everyone,

I carefully read Dave's JTAG-to-Avalon tutorial and it was interesting, particularly the section over Qsys which I never used before.

This debug system is good but cannot be integrated to my design, question of requirements.

Instead of it, as I explained previously, I'm using low level JTAG interface with only the DUT on the FPGA to test it.

Thanks to Dave's Virtual JTAG interface tutorial, I use the device_dr_shift and device_ir_shift tcl procedure to read from and write to DUT I/Os.

i have however a problem with the device under test clock control / management via jtag.

Following Altera's cyclone II documentation, it seems that the dedicated clock input pins cannnot be drived by JTAG, but can be captured.

Which is OK with what Dave previously said:

--- Quote Start ---

--- Quote Start ---

I'm also always searching for explanation about how the JTAG manages the DUT clock, when JTAG is active. Does it disable the clock, how is it done?

--- Quote End ---

The JTAG does nothing to the clocks, its completely independent of your top-level design's clock pins. If you want the signals from JTAG to be synchronous to your DUT clock, then you have to add the synchronization logic.

--- Quote End ---

Then, when I will set DUT inputs, I will not sample correctly the corresponding output, because registers will be clocked on my device clock, which is faster than JTAG clock.

My question is then :

• how to synchronize my dut internal registers and i/os jtag cells on the same clock? or how can i be sure to correctly sample output pins with the jtag chain?

• can i specify dut clock state via jtag and connect that signal to a normal pin (meaning non-clock dedicated pin) and then use it as clock for my dut?

I also though of connecting the DUT clock pin to the JTAG clock, but it would be quite complicated as my DE1 connections are buried in the card plastics.

In advance, thanks for your help!

J-B

--- Quote Start ---

I have a DE1

--- Quote End ---

Here's a basic top-level design and constraints file in the format I've used for the tutorial:

http://www.alteraforum.com/forum/showthread.php?t=35687

Cheers,

Dave

Hi,

I'have a DE1, it shouldn't be too difficult to make it work, on the basis of your DE2 work.

Regards,

J-B

Hi J-B,

--- Quote Start ---

I'll implement your JTAG-to-Avalon system in the following hours/days, I will come back to you if I need help or to give you my feedback.

--- Quote End ---

Do you have any of the boards I list:

http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial

BeMicro-SDK, BeMicro, and DE2?

If you have a different one, and have trouble getting it to work, let me know.

Cheers,

Dave

Hi dave,

Thank you for your explanations.

I'll implement your JTAG-to-Avalon system in the following hours/days, I will come back to you if I need help or to give you my feedback.

Have a good day,

Regards,

J-B

--- Quote Start ---

I think using pure JTAG chain with DUT I/O better fits my requirements.

--- Quote End ---

Ok, so how are you going to set and clear individual bits?

Hmm, how about a block of registers? Ok, so first you'll need a shift sequence to load the address register, then a shift sequence to issue a read or write command, and then perhaps another shift sequence to read the result. Ah, but what about slow devices, how to you know when read data is ready?

By the time you've answered all those questions, you've re-written your own implementation of the JTAG-to-Avalon-MM bridge.

Read the Avalon analysis document. No matter how you implement your design, you have to implement much of the same functionality as already exists in the JTAG-to-Avalon-ST bridge, and then the JTAG-to-Avalon-MM bridge. I don't like some aspects of the design, but it works, so I just use it.

I'm not trying to sell this to you :) I'm just trying to point out that you have better things to do than to try and create some low-level JTAG components, when the components you need already exist.

Cheers,

Dave

--- Quote Start ---

I didn't know it was possible to integrate Avalon systems to ASIC designs. Or maybe design effort should be carried out to replace it by another bus protocol?

--- Quote End ---

You're still missing the point.

Think of the JTAG-to-DUT bridge as a black box. Its sole purpose in life is to give you some way of using a JTAG transaction to set bits and read the bits connected to your DUT.

For the FPGA design, the JTAG-to-DUT bridge can easily be implemented using the JTAG-to-Avaon-MM bridge and PIO components. If you were using a Xilinx FPGA, you'd use a bscan component, if you were using a Lattice device, you'd use their JTAG component. In your ASIC, you can use whatever JTAG logic they offer. Regardless of the internal implementation, the top-level functionality is identical.

Cheers,

Dave

--- Quote Start ---

Can you explain the difference between the device_dr_shift and device_virtual_dr_shift procedures, and between the device_ir_shift and device_virtual_ir_shift procedures?

--- Quote End ---

device_ir_shift shifts bits into the real JTAG IR register.

device_virtual_ir_shift shifts bits into a shift register implemented using logic elements in the FPGA fabric. This shift register is accessed by first shifting an instruction into the real JTAG IR register, and then shifting the Virtual instruction into the DR register. If you look at the SignalTap traces in that document and the Avalon Analysis document, you'll see the real JTAG IR instructions that correspond to accessing the Virtual JTAG IR and DR (which are loaded using JTAG shift-DR sequences).

--- Quote Start ---

I understand the virtual procedures are higher level, but are they safer to use? Why use the virtual ones instead of the low-level ones?

--- Quote End ---

Read vjtag.pdf again. The Virtual JTAG instructions can be constructed using low-level JTAG instructions. However, you have to know the encoding, so that you can generate the correct JTAG Shift-IR sequence followed by the JTAG Shift-DR sequence needed to implement a Virtual Shift-IR or Shift-DR sequence. That encoding depends on the number of JTAG nodes in the design, and so to determine the encoding you first need the HUB_INFO and NODE_INFO for each node in the JTAG design.

The JTAG-to-Avalon-MM bridge example contains a JTAG script for quartus_stp that implements all of the JTAG commands you are interested in.

Cheers,

Dave