rocket-chip
rocket-chip copied to clipboard
chipsalliance
vcs arguments not properly ignored by fesvr
A fresh clone of rocket-chip with riscv-tools built from the submodule pointer can not run assembly tests in the vsim directory.
The extra vcs arguments are no longer correctly ignored by fesvr and so a few messages appear:
C0: 0 [0] pc=[af57f623af] W[r 0=0000000000000000][0] R[r14=b815d870b815d870] R[r19=1e75de3d1e75de3d] inst=[000032ad] DASM(000032ad)
./simv-freechips.rocketchip.system-DefaultConfig: invalid option -- 'q'
C0: 1 [0] pc=[af57f623af] W[r 0=0000000000000000][0] R[r14=b815d870b815d870] R[r19=1e75de3d1e75de3d] inst=[000032ad] DASM(000032ad)
...
C0: 456 [0] pc=[000001004c] W[r 0=fffffff7bbd73677][0] R[r 0=0000000000000000] R[r 5=0000000000000003] inst=[10500073] DASM(10500073)
terminate called after throwing an instance of 'std::runtime_error'
what(): could not open +ntb_random_seed_automatic
Recording this issue here for now, I'll probably issue a PR sometime tomorrow, assuming I'm not making a simple mistake.
This is on me. Apologies for breaking this...
I think the current approach is to special case the valid VCS arguments in riscv-fesvr (or this is what is happening for -cm line+cond). However, now that I look at this, I don't think that -cm line+cond will actually parse correctly.
Two options seem apparent to me:
- Special case all VCS options (or find some VCS header which exposes what these are). This will result in a game of whack-a-mole...
- Add some flag that will cause HTIF (
--permissive-parse) to more permissively handle options in the old style
Granted, I'm also open to whether all my PRs that attempt to expose all options directly at the emulator level may be misplaced and permissive parsing should be the way to go by default.
Current options that need to be ignored in vsim/Makefrag:
-q+ntb_random_seed_automatic
Option 1 seems bad because of all the potential options and the tying of the general infrastructure to a specific simulator.
I think option 2 seems very reasonable to me.
As a comment on your first note about -cm I agree that even that might not handled correctly now.
Actually even with a command like this
/simv-freechips.rocketchip.system-DefaultConfig +verbose +max-cycles=1000000 output/rv64ui-p-add
I still get this failure message at the end of the output:
terminate called after throwing an instance of 'std::runtime_error'
what(): could not open +verbose
😢
I've made a strawman permissive PR on fesvr here https://github.com/riscv/riscv-fesvr/pull/41
Is this still an issue? I.e., if I'm getting what(): could not open... when testing #1230 it isn't something I'm doing wrong?
Yeah, this should still be an issue... No resolution as far as I know of, nor have I played around with VCS to try and find a reasonable resolution. (Though I did find a box with VCS.)
The fesvr PR may have been forgotten, too. That's a simple fix that will ignore + args that VCS doesn't understand. Hopefully that's enough until there's a better solution...
Unclear if this is outdated, but I'll aim to reproduce this sometime in the near future
