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

Adding schedule_next_max_ticks to Simulator #927

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

mahyarsamani
Copy link
Contributor

This commit extends the Simulator class to allow the user to set a max_tick with Simulator::run which will be the total sum of simulated ticks (through exiting due to exit events and re-enterin), and schedule next_max_ticks which allows the user to schedule simulation for next_max_ticks ticks from curTick.

Change-Id: I17334ac74d0a0c540cb67199f02ccdbc1209be32

This commit extends the Simulator class to allow the user to
set a max_tick with Simulator::run which will be the total sum
of simulated ticks (through exiting due to exit events and
re-enterin), and schedule next_max_ticks which allows the user
to schedule simulation for next_max_ticks ticks from curTick.

Change-Id: I17334ac74d0a0c540cb67199f02ccdbc1209be32
Comment on lines +591 to +594
:param max_ticks: The maximum number of ticks to simulate overall.
If this ``max_ticks`` value is met, a ``MAX_TICK``
exit event is received, if another simulation exit
event is met the tick count is reset. This is the
**maximum number of ticks per simulation run**.
event is met the tick count is reset.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this changing the behavior? If so, it concerns me. Either way, the description still isn't clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's changing the behavior. I am not hellbent on getting this merged, if you don't see any value in this I can close this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with changing behavior is that there are many scripts out there that expect the old behavior. We could add a new parameter which has this behavior and deprecate max_ticks, but we can't just break people's current scripts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I can make that change.

@ivanaamit ivanaamit added the python gem5's Python SimObject wrapping and infrastructure label Mar 14, 2024
@mahyarsamani mahyarsamani marked this pull request as draft March 14, 2024 22:48
@BobbyRBruce
Copy link
Member

I think it's fine to add this feature but i don't think you should interfere with max_ticks current behavior. Remember we want to extent, not modify, when adding a new feature.

I think we over-use max_ticks as, for a while, it was the more straight-forward way to schedule an exit based on ticks. Last year I added more functions to the m5.simulate module: 8479a69. I believe the scheduleTickExitAbsolute function there is what you want to use. Though the part you need to implement (and for which I'd welcome a PR), is extending the stdlib's Simulator API to utilize these functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
python gem5's Python SimObject wrapping and infrastructure
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants