Hi Fengze,
Yeah, there's a lot of complicated and undocumented things you need to do
when initializing a CPU.
Here's a couple of pointers that may help. However, this code was written a
few years ago and is almost 4000 commits behind, so things have probably
changed since then!
Code: https://gith
Hello
I'm trying to modify and extend ruby CHI protocol for my research. Before doing
so, I'm looking for a simple way to verify my ruby model.
I used to use ruby_random_test.py config on ruby protocols to test multi-core
cache coherence and it worked well, but when I do the same thing on CHI, l
This certainly seems like a bug, but my guess is it's benign and will
essentially overwrite the existing one. Brad/Matt P (CC'd) may know better
though.
Matt
On Wed, Nov 3, 2021 at 4:06 AM Sampad Mohapatra via gem5-users <
gem5-users@gem5.org> wrote:
> Hi All,
>
> The dir_cntrl.requestToMemory
Thank you .This is really useful.
On 2/11/21 15:51, Jason Lowe-Power via gem5-users wrote:
Hello,
Yes. MI_example and MESI_Two_Level have been tested with the RISC-V
board in the components library. See
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/configs/example/components-
Hi all,
I am using gem5 with version 20.1.0.5. I am running a matrix arithmetic
application in SE mode with ARM architecture.
The system I am simulating includes CPU,icache,dcache, l2cache, and dram.
The l2cache has a stride prefetcher. Here are my problems about this stride
prefetcher:
Hi
I was trying to add a new CPU inherit from BaseCPU:
class MY_CPU: public BaseCPU
{
public:
MY_CPU(const MY_CPUParams& p);
~MY_CPU(){}
...
private:
...
}
but incurs the following running error: fatal: Process system.cpu.workload is
not associated with any HW contexts!
Hi All,
The dir_cntrl.requestToMemory is initialized twice in GPU_VIPER.py.
Could this potentially lead to two MessageBuffers being added or the
previous one will just be overwritten ? Is this correct functionality?
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/configs/ruby/GPU_V
