HS3 JTAG slowness

[Stefano Antoniazzi]

I'm using the USB-JTAG HS3 dongle as JTAG interface to our proprietary systems.

I implemented JTAG transactions for reading and writing registers on top of the HS3 Adept API.

This works fine but I noticed that there is always a time gap between transactions I can not reduce.

More precisely, I can reduce it using large blocks in batch mode but this is not suitable for many individual register read/write ops.

In fact, the actual data speed looks more than 10x slower than the JTAG frequency. At 15 MHz JTAG I can only perform about 7000 transactions (each one takes about 100 TCK clock cycles).

I can not believe it is just SW overhead. Is there any reason for that? Is there a way to reduce the gaps?

[JColvin]

Hi @Stefano Antoniazzi,

I asked the engineer who wrote/maintains the Adept software about this and while they aren't sure why the amount of data isn't as high as you expected as there are no sleep calls or intentional delay (presuming you aren't introducing it yourself via DjtgSetDelayCnt) they did give me the following tidbits.

Presuming you are operating with the default non-buffered transactions there will always be gaps if you make multiple API calls and aren't operating in batch mode because each API call will generate a packet containing a command and data to send to the device (JTAG HS3 in this case). Each of these take a single USB transaction which has it's own overhead dependent on your system. If you are sending large data transactions (greater than 4096 bytes), this will automatically be split up into the 4096 byte or smaller sized chunks so that a cancel request can be completed in an reasonable amount of time.
It's hard to know from your post, but if those 7000 transactions are a bunch of small data shifts followed by polling of status registers, that will inevitably slow due to overhead associated with each transaction as in each non-batch mode call JtgPutTDIBits will transmit the shift commands, any associated data to be shifted out, and then sync with the MPSSE on the JTAG HS3. Whereas in batch mode, the commands and data are buffered in the host DLL but don't sync with the FTDI chip until one of the three things happen: buffer fills up, a flush API function is called, or an API call requiring TDO data to be returned is made (which requires the buffer to be flushed as USB 2.0 is half duplex). You could maybe set up transaction buffering as a pseudo batch mode (via DPCAPI BOOL DjtgEnableTransBuffering(HIF hif, BOOL fEnable) which is in dtjg.h), but you'll be limited to the same synchronization conditions as batch mode.

If our guess on your style of transactions is correct (the engineer might be able to offer some ways to speed some things up depending on what your system is doing), then unfortunately the only "true" way to speed up the make small change and read a register system would be to make an ASIC that facilitates the role of the USB controller and executes known commands can make decisions on its own without having to communicate over USB (since creating such an engine on the FTDI chip is not possible).

Let me know if you have any questions.

Thanks,
JColvin