Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add default cfg_t and debug_module_config_t constructor to libriscv #1526

Merged
merged 5 commits into from
Dec 11, 2023

Conversation

jerryz123
Copy link
Collaborator

Adding additional config options to cfg_t has, up to now, required propagating the flag to all code which instantiates cfg_t, including projects which use Spike as a library.

Now, the default constructor for cfg_t will construct the default spike parameters.

This should be merged after #1522 to avoid merge conflicts.

@jerryz123 jerryz123 changed the title Move default cfg_t construction to libriscv Add default cfg_t constructor to libriscv Dec 7, 2023
@jerryz123 jerryz123 changed the title Add default cfg_t constructor to libriscv Add default cfg_t and debug_module_config_t constructor to libriscv Dec 7, 2023
@jerryz123 jerryz123 force-pushed the default_cfg branch 4 times, most recently from 6d33293 to 4c99a5e Compare December 8, 2023 04:14
@aswaterman
Copy link
Collaborator

I didn't look at the code, but the rationale checks out. Probably worth pinging this thread after #1522 is merged.

@scottj97
Copy link
Contributor

scottj97 commented Dec 8, 2023

I'm not sure I understand the removal of cfg_arg_t. (There's only one place left that uses it after this change.)

@rswarbrick introduced this in #946 to keep track of which config vars had been overridden from their initial values (e.g. via command-line). Do we not need that capability anymore?

@jerryz123
Copy link
Collaborator Author

@rswarbrick introduced this in #946 to keep track of which config vars had been overridden from their initial values (e.g. via command-line). Do we not need that capability anymore?

That capability was never used once the cfg_t was passed into sim_t. I believe some other code in spike main uses the cfg_arg_t ... the explicit_hartids stuff.

My understanding is that the overridden API in cfg_t was added to eventually support a use case where the user provides cmdline args, and a DTS/DTB, and spike would implement some code to check that the DTS/DTB is consistent with the command line args (#938). However, none of the consistency checking has been implemented. I'm not actually sure this "consistency check" approach makes sense... do we need to support the use case of providing both DTB and cmdline args which affect the same system configurations?

@jerryz123
Copy link
Collaborator Author

@aswaterman @scottj97 This is ready now.

@aswaterman
Copy link
Collaborator

Still OK with me; let's wait for @scottj97

@scottj97
Copy link
Contributor

scottj97 commented Dec 11, 2023 via email

@jerryz123 jerryz123 merged commit f1e0be8 into master Dec 11, 2023
3 checks passed
@jerryz123 jerryz123 deleted the default_cfg branch December 11, 2023 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants