riscv-openocd
riscv-openocd copied to clipboard
riscv
batch: Not retrieving DR value when writing to DMI
Indicate to the JTAG driver that it does not need to read and return the DR register value after scanning the JTAG chain.
riscv_batch_run(), calls jtag_add_dr_scan() to schedule a DR scan operation. Eventually, this will result in the JTAG driver performing a JTAG scan to write to or read from DR. The decision on whether to write to and/or read from DR register is determined by the second parameter to jtag_add_dr_scan(), i.e. a "struct scan_field". Of particular interest here is if batch->fields[i]->in_value is not NULL, the JTAG developer must return the DR value collected from the JTAG scan operation.
When creating the DR scan operation instruction with riscv_batch_add_dmi_write(), batch->fields[i]->in_value points to a location in batch->data_in buffer, meaning batch->field[i]->in_value is not NULL, and the JTAG developer must therefore read and return the DR value collected. The returning of the DR value is redundant in a write operation.
This patch set batch->fields[i]->in_value to NULL to indicate the DR value need not be returned. This allows the JTAG developer to optimize away any code associated with returning the DR value.
Normally, the extra work to return the DR value is negligible. However, in one usecase it introduces significant delays In this use case a JTAG driver forwards all JTAG scan to a server on a network. If the server has to return the DR value, it has to perform the JTAG scan before replying to the JTAG driver, and only then the JTAG driver can send the next JTAG scan operation. However, if there is no need to return the DR value, the server can acknowledge the JTAG operation request immediately,thus signalling to the JTAG driver that it is free to send the next JTAG scan operation. At the same time of receiving the second JTAG operation the server will process the original JTAG scan. This saves time and mitigates network delay. Also, not having to include the DR value in resulting in smaller reply packet from server to JTAG driver and save on network traffic.
Signed-off-by: Ooi, Cinly [email protected]
This is a continuation of PR #619 . I had some problem with branch management on the forked directory for the original PR. Sorry.
Yet to complete conversation from #619 (https://github.com/riscv/riscv-openocd/pull/619#issuecomment-856985825), @timsifive
So it sounds like the speedup is significant for your use-case. It might also help with remote bitbang, which I use for testing, so I'd love a speedup there also.
Are you able to run the tests from https://github.com/riscv/riscv-tests/tree/master/debug? #563 is trying to automate that process, but until we're there it's best to run those tests manually.
This change breaks MemorySampleMixed which exercises sample_memory_bus_v1(). It's a good idea, but we need a flag to indicate whether the data will be read or not. That flag can be set on at least memory write operations, so there will still be a significant speedup for the common cases.
If I understand correctly, the change from this merge request was merged (in a modified form) via #768.
Can this one be closed, then?
