Searched hist:13288 (Results 1 - 13 of 13) sorted by relevance
| /gem5/src/systemc/ext/channel/ | ||
| H A D | sc_signal_in_if.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | sc_signal.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| /gem5/src/systemc/core/ | ||
| H A D | port.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> 13282:d0546737f962 Wed Oct 03 19:16:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Add an sc_gem5::Port destructor. This destructor just removes the port from the list of all ports. Change-Id: I809b529540c2946d20aeb8d64467d77dc94a7a96 Reviewed-on: https://gem5-review.googlesource.com/c/13288 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | port.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | sensitivity.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | sensitivity.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | event.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | sc_spawn.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | event.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | process.hh | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | sc_module.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| H A D | process.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
| /gem5/src/systemc/channel/ | ||
| H A D | sc_signal.cc | 13288:f1c04129f709 Thu Oct 04 17:59:00 EDT 2018 Gabe Black <gabeblack@google.com> 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> |
Completed in 73 milliseconds