[dv,tools] Add Xcelium reinvoke simulator - #31137
Open
martin-velay wants to merge 1 commit into
Open
Conversation
Contributor
|
I think there's a danger we'll end up writing a competitor to a bit of dvsim here. Is there any way this could have been done by dvsim itself? |
Contributor
Author
Some changes cannot be part of DVSim, but I agree that some pieces should probably better go in there. I'll try to fix this @rswarbrick: it should be addressed now (see my latest push and DVSim change) |
Contributor
Author
|
This PR depends on lowRISC/dvsim#256 |
Until now a GUI run (--gui or --gui-debug) had to be closed and relaunched through dvsim for an RTL or DV fix to be picked up, which lost the waveform, the probes and every breakpoint that had been set. The run step of an Xcelium GUI run now compiles and elaborates for itself instead of loading the snapshot the build step produced. That makes it a single-step xrun invocation, so "Reinvoke Simulator..." in SimVision recompiles the changed design units and reloads the design into the running session. Three things follow from that. FuseSoC no longer exports the sources into the build tree for Xcelium, so that SimVision recompiles the real files and batch and GUI builds can share one build directory. Every Xcelium include path therefore names the source tree. And every build records its options in build_opts.f, which the GUI run reads back, so that the run compiles the design the build described. One-time action for anyone with an existing Xcelium scratch tree: the first build after this change fails with "No rule to make target .../fusesoc-work/src/<core>/<file>.c". Xcelium caches DPI dependency files under <build_dir>/xcelium.d with absolute source paths and does not regenerate them when those paths change. Delete the scratch tree once, or rerun dvsim with --purge, and it does not recur. Signed-off-by: martin-velay <mvelay@lowrisc.org>
martin-velay
force-pushed
the
xcelium_reinvoke_simulator
branch
from
August 31, 2026 14:34
94ba26c to
68d6de1
Compare
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.
Until now a GUI run (--gui or --gui-debug) had to be closed and relaunched through dvsim for an RTL or DV fix to be picked up, which lost the waveform, the probes and every breakpoint that had been set.
The run step of an Xcelium GUI run now compiles and elaborates for itself instead of loading the snapshot the build step produced. That makes it a single-step xrun invocation, so "Reinvoke Simulator..." in SimVision recompiles the changed design units and reloads the design into the running session.
Three things follow from that. FuseSoC no longer exports the sources into the build tree for Xcelium, so that SimVision recompiles the real files and batch and GUI builds can share one build directory. Every Xcelium include path therefore names the source tree. And every build records its options in build_opts.f, which the GUI run reads back, so that the run compiles the design the build described.
One-time action for anyone with an existing Xcelium scratch tree: the first build after this change fails with "No rule to make target .../fusesoc-work/src//.c". Xcelium caches DPI dependency files under <build_dir>/xcelium.d with absolute source paths and does not regenerate them when those paths change. Delete the scratch tree once, or rerun dvsim with --purge, and it does not recur.