[diamondman]

I am sorry you suffer from the dongle collection woes too. The only reason I can see to buy expensive dongles are the ones that have a big blob of RAM on them for quickly reading debug output from the chip without slowing it down, and ones that can adapt to highly exotic voltages and pin outs automatically. But usually the software for these only work in windows, have secret drivers, and are NOT worth 2 thousand dollars.

Xilinx and Altera would not have to give up their custom algorithm. It is like building GCC instead of using Intel's compiler. We just want to know what the chip's instructions are, we will find a way to make it optimal ourselves.

[snops]

In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's[1] Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself.

Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor latency (1ms) and flash peripherals require quite a few read-modify-write operations, which soon adds up. More expensive JTAG dongles can run these operations locally on the dongle, with USB just for bulk data transfers, or even download and run code on the target itself for even lower latency, greatly increasing download speed. Since this software needs to be tested for each target, requiring a physical chip to be bought, this gets very expensive to develop. Even a "cheap" dongle like the Segger J-Link has an incredibly long list of targets[2], and I suspect a substantial amount of the purchase price is in engineering and testing flash drivers for those.

ARM seem to be trying to solve some of these problems in the ARM world with CMSIS-DAP[3], an open standard for JTAG/SWD dongles USB protocol. It uses USB HID, so no drivers should be needed on any platform, and they have even created an Apache licensed implementation[4], which Freescale are now using in their FRDM boards.

[1]http://www.lauterbach.com/ [2]https://www.segger.com/jlink_supported_devices.html [3]http://www.keil.com/support/man/docs/dapdebug/dapdebug_intro... [4]https://github.com/ARMmbed/CMSIS-DAP

[diamondman]

Very well written.

I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.

In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.

Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip. While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.

I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.

[snops]

>Are you talking about the flash driver for loading external SPI flash?

I was slipping into talking about ARM microcontrollers there, which have internal flash. Reads from it are memory mapped, but writes generally require feeding peripheral registers with commands, hence the latency sensitive read-modify-write. Some ARM microcontrollers do have more direct methods though, some of Freescale's Kinetis range have a feature called EzPort, where you hold a pin low on boot and it pretends to be SPI flash instead, and tiny 8 bit micros like the AVR all have something similar as full JTAG would be too big for them.

>If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.

Yeah, this is what I meant by having code run on the "target", this being the microcontroller you are programming. You are right in thinking this means the JTAG dongle no longer needs to know how to program flash itself, but it still needs to code to load in and instructions on how to do it (setting up clocks etc), which are also very platform specific. You could do the same for external flash, but its often easier just to connect to it directly and bypass the microcontroller.

Feel free to PM me if you have any more questions.