-
Notifications
You must be signed in to change notification settings - Fork 58
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
Raise exception in LSU when ROB is drained #108
Raise exception in LSU when ROB is drained #108
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Function name does not follow style guide
bc71fc3
to
44d9a9e
Compare
44d9a9e
to
a385d57
Compare
My bad just fixed it |
Co-authored-by: Knute Lingaard <[email protected]> Signed-off-by: Suraj Shirvankar <[email protected]>
Co-authored-by: Knute Lingaard <[email protected]> Signed-off-by: Suraj Shirvankar <[email protected]>
733a886
to
a738bbb
Compare
I pushed changes to this PR to origin/lsu_drained. Please pull those changes into your fork. |
Thanks Knute |
At your earliest convenience, @h0lyalg0rithm can you update this branch (resolve conflicts)? |
@klingaard I synced it up with master |
This PR adds a notification from ROB to the entire simulation that the ROB is about to or is expecting simulation to correctly terminate. If a unit listens for that notification, it can use that information to determine if simulation ended improperly, meaning, it might still have work to do, but didn't expect simulation to stop. An example of how this can happen: a unit is NOT scheduling an event to do work (a bug) because of a missed path to "wake" it up. If the sparta::Scheduler ends simulation because it has no events to run, the unit will not receive the end-of-simulation notification from the ROB and can throw an exception in this case. --------- Signed-off-by: Suraj Shirvankar <[email protected]> Co-authored-by: Knute Lingaard <[email protected]>
Based on the discussion in #90