debug_rom: regenerate for v1.0 GoingAddr/ResumingAddr/ExceptionAddr offsets#1
Open
jahanzebkhalid-10Xe wants to merge 1 commit into
Open
Conversation
…ffsets Fixes pulp-platform#104 (riscv-dbg-vip). 17e912c ("Updated 1.0 debug module") moved dm_mem.sv's flag-write addresses to the v1.0 spec layout: GoingAddr: 0x108 -> 0x104 ResumingAddr: 0x110 -> 0x108 ExceptionAddr: 0x118 -> 0x10C but debug_rom.S was never updated to match, so the hart's debug-mode code kept writing "going" to the old 0x108 offset -- an address dm_mem.sv's FSM no longer watches. going never asserted, and the abstract-command FSM parked in Go forever (abstractcs.busy stuck at 1). Updated the GOING/RESUMING/EXCEPTION defines in debug_rom.S to match, and regenerated debug_rom.sv/debug_rom_one_scratch.sv (+ .h) via `make -C debug_rom` (riscv64-unknown-elf-gcc 15.2.0). Diff is minimal and exactly localized to the changed store-immediate encodings, nothing else. Verified against real Questa CVA6 sim (riscv-dbg-vip's pydebug suite): halt_uvm 8/8 (was stuck at step 04, "Read PC"), csr_access_uvm 4/4, gpr_write_uvm 4/4 -- all previously timed out on the first abstract command. One new, separate, unrelated finding surfaced now that the Program Buffer path is reachable for the first time (progbuf0/1 write/read-back returns 0) -- filed as riscv-dbg-vip#121, not touched here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Collaborator
|
It has some issues so i have added the one I fixed. You can use the updated version Thanks. |
Collaborator
Author
I don't see anything recently updated |
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
2 participants
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.
Summary
Fixes 10x-Engineers/riscv-dbg-vip#104.
17e912c("Updated 1.0 debug module") moveddm_mem.sv's flag-writeaddresses to the v1.0 spec layout:
but
debug_rom.Swas never updated to match, so the hart's debug-mode codekept writing "going" to the old
0x108offset — an addressdm_mem.sv'sFSM no longer watches.
goingnever asserted, and the abstract-command FSMparked in
Goforever (abstractcs.busystuck at 1, confirmed by waveformin the linked issue).
Fix
Updated the
GOING/RESUMING/EXCEPTIONdefines indebug_rom.Sto matchand regenerated
debug_rom.sv/debug_rom_one_scratch.sv(+.h) viamake -C debug_rom(riscv64-unknown-elf-gcc15.2.0). Diff is minimal andexactly localized to the changed store-immediate encodings.
Verification (real Questa, CVA6, via riscv-dbg-vip's pydebug suite)
halt_uvm: 8/8 passed (was stuck forever at "Read PC", the exactabstract command dmi_resp sent when cmderrbusy=0 pulp-platform/riscv-dbg#104 reports)
csr_access_uvm: 4/4 passed (previously also silently blocked)gpr_write_uvm: 4/4 passed (same)Full evidence and waveform analysis: 10x-Engineers/riscv-dbg-vip#104
(see comments).
🤖 Generated with Claude Code