[lionelZhaowy]

The VIP starts a new scan directly after each DMI write. With corrected pending-write Capture status from riscv-dbg #214, the next Capture can set sticky BUSY before the previous CDC response returns. Add eight TCK cycles with the existing driver method after each write.

This is a compatibility change for that DTM correction. The current locked DTM control passes; this PR does not claim a standalone current-main failure or upgrade the dependency.

Validation at Cheshire main 6c6dd5e834347f72c7be31cd6c41021ec293c5b9 used its exact locked riscv-dbg/common_cells/tech versions. A public test extracts the actual complete VIP task and runs it through the actual JTAG driver, DTM, TAP and CDC. A standard DMI endpoint records all 32 writes and returns SUCCESS after 0/4/12 system cycles. System period 5 ns, TCK 20 ns.

• Current DTM + original VIP: all three runs have 32 writes, 32 responses, zero errors.
• Strict Capture DTM + original VIP: all three have 1 write, 1 response, 34 errors.
• Strict DTM + this VIP: all three have 32 writes, 32 responses, zero errors.
• Current DTM + this VIP: all three have 32 writes, 32 responses, zero errors.
• Each run checks all payloads, counts and final DTM status, reaches normal finish and keeps assertions enabled. VCS W-2024.09-SP1 uses finite HDL/wall limits. This task change does not need synthesis.

The exact locked commits, related DTM commit, test adapters and commands are in target/sim/test/JTAG_WRITE_WAIT.md. Eight cycles cover the tested CDC/clock/endpoint limits. This does not implement general response polling for arbitrary endpoint backpressure. The test does not elaborate the full SoC VIP and includes no EEPROM model.

AI assistance: OpenAI Codex assisted implementation, test and validation. A separate AI review checked the change and actual results. This was not a human review.