t;
> Dan Gerzhoy
> PhD Candidate, Computer Engineering
> University of Maryland College Park
>
> On Fri, Nov 6, 2020 at 8:38 AM Shehab Elsayed via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hello All,
>>
>> My group is in the process of upgrading ou
Hello All,
My group is in the process of upgrading our cluster and since many of us
are using gem5 I was wondering if anyone has experience or recommendation
they would like to share about the process for a smooth gem5 operation.
Mainly I am concerned about 2 issues:
1) Required hard disk and
matter since the TLB sits behind
> caches anyways? I believe that model will work for either classic or Ruby.
> --------------
> *From:* Shehab Elsayed via gem5-users
> *Sent:* Tuesday, June 23, 2020 12:20 AM
> *To:* gem5 users mailing list
> *Cc:* Shehab Elsayed
Hello All,
I am trying to model a deeper O3 pipeline as suggested in
https://gem5-users.gem5.narkive.com/LNMJQ1M5/model-deeper-pipeline-in-x86
but I keep running into some assertion failures related to the time buffers
and skid buffers even though that patch mentioned in the previous link is
Hello All,
I was wondering if there is a way to simulate a system with 2 levels of TLBs
in full system simulation with ruby for ARM?
I have seen other examples that use the classical memory model and use a
cache as the second level TLB. Is there something similar that can be done
in Ruby memory
Which files do you think are missing? There are some shared files between
MESI_Three_Level and MESI_Two-Level such as the L2 controller. You can find
a list of all files used by the MESI_Three_Level protocol in
src/mem/ruby/protocol/MESI_Three_Level.slicc. I hope this helps.
On Thu, May 28, 2020
I see, Thanks for the explanation!
On Thu, May 14, 2020 at 3:36 PM Tiago Muck wrote:
> Right now it's possible the redefine the mandatoryQueueLatency function to
> return the cache latency, but this only works for L1 hit latency. It's
> currently not possible to have a fully generic model since
Thank you very much for your reply and explanation, Tiago!
Wouldn't it be more generic to add the latencies at the time of performing
the access in the cache itself instead of having it in the controllers
since any cache access should incur access latency? I am not sure how easy
that would be
Hello All,
In MOESI_CMP_directory, the ruby cache latencies (tagAccessLatency and
dataAccessLatency) are included in the SLICC cache controllers through
cacheReponsLatency() function. However, the function is only included in
messages that include a data response while all other messages use the
