[dv] Stop the icache core driver before a reset

[kulan-pal]

ibex_icache_stress_all_with_reset fails on master on about 2 % of random seeds:

UVM_ERROR @ 186310000 ps: (ibex_icache_core_protocol_checker.sv:44) [ASSERT FAILED] NoReqInReset

The checker is right. The testbench leaves req high when reset is asserted.

To reset in the middle of a test, the combo sequence kills the running sequence and calls reset_ifs() to lower
req. The next sequence then applies reset. Killing a sequence does not stop the item the core driver is working
on. That item can raise req again after reset_ifs() has lowered it.

Now reset_ifs() triggers an event instead. The driver runs each item next to a process that waits
for that event. When the event comes, the driver stops the item with disable fork and clears the control signals.
The event and the item's last drive can happen at the same simulation time, in either order. So the driver clears
the signals when the event fires and again once the item has stopped.

Lowering only req could leave ready high. That violates NoReadyWithoutReq. The protocol checker is unchanged.

I tested with dvsim on VCS with the default icache bench parameters. On 300 random seeds, 7 fail on master and none
on this branch. The change alters the driver's random draws, so a seed gives different stimulus on each.
A local tree that forces the item to drive after the first clear fails without the second clear and passes with it.
Every icache test also passes on 20 seeds. I have not run Xcelium.

Unrelated to this change, a few seeds fail TagHitKnown on master. I have not found the cause yet.

Dependencies: none.

AI disclosure (CLA §9): written with help from Claude Code and reviewed with OpenAI Codex; I have reviewed and understood every change and take full responsibility for it.

[bonnie-banks123]

This looks correct: cancelling the driver’s active transaction addresses the reset race. I also ran 50 VCS seeds of ibex_icache_stress_all_with_reset at this head; all passed.