Searched hist:10722 (Results 1 - 8 of 8) sorted by relevance
/gem5/src/mem/ | ||
H A D | qport.hh | 10722:886d2458e0d6 Mon Mar 02 04:00:00 EST 2015 Stephan Diestelhorst <stephan.diestelhorst@arm.com> mem: Add option to force in-order insertion in PacketQueue By default, the packet queue is ordered by the ticks of the to-be-sent packages. With the recent modifications of packages sinking their header time when their resposne leaves the caches, there could be cases of MSHR targets being allocated and ordered A, B, but their responses being sent out in the order B,A. This led to inconsistencies in bus traffic, in particular the snoop filter observing first a ReadExResp and later a ReadRespWithInv. Logically, these were ordered the other way around behind the MSHR, but due to the timing adjustments when inserting into the PacketQueue, they were sent out in the wrong order on the bus, confusing the snoop filter. This patch adds a flag (off by default) such that these special cases can request in-order insertion into the packet queue, which might offset timing slighty. This is expected to occur rarely and not affect timing results. |
H A D | packet_queue.cc | 10722:886d2458e0d6 Mon Mar 02 04:00:00 EST 2015 Stephan Diestelhorst <stephan.diestelhorst@arm.com> mem: Add option to force in-order insertion in PacketQueue By default, the packet queue is ordered by the ticks of the to-be-sent packages. With the recent modifications of packages sinking their header time when their resposne leaves the caches, there could be cases of MSHR targets being allocated and ordered A, B, but their responses being sent out in the order B,A. This led to inconsistencies in bus traffic, in particular the snoop filter observing first a ReadExResp and later a ReadRespWithInv. Logically, these were ordered the other way around behind the MSHR, but due to the timing adjustments when inserting into the PacketQueue, they were sent out in the wrong order on the bus, confusing the snoop filter. This patch adds a flag (off by default) such that these special cases can request in-order insertion into the packet queue, which might offset timing slighty. This is expected to occur rarely and not affect timing results. |
H A D | packet_queue.hh | 10722:886d2458e0d6 Mon Mar 02 04:00:00 EST 2015 Stephan Diestelhorst <stephan.diestelhorst@arm.com> mem: Add option to force in-order insertion in PacketQueue By default, the packet queue is ordered by the ticks of the to-be-sent packages. With the recent modifications of packages sinking their header time when their resposne leaves the caches, there could be cases of MSHR targets being allocated and ordered A, B, but their responses being sent out in the order B,A. This led to inconsistencies in bus traffic, in particular the snoop filter observing first a ReadExResp and later a ReadRespWithInv. Logically, these were ordered the other way around behind the MSHR, but due to the timing adjustments when inserting into the PacketQueue, they were sent out in the wrong order on the bus, confusing the snoop filter. This patch adds a flag (off by default) such that these special cases can request in-order insertion into the packet queue, which might offset timing slighty. This is expected to occur rarely and not affect timing results. |
/gem5/src/mem/cache/tags/ | ||
H A D | base_set_assoc.hh | 12746:0d0c266663d4 Sat Jun 02 09:04:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Use secure bit in findVictim Sector caches must know if there was a sector hit in order to decide whether a victim's sector must be fully evicted to give place to a new sector or not. In order to do so it needs the tag and secure information. Change-Id: Ib554169e25fa131d6bf986561f7970b787c56874 Reviewed-on: https://gem5-review.googlesource.com/10722 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
H A D | base.hh | 12746:0d0c266663d4 Sat Jun 02 09:04:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Use secure bit in findVictim Sector caches must know if there was a sector hit in order to decide whether a victim's sector must be fully evicted to give place to a new sector or not. In order to do so it needs the tag and secure information. Change-Id: Ib554169e25fa131d6bf986561f7970b787c56874 Reviewed-on: https://gem5-review.googlesource.com/10722 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
H A D | fa_lru.hh | 12746:0d0c266663d4 Sat Jun 02 09:04:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Use secure bit in findVictim Sector caches must know if there was a sector hit in order to decide whether a victim's sector must be fully evicted to give place to a new sector or not. In order to do so it needs the tag and secure information. Change-Id: Ib554169e25fa131d6bf986561f7970b787c56874 Reviewed-on: https://gem5-review.googlesource.com/10722 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
H A D | fa_lru.cc | 12746:0d0c266663d4 Sat Jun 02 09:04:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Use secure bit in findVictim Sector caches must know if there was a sector hit in order to decide whether a victim's sector must be fully evicted to give place to a new sector or not. In order to do so it needs the tag and secure information. Change-Id: Ib554169e25fa131d6bf986561f7970b787c56874 Reviewed-on: https://gem5-review.googlesource.com/10722 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
/gem5/src/mem/cache/ | ||
H A D | base.cc | 12746:0d0c266663d4 Sat Jun 02 09:04:00 EDT 2018 Daniel R. Carvalho <odanrc@yahoo.com.br> mem-cache: Use secure bit in findVictim Sector caches must know if there was a sector hit in order to decide whether a victim's sector must be fully evicted to give place to a new sector or not. In order to do so it needs the tag and secure information. Change-Id: Ib554169e25fa131d6bf986561f7970b787c56874 Reviewed-on: https://gem5-review.googlesource.com/10722 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> |
Completed in 103 milliseconds