No need for busy delays after a DMI NOP.

[en-sc]

When running a NOP, there is no need to add extra RTI cycles -- according to the spec it should not cause a DMI busy status. See [6.1.5. Debug Module Interface Access (dmi, at 0x11)], op field description:

0 (nop): Ignore data and address. Don’t send anything over the DMI during Update-DR. This operation should never affect DMI busy or error status.
The address and data reported in the following CaptureDR are undefined.

Therefore, instead of:

Debug: 147 2 batch.c:291 riscv_batch_run_from(): [riscv.cpu] Running batch of scans [0, 2)
Debug: 148 3 batch.c:255 log_batch(): 41b w 00000001 @10 -> + 00000000 @00; 3i
Debug: 149 3 batch.c:199 log_dmi_decoded(): write: dmcontrol=1 {dmactive=active}
Debug: 150 3 batch.c:255 log_batch(): 41b - 00000000 @00 -> + 00000001 @10; 3i

the sequence of:

Debug: 147 2 batch.c:291 riscv_batch_run_from(): [riscv.cpu] Running batch of scans [0, 2)
Debug: 148 3 batch.c:255 log_batch(): 41b w 00000001 @10 -> + 00000000 @00; 3i
Debug: 149 3 batch.c:199 log_dmi_decoded(): write: dmcontrol=1 {dmactive=active}
Debug: 150 3 batch.c:255 log_batch(): 41b - 00000000 @00 -> + 00000001 @10; 0i

can be issued.

This will result in a speed-up of rti / ((5 + 32 + 2 + abits + rti) * 2) (with abits = 7 and rti = 5 it's about 5%).

However, this should be done with caution, considering:

• An abstract command can be running.
• The delay derivation algorithm can require adjustments.

[Biancaa-R]

@en-sc I had added a simple fix ,but what abstract command should I look into ?

[en-sc]

@Biancaa-R, thanks! I've answered in the PR to keep the discussion in one place.