On Mon, Jul 14, 2014 at 1:32 AM, Angus Gratton <[email protected]> wrote:
>
> I think it should be possible to boost performance inside
> jtag/drivers/cmsis_dap_usb.c while keeping the current swd_driver
> interface:
>
> - Add a command queue (as per ftdi swd driver, etc.) CMSIS-DAP
> includes a provision for multiple commands in a single USB
> request/response (PACKET_SIZE/PACKET_COUNT in DAP_INFO) so this
> should be a performance win already.
>
> - When building the queue, look for queued reads/writes to the same
> register and transfer them into Transfer_BLOCKs rather than
> individual register transfers.
>
Exactly what I have in mind, although I'm having doubts about the
swd_driver part of it, see below.
> I also looked at the dap_ops driver in target/adi_v5_cmsis_dap.c,
> which I'm guessing is the higher layer intended to eventually support
> both SWD and JTAG? This layer also has the (unused) notion of a
> queue.
Not sure if I follow... The dap_ops interface is what all ADIv5 target
operations go through. It supports both SWD and JTAG today and the queuing
is certainly used, i.e. target code must, and do, call dap_run() before
results from earlier operations are available.
Example, in JTAG mode, the target's dap pointer points to jtag_dap_ops,
implemented by adi_v5_jtag.c, which converts the DAP register accesses to
JTAG scans. Finally, dap_run() calls jtag_execute_queue() to make results
available (the JTAG API has a mandatory queue before operations are pushed
down to the driver, which is completely brain-dead but I won't rant about
that now).
The swd_dap_ops implementation does the same thing but using SWD protocol
operations. Since the SWD protocol was designed specifically to transfer
DAP operation commands, adi_v5_swd.c is a very thin layer, basically just
handling the posted nature of reads.
> However I couldn't think of a useful way to use this layer for
> a performance boost, at least without replacing the lower level
> swd_driver interface with a hardware-specific interface that just
> takes cmsis-dap transfer requests. This seemed like a bad idea to me,
> as the push seems to be towards unifying internal APIs rather than
> creating more HLA-style special cases.
>
However, the CMSIS-DAP is a bit special, as it implements the DAP
operations directly in firmware. It provides DAP access, not SWD nor JTAG
access (well, it does too but let's forget that for a moment) and it can do
that using either JTAG or SWD as the underlying transport, with the same
commands. Basically, the firmware contains the equivalents of both
jtag_dap_ops and swd_dap_ops plus some commands to select between them.
So CMSIS-DAP fits perfectly into the dap_ops layer (after some link
initialization), more so than as an SWD driver I guess. So I don't really
know why the current CMSIS-DAP driver calls into jtag_interface->swd when
it could have cleanly implemented the operations directly. Well, I can
guess why... because all adapter setup logic in OpenOCD goes through the
jtag_interface struct and without that it could (perhaps?) be messy to
select and configure a cmsis-dap adapter.
Too tired to think clearly now but there are multiple other issues that
needs addressing before we can decide how to move forward.
> That all said, I'm new to the openocd codebase
>
Good, then you have a fresh set of eyes and maybe another angle on
things... :)
/Andreas
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
