Searched hist:13260 (Results 1 - 13 of 13) sorted by relevance
/gem5/src/systemc/ext/core/ | ||
H A D | sc_spawn.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
/gem5/src/systemc/core/ | ||
H A D | port.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | port.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | sensitivity.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | sensitivity.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | event.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | sc_spawn.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | event.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | process.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | sc_module.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | process.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | scheduler.hh | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
H A D | scheduler.cc | diff 13260:4d18f1d20093 Wed Sep 26 06:20:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement signal based resets. The implementation is based on sc_event sensitivities. Also of note is that the way reset works in the Accellera implementation isn't consistent with the spec. That says that wait(int n) is supposed to be equivalent to calling wait() n times, assuming n is greater than 0. Instead, Accellera stores that count and then doesn't wake up the process until the count is 0, decrementing it otherwise. That means that when the process is in reset, it won't actually reset for those intermediate wait()s which it would if wait() was called repeatedly. Also, oddly, when a reset becomes asserted, it will clear the count to 0 explicitly. That may have been an attempt to make the behavior of wait(int n) match the spec, but it doesn't handle cases where the reset is already set when wait(int n) is called. Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b Reviewed-on: https://gem5-review.googlesource.com/c/13186 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
Completed in 82 milliseconds