Feature: implement ADIv5 SWD Posted reads #2265

ALTracer commented 2026年05月25日 04:25:03 +02:00

Detailed description

• This is a new feature in core ADIv5 layer code.
• The existing problem is only 50% efficient utilization of MEM-AP during long block reads (slow read speed).
• The PR solves it by providing a new function which relies on "posted" reads.

Every AP Read DRW initiates a read transaction internally but provides in its RDATA phase the value of previous (completed) transaction. BMD works around this by issuing an additional DP Read RDBUFF, which returns in its RDATA phase the value of current transaction (and lets it complete; or enters a DP WAIT loop).
Other adapters, like and including the reference implementation https://github.com/ARM-software/CMSIS-DAP , have complicated code in DAP_SWD_Transfer() methods which staggers the reads to achieve high performance.

I saw a similarity to #2225 (RISC-V Progbuf-based memory access with abstractauto) and #1946 (SPI pipelining for byte in flight), and tried to rewrite the internal loop in adiv5_mem_read_bytes(). The setup begins identically, with AP Write CSW, AP Write TAR, but then I discard one AP Read DRW and allow the loop to capture data as usual, for N-1 transactions; the final "stride" is taken from DP Read RDBUFF, to avoid DUT access out-of-bounds. Additionally, as the AutoIncr range check will still hit inside the loop, I've moved its condition by one stride and inserted the required pipeline terminations -- DP read RDBUFF of last stride of 1 KiB and dummy AP read DRW. The check for (len > 16U) prevents use of this new code path in majority of "single MMIO register read" callsites, like flash driver code and ident/probe functions.

Tested on blackpill-f411ce against Cortex-M4F at multiple SWCLK frequency settings, best compare-sections speed report increased from 138 to 261 KiB/s, almost double. BMDA benefits from this indirectly, too.
Ideally testing against some Cortex-M0+ or whatever MINDP is required. JTAG-DP transport not considered, as jtagtap.c bitbanging is definitely slower for BMF.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * This is a new feature in core ADIv5 layer code. * The existing problem is only 50% efficient utilization of MEM-AP during long block reads (slow read speed). * The PR solves it by providing a new function which relies on "posted" reads. Every AP Read DRW initiates a read transaction internally but provides in its RDATA phase the value of previous (completed) transaction. BMD works around this by issuing an additional DP Read RDBUFF, which returns in its RDATA phase the value of current transaction (and lets it complete; or enters a DP WAIT loop). Other adapters, like and including the reference implementation https://github.com/ARM-software/CMSIS-DAP , have complicated code in DAP_SWD_Transfer() methods which staggers the reads to achieve high performance. I saw a similarity to #2225 (RISC-V Progbuf-based memory access with abstractauto) and #1946 (SPI pipelining for byte in flight), and tried to rewrite the internal loop in `adiv5_mem_read_bytes()`. The setup begins identically, with AP Write CSW, AP Write TAR, but then I discard one AP Read DRW and allow the loop to capture data as usual, for N-1 transactions; the final "stride" is taken from DP Read RDBUFF, to avoid DUT access out-of-bounds. Additionally, as the AutoIncr range check will still hit inside the loop, I've moved its condition by one stride and inserted the required pipeline terminations -- DP read RDBUFF of last stride of 1 KiB and dummy AP read DRW. The check for (len > 16U) prevents use of this new code path in majority of "single MMIO register read" callsites, like flash driver code and ident/probe functions. Tested on `blackpill-f411ce` against Cortex-M4F at multiple SWCLK frequency settings, best `compare-sections` speed report increased from 138 to 261 KiB/s, almost double. BMDA benefits from this indirectly, too. Ideally testing against some Cortex-M0+ or whatever MINDP is required. JTAG-DP transport not considered, as jtagtap.c bitbanging is definitely slower for BMF. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [ ] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

You are not authorized to merge this pull request.