On Fri, May 18, 2012 at 10:48 PM, simonqian.openocd <[email protected]> wrote: >> One thing that Versaloon and other MCU based HW >> has advantage is that the MCU does quite some time >> critical work. On the contrary, FTDI based HW will be >> at the mercy of the host since there are no intelligence >> within the HW. >> http://openocd.sourceforge.net/doc/doxygen/html/ft2232_8c.html >> +++++ >> FT2232 based JTAG adapters are "dumb" not "smart", because >> most JTAG request/response interactions involve round trips >> over the USB link. A "smart" JTAG adapter has intelligence >> close to the scan chain, so it can for example poll quickly for a >> status change (usually taking on the order of microseconds not >> milliseconds) before beginning a queued transaction which >> require the previous one to have completed. >> +++++ > It's true for other adapters for example SWD, but it's not true for > generic JTAG. > There is no high level interface for JTAG, so all the JTAG dongle > does in the same way in openocd.
This is a very interesting statement. I think ST-Link is an exception for OpenOCD. Where should this high level interface reside for the intelligent debuggers in your opinion? FW side or the host side? > Of course, MCU based adapters can be smart, but after they implement > a generic ADIv5 layer. And libSWD is not libSWD only, but libADIv5. > Before that, they are as "dumb" as FT2232 based JTAG dongles. Do you mean the firmware can integrate at least some part of libswd in order to achieve better performance? Does Versaloon's FW integrate some part of libswd (or similar idea)? >> See the above, the USB delay does play a big part to >> reduce the high speed USB advantage of FTx232H (125us >> USB microframe time). > I think the way to evaluate the USB delay will be below. > It depends on the rate between the time used to do the > transaction and the time used to do the JTAG operation. If the JTAG > time is much longer than the transaction time, there will not be significant > performance descend. > For current openocd code, a memory access can be as large as 4K bytes > for CM3 and 1K bytes for CM0. So for large memory accesses, every 4KB > will has a "endcheck" which will poll the result of the access. So it's not > a great payload. But for small memory access eg 32-bit access, it another > story. Okay, you think in higher level. For me I think in a lower level -- USB transport level. Andreas' MPSSE work shows that lower level optimization (using libusb-1.0 async API) does improve things quite a lot for OpenOCD. But your higher level optimization idea is also very interesting and may have even more significant benefit to OpenOCD. -- Xiaofan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
