Hi Samuel,
If you're using the classic memory system, the easiest option is to add
a tiny cache between the SimObject that issues the writes and the rest
of the memory system. Then your SimObject can issue simple WriteReqs and
the cache will take care of the rest.
Otherwise, you will have to
Hi Aritra,
CleanEvict packets are generated by caches which have the parameter
writeback_clean set to false whenever there is an eviction of a clean
block. This is primarily to inform the snoop filter that a cache has a
evicted a block.
Hope this helps,
Nikos
On 02/03/2021 12:24,
Hi Aritra,
Your observation on what we model is correct. The response_latency is
the delay between the time that we handle a response from below (e.g.,
main memory) to the time we will send the response above (e.g., response
to the L2). We don't really attribute this latency to any specific
Hi,
The response_latency doesn't necessarily correspond to the time it takes
to fill in with the data from the response, but rather the time it takes
for a cache to respond to a request from the point it has the data. In
some cache designs, this will include the time to fill in but in other
Hi Saideepak,
In the classic memory system when you configure the cache to be mostly
inclusive, you always allocate on fetches and writebacks.
There are a few cases where mostly-inclusive deviates from
strictly-inclusive and iirc the most common one should be when a cache
(e.g., LLC) evicts a
Assymetric cache hierachies should work in the classic memory system.
The problem you run into is data corruption (the reported addresses are
most likely invalid) but it's hard to say anything about the cause of it
without more info.
One quick way to test your assymetric memory hierarchy would
gem5 doesn't provide a power model for the whole system out of the box.
However, it provides the infrastructure for you to hook your own power
model. You will find some very high level information here:
https://www.gem5.org/documentation/general_docs/thermal_model
and here:
Hi May,
Packets classified as writes in the memory controller are due to
writebacks from the last-level cache. Writeback packets will have a
physical address but will not have a valid virtual address.
Mapping a physical address to a virtual address in the general case is
not straightforward. In
Hi,
The simplest way to fix this, is to make sure that there is a
CoherentXBar just above the memory controller (you probably have one
already) and its parameter point_of_coherency is set to True. That way,
all packets that are necessary for the coherency protocol are handled by
that
