Add support for per-hart start PCs (--pcs)#2199
Add support for per-hart start PCs (--pcs)#2199nabudahab wants to merge 23 commits intoriscv-software-src:masterfrom
Conversation
Currently, the --pc flag sets the entry point for all processors globally, or relies on the ELF entry point. This is insufficient for asymmetric multi-processing (AMP) setups or bare-metal RTL verification where different harts must begin execution at distinct physical addresses (e.g., Hart 0 at 0x2000, Hart 1 at 0x4000). This patch adds the --pc-harts=<H:A,...> argument, allowing users to explicitly override the start PC for specific hart IDs.
|
Hello, can someone please review the code so that the CI checks can run? Thanks. I'm always happy to address feedback. |
aswaterman
left a comment
aswaterman
left a comment
There was a problem hiding this comment.
Can I get a second review from someone else, perhaps @jerryz123?
|
@jerryz123 Gentle nudge as it's been a week since the last update. Let me know if you have any thoughts on the implementation or if there's anything you'd like me to address. |
Signed-off-by: Natheir Abu-Dahab <20204834+nabudahab@users.noreply.github.com>
nabudahab
changed the title
|
@aswaterman I realized I hadn’t actually applied the spacing/style suggestions earlier — that’s fixed now and pushed. Could you take another quick look / re-approve when you get a chance? @jerryz123 (or any maintainer) GitHub Actions for this PR is still awaiting maintainer approval to run CI. Could someone approve the workflow runs so checks can execute? Once CI is green, this should be ready to merge. |
jerryz123
left a comment
jerryz123
left a comment
There was a problem hiding this comment.
Whoops, sorry. Need to fix my github notification filtering.
Co-authored-by: Jerry Zhao <qwertyuiopghb@gmail.com> Signed-off-by: Natheir Abu-Dahab <20204834+nabudahab@users.noreply.github.com>
Co-authored-by: Jerry Zhao <qwertyuiopghb@gmail.com> Signed-off-by: Natheir Abu-Dahab <20204834+nabudahab@users.noreply.github.com>
Fix implemented as suggested by @jerryz123 Signed-off-by: Natheir Abu-Dahab <20204834+nabudahab@users.noreply.github.com>
Removed unnecessary blank lines for cleaner code. Signed-off-by: Natheir Abu-Dahab <20204834+nabudahab@users.noreply.github.com>
|
@jerryz123 I've implemented your suggested changes and tested --pcs with --pc. The interaction I defined was that -pc sets a global override PC and --pcs can set overrides on top of that for individual harts, --pcs also works without --pc with the unspecified harts simply starting at the PC defined by sim_t::get_entry_point(). Please let me know if there's anything else of concern or if this is ready for merge. Can someone approve the workflows again? |
| const int reset_vec_size = 8; | ||
|
|
||
| reg_t start_pc = cfg->start_pc.value_or(get_entry_point()); | ||
| reg_t start_pc = cfg->start_pc.get(0).value_or(get_entry_point()); |
There was a problem hiding this comment.
Pipeline fails. It seems to me that set_global should also set pc for hart 0 in order for this to work
There was a problem hiding this comment.
After some though I was wrong here. The problem is actually that you set pc in sim_t::proc_reset, overriding default ROM start address
4 participants
Summary
This PR introduces a new command-line argument
--pc-hartsto allow specifying different start addresses (PCs) for different harts. This feature is particularly valuable for RTL co-simulation workflows, where the simulator must exactly match the behavior of the RTL design. In these scenarios, the Boot ROM is often bypassed or disabled, and each hart is released from reset at a specific entry point defined by the hardware configuration.Problem
Currently, Spike defaults to setting the PC for all harts to the ELF entry point or the address specified by
--pc.However, in many bare-metal verification environments and Asymmetric Multi-Processing (AMP) configurations, harts often have distinct reset vectors. For example, a dual-core system might require:
0x20000x4000Achieving this previously required modifying the C++ source code or relying on a complex bootloader/bootrom to diverge the harts.
Solution
I have added the
--pc-hartsflag which parses a comma-separated list ofHartID:Addresspairs.Usage Example:
spike -p2 --pc-harts=0:0x0,1:0x200 my_program.elfImplementation Details
--pc-hartsinspike_main/spike.cc.processor_tstates after simulation initialization but before the run loop begins.Testing
Verified using a dual-core bare-metal assembly test (with the boot ROM disabled) where Hart 0 and Hart 1 must execute distinct code sections located at
0x0and0x200respectively. Confirmed that both harts start at the correct overridden addresses.