gem5 - gem5

Age	Commit message (Collapse)	Author
2018-11-27	arch, base, cpu, gpu, mem: Replace assert(0 or false with panic.	Gabe Black
	Neither assert(0) nor assert(false) give any hint as to why control getting to them is bad, and their more descriptive versions, assert(0 && "description") and assert(false && "description"), jury rig assert to add an error message when the utility function panic() already does that directly with better formatting options. This change replaces that flavor of call to assert with panic, except in the actual code which processes the formatting that panic uses (to avoid infinitely recurring error handling), and in some *.sm files since I don't know what rules those have to follow and don't want to accidentaly break them. Change-Id: I8addfbfaf77eaed94ec8191f2ae4efb477cefdd0 Reviewed-on: https://gem5-review.googlesource.com/c/14636 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2018-07-23	mem: Rename Packet::checkFunctional to trySatisfyFunctional	Robert Kovacsics
	Packet::checkFunctional also wrote data to/from the packet depending on if it was read/write, respectively, which the 'check' in the name would suggest otherwise. This renames it to doFunctional, which is more suggestive. It also renames any function called checkFunctional which calls Packet::checkFunctional. These are - Bridge::BridgeMasterPort::checkFunctional - calls Packet::checkFunctional - MSHR::checkFunctional - calls Packet::checkFunctional - MSHR::TargetList::checkFunctional - calls Packet::checkFunctional - Queue<>::checkFunctional (of src/mem/cache/queue.hh, not src/cpu/minor/buffers.h) - Instantiated with Queue<WriteQueueEntry> and Queue<MSHR> - WriteQueueEntry - calls Packet::checkFunctional - WriteQueueEntry::TargetList - calls Packet::checkFunctional - MemDelay::checkFunctional - calls QueuedSlavePort/QueuedMasterPort::checkFunctional - Packet::checkFunctional - PacketQueue::checkFunctional - calls Packet::checkFunctional - QueuedSlavePort::checkFunctional - calls PacketQueue::doFunctional - QueuedMasterPort::checkFunctional - calls PacketQueue::doFunctional - SerialLink::SerialLinkMasterPort::checkFunctional - calls Packet::doFunctional Change-Id: Ieca2579c020c329040da053ba8e25820801b62c5 Reviewed-on: https://gem5-review.googlesource.com/11810 Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2018-05-31	mem-cache: Fix include directives in the cache related classes	Nikos Nikoleris
	Change-Id: I111b0f662897c43974aadb08da1ed85c7542585c Reviewed-on: https://gem5-review.googlesource.com/10433 Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2018-05-31	mem-cache: Add a non-coherent cache	Nikos Nikoleris
	The class re-uses the existing MSHR and write queue. At the moment every single access is handled by the cache, even uncacheable accesses, and nothing is forwarded. This is a modified version of a changeset put together by Andreas Hansson <andreas.hansson@arm.com> Change-Id: I41f7f9c2b8c7fa5ec23712a4446e8adb1c9a336a Reviewed-on: https://gem5-review.googlesource.com/8291 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
2016-05-26	mem: change NULL to nullptr in the cache related classes	Nikos Nikoleris
	Change-Id: I5042410be54935650b7d05c84d8d9efbfcc06e70 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-03-17	mem: Adjust cache queue reserve to more conservative values	Andreas Hansson
	The cache queue reserve is there as an overflow to give us enough headroom based on when we block the cache, and how many transactions we may already have accepted before actually blocking. The previous values were probably chosen to be "big enough", when we actually know that we check the MSHRs after every single allocation, and for the write buffers we know that we implicitly may need one entry for every outstanding MSHR. * * * mem: Adjust cache queue reserve to more conservative values The cache queue reserve is there as an overflow to give us enough headroom based on when we block the cache, and how many transactions we may already have accepted before actually blocking. The previous values were probably chosen to be "big enough", when we actually know that we check the MSHRs after every single allocation, and for the write buffers we know that we implicitly may need one entry for every outstanding MSHR.
2016-03-17	mem: Create a separate class for the cache write buffer	Andreas Hansson
	This patch breaks out the cache write buffer into a separate class, without affecting any stats. The goal of the patch is to avoid encumbering the much-simpler write queue with the complex MSHR handling. In a follow on patch this simplification allows us to implement write combining. The WriteQueue gets its own class, but shares a common ancestor, the generic Queue, with the MSHRQueue.