Skip to content

[dv] Keep checking after a mid-test reset - #2514

Open
kulan-pal wants to merge 3 commits into
lowRISC:masterfrom
kulan-pal:dv/mid-test-reset
Open

kulan-pal wants to merge 3 commits into
lowRISC:masterfrom
kulan-pal:dv/mid-test-reset

Conversation

@kulan-pal

Copy link
Copy Markdown
Contributor
Co-simulation matched          0 instructions

After a mid-test reset, riscv_reset_test can report this and pass. The scoreboard waits for a reset release that already happened, and the binary can be loaded into the old Spike instance.

Restart the checkers after re-creating Spike, clear the instruction-side error state, and wait for the new instance before loading memory. Log each instance's matched count before replacing it.

The irq driver also waits for another reset assertion inside its reset handler. Drive the idle values at once and resume requests after reset release.

The testbench memory kept the stores from before the reset, while the new Spike starts from the binary alone. Clear it before the binary is reloaded, so memory outside the binary no longer survives a mid-test reset.

Two new directed tests reset the core once, from a checkpoint in the program. One then raises an interrupt that the rebooted program waits for. The other checks that a store from before the reset is gone. Both fail on master with the tests added, and with their fix removed. Suppressing the reset also makes them fail.

Tested on VCS. The reset regression passes on opentitan, and I matched per-boot cosim counts against instruction traces. Both new tests pass on opentitan and maxperf-pmp-bmbalanced. small skips them because it has no PMP. Arithmetic, memory-error and PC-integrity traces match master at one seed each.

No prerequisite PRs. #2513 adds directed tests at the same place in gen_testlist.py, so whichever merges second needs a small rebase.

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.

After a mid-test reset the cosim scoreboard waited for a reset release
that had already happened, so nothing was checked for the rest of the
test. The base test could also load the binary into the old Spike.
Restart the checkers as soon as Spike is re-created, clear the
instruction-side error state, and make the base test wait for the new
Spike before loading memory. Log each Spike's matched count at reset.

Signed-off-by: Kulan Palanichamy <kulan.palanichamy@opentitan.org>
After a mid-test reset, the irq driver waits for another reset
assertion before driving its idle values, so interrupts requested
after the reset stay blocked. Drive the idle values while reset is
asserted, and wait for release before taking new requests. Add a
directed test that resets the core and fails if a later interrupt
does not reach it.

Signed-off-by: Kulan Palanichamy <kulan.palanichamy@opentitan.org>
A mid-test reset re-creates Spike and reloads the binary, but the
testbench memory outside the binary kept the old run's stores. A
rebooted program that loads such a word sees different data on the two
sides. Clear the memory model before reloading the binary, and discard
queued test-done and signature entries at reset. Add a directed test
that fails if the rebooted program reads a store from before the reset.

Signed-off-by: Kulan Palanichamy <kulan.palanichamy@opentitan.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant