Searched hist:13210 (Results 1 - 4 of 4) sorted by relevance
| /gem5/src/systemc/ext/core/ | ||
| H A D | sc_sensitive.hh | diff 13210:8f6d757c46dc Sat Sep 15 00:28:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Handle nonstandard cthread sensitivities. Accellera allows some non-standard values in the second position of the SC_CTHREAD macro. Do that as well, with the same special handling which automatically selects the positive edge of boolean ports/interfaces. Change-Id: I79594980898a17afc30fea6f77384589cbc3c250 Reviewed-on: https://gem5-review.googlesource.com/c/12809 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sc_module.hh | diff 13210:8f6d757c46dc Sat Sep 15 00:28:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Handle nonstandard cthread sensitivities. Accellera allows some non-standard values in the second position of the SC_CTHREAD macro. Do that as well, with the same special handling which automatically selects the positive edge of boolean ports/interfaces. Change-Id: I79594980898a17afc30fea6f77384589cbc3c250 Reviewed-on: https://gem5-review.googlesource.com/c/12809 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| /gem5/src/systemc/core/ | ||
| H A D | sc_sensitive.cc | diff 13210:8f6d757c46dc Sat Sep 15 00:28:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Handle nonstandard cthread sensitivities. Accellera allows some non-standard values in the second position of the SC_CTHREAD macro. Do that as well, with the same special handling which automatically selects the positive edge of boolean ports/interfaces. Change-Id: I79594980898a17afc30fea6f77384589cbc3c250 Reviewed-on: https://gem5-review.googlesource.com/c/12809 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| /gem5/src/mem/cache/tags/ | ||
| H A D | fa_lru.cc | diff 13165:d52afbf4cdfe Thu Oct 04 04:53:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Fix FALRU hash invalidation The block was being invalidated before the hash could erase its entry, therefore it was using invalid values (tag was being assigned MaxAddr and the secure bit was reset). This change reorders the calls, so that the appropriate hash entry is erased. Change-Id: I161463df0f8f5220179bc68d7be12051e5390d01 Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br> Reviewed-on: https://gem5-review.googlesource.com/c/13210 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
Completed in 31 milliseconds