Searched hist:10722 (Results 1 - 8 of 8) sorted by relevance

/gem5/src/mem/
H A Dqport.hh10722: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 Dpacket_queue.cc10722: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 Dpacket_queue.hh10722: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 Dbase_set_assoc.hh12746: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 Dbase.hh12746: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 Dfa_lru.hh12746: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 Dfa_lru.cc12746: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 Dbase.cc12746: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