systemc: Change how signal based resets work.

The previous implementation used the value changed event to track when
signals changed value, but there were a couple problems with this
approach. First, this piggybacked on the sensitivity mechanism in some
ways, but diverged in others. The sensitivity didn't notify a process
when it was satisfied like other sensitivity types would, and it also
ignored whether the process was disabled.

Second, the value_changed_event is notified by a signal instance as a
delta notification, but reset signals are supposed to act immediately.
That means they should happen before all delta notifications, or in
other words all delta notifications should see the reset status of a
given process. That's particularly important in the case of wait(int n)
where setting the reset clears the reset count, and the count is
checked when determining whether or not to wake up a process when its
sensitivity is satisfied, potentially by a delta notification.

Third, by removing the middle man and not trying to repurpose the
sensitivity mechanism, the code gets simpler and easier to understand.

Change-Id: I0d05d11437291d368b060f6a45a207813615f113
Reviewed-on: https://gem5-review.googlesource.com/c/13294
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

1 files changed, 14 insertions, 1 deletions

diff --git a/src/systemc/channel/sc_signal.cc b/src/systemc/channel/sc_signal.cc
index 702f20901..14ee8a6e4 100644
--- a/src/systemc/channel/sc_signal.cc
+++ b/src/systemc/channel/sc_signal.cc
@@ -165,11 +165,24 @@ ScSignalBaseBinary::posedge() const
 {
     return _posStamp == getChangeStamp();
 }
-bool
 
+bool
 ScSignalBaseBinary::negedge() const
 {
     return _negStamp == getChangeStamp();
 }
 
+void
+ScSignalBaseBinary::_signalReset(sc_gem5::Reset *r)
+{
+    r->update();
+}
+
+void
+ScSignalBaseBinary::_signalReset()
+{
+    for (auto r: _resets)
+        _signalReset(r);
+}
+
 } // namespace sc_gem5