Electronic – What’s the difference between a commercial JTAG debugger and an open source FT2232H OpenOCD debugger


I have seen a few commercial JTAG debuggers such as:

  1. iC6000 On-chip Analyzer (with Aurora protocol support)
  2. Lauterbach – Microprocessor Development Tools

And OpenOCD FT2232H-based JTAG debuggers:

  1. Flyswatter

Why are these commercial debuggers big boxes compared to FT2232H JTAG debuggers which has just a small credit card size PCB? What additional hardware is present inside the commercial debuggers and in which part of debugging can these help?

Best Answer

JTAG cables can be built around all sorts of stuff. Xilinx JTAG cables, for example, have a Cypress chip and an FPGA. Atmel cables generally contain an AVR microcontroller with USB support. They will also usually contain some interface/level translation/protection/isolation components. It really depends on the manufacturer, they're all proprietary and mutually incompatible. Generally you need to have the cable that works with whatever software you need to use. If all you need is OpenOCD, then an FTDI based cable is fine. But if you want to use, say Xilinx ChipScope? Then you need to pay up for either the real thing from Xilinx or a chinese knockoff.

The links you have are not for simple JTAG cables, they are far more specialized. I would personally consider these to be a full-on piece of test equipment. They are basically specialized protocol analyzers. They are designed to interface with specialized trace hardware that is incorporated into the device under test. Trace hardware is distinct from JTAG. It's purpose is to record the complete execution trace of the running software (i.e. all branches taken) across all execution cores and pass it to the external trace collection system (the box in question) over a high speed bus. The trace is then analyzed offline. This is NOT the same as debugging that can be done over JTAG by setting breakpoints and stepping through the code. Trace collection is supposed to be completely transparent to the running program (no breakpoints or added code). Since the processor under test can be executing several hundred million instructions per second, storing the trace as it is produced requires a lot of bandwidth and fast memory. The linked devices support the Aurora protocol (probably among others), which is an 8b/10b encoded high speed serial protocol, somewhat similar to USB 3, serial ATA, serial gigabit/10G ethernet, and PCIe. It's capable of transferring data at 6.25 Gbps, significantly more than what the USB link back to the PC can handle, so the captured data must be stored in onboard RAM for offline analysis. These devices will contain rather high end FPGAs with internal high-speed deserializers to capture the data along with quite a bit (several GB) of fast DRAM, probably DDR2 or perhaps even DDR3.