Hi Gabriel,
Sorry, but I am confused. I recompiled with the changes and also set
percent_uncacheable = 100 for the DMA controller. It still shows the same error.
Also, isn't DMA supposed to work coherently with the protocol? Otherwise
couldn't we simply read or write without worrying about coherency in
uncacheable accesses? Line 86 of ruby_mem_test also says that ruby does not
support atomic or uncacheable accesses.
I am trying to make changes to a protocol in order for it to support dma
operations and was hoping I could speed up the checking process by using
ruby_mem_test rather than waiting for hours for fs.py to boot up everytime.
Thanks and Regards,
Gautam Pathak
David R. Cheriton School of Computer Science
University of Waterloo
________________________________
From: gabriel.bus...@arteris.com <gabriel.bus...@arteris.com>
Sent: Tuesday, September 27, 2022 2:06 AM
To: gem5-users@gem5.org <gem5-users@gem5.org>
Subject: [gem5-users] Re: Ruby_mem_test.py dma test bug
Hi Gautam,
I believe this is caused by a failing dice rolling on line memtest.cc:223.
Replace:
bool uncacheable = random_mt.random(0, 100) < percentUncacheable;
with
bool uncacheable = random_mt.random(1, 100) <= percentUncacheable;
I forgot to push that patch, my mistake.
Explanation: DMAs should be emulated by MemTest by sending 100% uncachable
accesses. The offending line causes the DMA MemTest to send a coherent access
~1% of the time although configured with percent_uncacheable == 100. These 1%
accesses then target the same memory region as the coherent CPU (cache)
accesses but it is handled as a DMA (non-coherent) access by Ruby.
And there you get that error that merely tells you that an unexpected value was
read by MemTest.
Best,
Gabriel
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
