Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After a mid-test reset,
riscv_reset_testcan 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 onopentitanandmaxperf-pmp-bmbalanced.smallskips 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.