Discussion:
ARM - Cache Coherence Protocol
(too old to reply)
Davesh Shingari
2015-04-15 22:45:29 UTC
Permalink
Hi

In the ARM FS simulation which cache coherence model is used. When I look
at the build_opts/ARM, then I can see Protocol as MI_example. If that is
the one used then how come 2 level cache hierarchy is implemented (because
the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it
then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
ᐧ
Andreas Hansson
2015-04-15 23:31:36 UTC
Permalink
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=bde27132-b42f-4480-ace7-bef4c56120df]ᐧ

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Davesh Shingari
2015-04-15 23:52:35 UTC
Permalink
Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please
help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean
that right now by default when I built gem5.opt the default configuration
in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL =
'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the
simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with
specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used
for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of
a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt
(I know debugger and logs can be used, but is looking into build/ARM/
directory enought to draw conclusions that a file was compiled)


ᐧ
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide a
very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When I
look at the build_opts/ARM, then I can see Protocol as MI_example. If that
is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't
it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
ᐧ
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Andreas Hansson
2015-04-16 00:03:58 UTC
Permalink
Q1 Since you are not using Ruby the PROTOCOL is irrelevant

Q2 As with all gem5 objects there is a Python class (BaseCache.py) instance created. Check out CacheConfig.py and the other config scripts.

Q3 I’d suggest to make them uncacheable based on masterId. Note that you need the non-stable gem5 repo to support snooping for uncacheable accesses.

Q4 The build/ directory contains all the built files.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 00:52
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean that right now by default when I built gem5.opt the default configuration in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MI_example'
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL = 'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the simulation, then in the directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with specification of "--caches --l2cache", I could see in config.ini that L2cache was created, but I am confused how was it created as in which file was involved. It will be highly appreciated if you could point out which file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of a specific processor directly to main memory bypassing L2. I mean suggestion on which file to look for. In x86 system we could have used MachineId to know the requestor and in allocateCacheblock could have bypassed the allocation on basis of l1cache id. Can you provide some pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt (I know debugger and logs can be used, but is looking into build/ARM/ directory enought to draw conclusions that a file was compiled)


[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=88aed3a1-1370-47f1-b943-aa2ce935efc0]ᐧ

On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=bde27132-b42f-4480-ace7-bef4c56120df]ᐧ

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Davesh Shingari
2015-04-16 00:24:27 UTC
Permalink
Hello Andreas

Thanks for the reply. It makes much more sense now. Just one clarification.

If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.

The reason I am asking is that I am confused because you say:
"With ARM you should use the classic memory system (in some configuration),
and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.

Thanks a lot for your time.
ᐧ
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note that you
need the non-stable gem5 repo to support snooping for uncacheable accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions. Please
Q.1
For building gem5.opt do we need to provide some specific arguments. I
mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL =
'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run the
simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM
with specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1 cache
of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt
(I know debugger and logs can be used, but is looking into build/ARM/
directory enought to draw conclusions that a file was compiled)
ᐧ
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide a
very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When I
look at the build_opts/ARM, then I can see Protocol as MI_example. If that
is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't
it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
ᐧ
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Andreas Hansson
2015-04-16 00:49:30 UTC
Permalink
Hi Davesh,

All the classic memory system cache source files are in src/mem/caches, and this is also where you can see how the coherency protocol is implemented.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 01:24
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks for the reply. It makes much more sense now. Just one clarification.

If I understand clearly then you mean that mentioning of PROTOCOL is irrelevant, but then how come MOESI gets selected (as you said Classic memory model uses it, which file is associated with it). So if I change the MOESI protocol files in src/mem/protocol, then the changes won't have any effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.

The reason I am asking is that I am confused because you say:
"With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which associated files implements that, because in build directory I can't see any MOESI file.

Thanks a lot for your time.
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=6d8a59bf-9499-4c2c-830d-80ef7a89077c]ᐧ

On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Q1 Since you are not using Ruby the PROTOCOL is irrelevant

Q2 As with all gem5 objects there is a Python class (BaseCache.py) instance created. Check out CacheConfig.py and the other config scripts.

Q3 I’d suggest to make them uncacheable based on masterId. Note that you need the non-stable gem5 repo to support snooping for uncacheable accesses.

Q4 The build/ directory contains all the built files.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 00:52
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean that right now by default when I built gem5.opt the default configuration in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MI_example'
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL = 'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the simulation, then in the directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with specification of "--caches --l2cache", I could see in config.ini that L2cache was created, but I am confused how was it created as in which file was involved. It will be highly appreciated if you could point out which file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of a specific processor directly to main memory bypassing L2. I mean suggestion on which file to look for. In x86 system we could have used MachineId to know the requestor and in allocateCacheblock could have bypassed the allocation on basis of l1cache id. Can you provide some pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt (I know debugger and logs can be used, but is looking into build/ARM/ directory enought to draw conclusions that a file was compiled)


[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=88aed3a1-1370-47f1-b943-aa2ce935efc0]ᐧ

On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=bde27132-b42f-4480-ace7-bef4c56120df]ᐧ

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Davesh Shingari
2015-04-16 23:07:12 UTC
Permalink
Hello Andreas

Thanks a lot. That helped a lot. I implemented the configuration matching
my requirement.

Just one clarification needed. So in the access template in cache_impl.hh I
inserted the following logic:
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is %d\n",
pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?

And do I need to make these changes other places too i.e. should I make
these request uncacheable everywhere isUncacheable is being checked?

Thanks for your time.
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
Post by Andreas Hansson
Hi Davesh,
All the classic memory system cache source files are in src/mem/caches,
and this is also where you can see how the coherency protocol is
implemented.
Andreas
Date: Thursday, 16 April 2015 01:24
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks for the reply. It makes much more sense now. Just one
clarification.
If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.
"With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.
Thanks a lot for your time.
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note that
you need the non-stable gem5 repo to support snooping for uncacheable
accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions. Please
Q.1
For building gem5.opt do we need to provide some specific arguments. I
mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL
= 'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run the
simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM
with specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1 cache
of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the
gem5.opt (I know debugger and logs can be used, but is looking into
build/ARM/ directory enought to draw conclusions that a file was compiled)
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide a
very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When I
look at the build_opts/ARM, then I can see Protocol as MI_example. If that
is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then
doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Andreas Hansson
2015-04-17 01:21:57 UTC
Permalink
Hi Davesh,

Conceptually it looks ok (but rather brittle using a number like that). You should only ever have to do this in the L1 (or the LSQ).

Also, for this to work, you need the patches for uncacheable access that are currently on the review board. I’m hoping they can be pushed in the next week or so.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 16:07
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot. That helped a lot. I implemented the configuration matching my requirement.

Just one clarification needed. So in the access template in cache_impl.hh I inserted the following logic:
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is %d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=45fea47d-7555-4791-a1db-da1c73d6b4fb]ᐧ
What I am expecting is that whenever request comes from L1 cache with master id 12, then that request will be uncacheable in L2, i.e. it won't be allocated a cache line. Is my assumption correct.
Is this what uncacheable does?

And do I need to make these changes other places too i.e. should I make these request uncacheable everywhere isUncacheable is being checked?

Thanks for your time.
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>


On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

All the classic memory system cache source files are in src/mem/caches, and this is also where you can see how the coherency protocol is implemented.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 01:24

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks for the reply. It makes much more sense now. Just one clarification.

If I understand clearly then you mean that mentioning of PROTOCOL is irrelevant, but then how come MOESI gets selected (as you said Classic memory model uses it, which file is associated with it). So if I change the MOESI protocol files in src/mem/protocol, then the changes won't have any effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.

The reason I am asking is that I am confused because you say:
"With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which associated files implements that, because in build directory I can't see any MOESI file.

Thanks a lot for your time.

On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Q1 Since you are not using Ruby the PROTOCOL is irrelevant

Q2 As with all gem5 objects there is a Python class (BaseCache.py) instance created. Check out CacheConfig.py and the other config scripts.

Q3 I’d suggest to make them uncacheable based on masterId. Note that you need the non-stable gem5 repo to support snooping for uncacheable accesses.

Q4 The build/ directory contains all the built files.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 00:52
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean that right now by default when I built gem5.opt the default configuration in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MI_example'
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL = 'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the simulation, then in the directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with specification of "--caches --l2cache", I could see in config.ini that L2cache was created, but I am confused how was it created as in which file was involved. It will be highly appreciated if you could point out which file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of a specific processor directly to main memory bypassing L2. I mean suggestion on which file to look for. In x86 system we could have used MachineId to know the requestor and in allocateCacheblock could have bypassed the allocation on basis of l1cache id. Can you provide some pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt (I know debugger and logs can be used, but is looking into build/ARM/ directory enought to draw conclusions that a file was compiled)



On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Davesh Shingari
2015-04-17 02:20:52 UTC
Permalink
Hello Andreas

Thanks for prompt reply. Can you please let me know what you mean by "You
should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request comes
from L1 cache corresponding to Master Id of 12.

I know the implementation is brittle and is temporary. I will be modifying
it to make it stable and configurable.
Post by Andreas Hansson
Hi Davesh,
Conceptually it looks ok (but rather brittle using a number like that).
You should only ever have to do this in the L1 (or the LSQ).
Also, for this to work, you need the patches for uncacheable access that
are currently on the review board. I’m hoping they can be pushed in the
next week or so.
Andreas
Date: Thursday, 16 April 2015 16:07
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot. That helped a lot. I implemented the configuration matching my requirement.
Just one clarification needed. So in the access template in
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is
%d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?
And do I need to make these changes other places too i.e. should I make
these request uncacheable everywhere isUncacheable is being checked?
Thanks for your time.
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
Post by Andreas Hansson
Hi Davesh,
All the classic memory system cache source files are in src/mem/caches,
and this is also where you can see how the coherency protocol is
implemented.
Andreas
Date: Thursday, 16 April 2015 01:24
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks for the reply. It makes much more sense now. Just one
clarification.
If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.
"With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.
Thanks a lot for your time.
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note that
you need the non-stable gem5 repo to support snooping for uncacheable
accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions.
Q.1
For building gem5.opt do we need to provide some specific arguments. I
mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL
= 'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run
the simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM
with specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1 cache
of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the
gem5.opt (I know debugger and logs can be used, but is looking into
build/ARM/ directory enought to draw conclusions that a file was compiled)
On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide a
very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When I
look at the build_opts/ARM, then I can see Protocol as MI_example. If that
is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then
doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Davesh Shingari
2015-04-18 01:35:38 UTC
Permalink
Hello Andreas

Is the changelist on
https://www.mail-archive.com/gem5-***@gem5.org/msg14217.html , the one you
are talking about?

Can I just update these changes on the gem5 dev downloaded code setup?
ᐧ
Post by Davesh Shingari
Hello Andreas
Thanks for prompt reply. Can you please let me know what you mean by "You
should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request comes
from L1 cache corresponding to Master Id of 12.
I know the implementation is brittle and is temporary. I will be modifying
it to make it stable and configurable.
Post by Andreas Hansson
Hi Davesh,
Conceptually it looks ok (but rather brittle using a number like that).
You should only ever have to do this in the L1 (or the LSQ).
Also, for this to work, you need the patches for uncacheable access
that are currently on the review board. I’m hoping they can be pushed in
the next week or so.
Andreas
Date: Thursday, 16 April 2015 16:07
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot. That helped a lot. I implemented the configuration
matching my requirement.
Just one clarification needed. So in the access template in
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is
%d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?
And do I need to make these changes other places too i.e. should I make
these request uncacheable everywhere isUncacheable is being checked?
Thanks for your time.
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
Post by Andreas Hansson
Hi Davesh,
All the classic memory system cache source files are in
src/mem/caches, and this is also where you can see how the coherency
protocol is implemented.
Andreas
Date: Thursday, 16 April 2015 01:24
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks for the reply. It makes much more sense now. Just one clarification.
If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.
"With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.
Thanks a lot for your time.
On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note that
you need the non-stable gem5 repo to support snooping for uncacheable
accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions.
Q.1
For building gem5.opt do we need to provide some specific arguments. I
mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or
PROTOCOL = 'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run
the simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM
with specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1
cache of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the
gem5.opt (I know debugger and logs can be used, but is looking into
build/ARM/ directory enought to draw conclusions that a file was compiled)
On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide a
very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When I
look at the build_opts/ARM, then I can see Protocol as MI_example. If that
is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then
doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Andreas Hansson
2015-04-20 12:52:09 UTC
Permalink
Hi Davesh,

There is a whole bunch of patches related to uncacheable accesses that you will need. Just have a look at the patches I have posted in the last three weeks.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Saturday, 18 April 2015 02:35
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Is the changelist on https://www.mail-archive.com/gem5-***@gem5.org/msg14217.html , the one you are talking about?

Can I just update these changes on the gem5 dev downloaded code setup?
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=2e8b264e-6370-4db6-9e33-eaf2ad52440a]ᐧ

On Thu, Apr 16, 2015 at 7:20 PM, Davesh Shingari <***@gmail.com<mailto:***@gmail.com>> wrote:
Hello Andreas

Thanks for prompt reply. Can you please let me know what you mean by "You should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request comes from L1 cache corresponding to Master Id of 12.

I know the implementation is brittle and is temporary. I will be modifying it to make it stable and configurable.

On Thu, Apr 16, 2015 at 6:21 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

Conceptually it looks ok (but rather brittle using a number like that). You should only ever have to do this in the L1 (or the LSQ).

Also, for this to work, you need the patches for uncacheable access that are currently on the review board. I’m hoping they can be pushed in the next week or so.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 16:07

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot. That helped a lot. I implemented the configuration matching my requirement.

Just one clarification needed. So in the access template in cache_impl.hh I inserted the following logic:
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is %d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=45fea47d-7555-4791-a1db-da1c73d6b4fb]ᐧ
What I am expecting is that whenever request comes from L1 cache with master id 12, then that request will be uncacheable in L2, i.e. it won't be allocated a cache line. Is my assumption correct.
Is this what uncacheable does?

And do I need to make these changes other places too i.e. should I make these request uncacheable everywhere isUncacheable is being checked?

Thanks for your time.
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>


On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

All the classic memory system cache source files are in src/mem/caches, and this is also where you can see how the coherency protocol is implemented.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 01:24

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks for the reply. It makes much more sense now. Just one clarification.

If I understand clearly then you mean that mentioning of PROTOCOL is irrelevant, but then how come MOESI gets selected (as you said Classic memory model uses it, which file is associated with it). So if I change the MOESI protocol files in src/mem/protocol, then the changes won't have any effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.

The reason I am asking is that I am confused because you say:
"With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which associated files implements that, because in build directory I can't see any MOESI file.

Thanks a lot for your time.

On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Q1 Since you are not using Ruby the PROTOCOL is irrelevant

Q2 As with all gem5 objects there is a Python class (BaseCache.py) instance created. Check out CacheConfig.py and the other config scripts.

Q3 I’d suggest to make them uncacheable based on masterId. Note that you need the non-stable gem5 repo to support snooping for uncacheable accesses.

Q4 The build/ directory contains all the built files.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 00:52
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean that right now by default when I built gem5.opt the default configuration in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MI_example'
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL = 'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the simulation, then in the directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with specification of "--caches --l2cache", I could see in config.ini that L2cache was created, but I am confused how was it created as in which file was involved. It will be highly appreciated if you could point out which file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of a specific processor directly to main memory bypassing L2. I mean suggestion on which file to look for. In x86 system we could have used MachineId to know the requestor and in allocateCacheblock could have bypassed the allocation on basis of l1cache id. Can you provide some pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt (I know debugger and logs can be used, but is looking into build/ARM/ directory enought to draw conclusions that a file was compiled)



On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Davesh Shingari
2015-04-20 17:47:08 UTC
Permalink
Hi Andreas

Thanks a lot. I found and applied the patches.
Thanks again for your help.
ᐧ
Post by Andreas Hansson
Hi Davesh,
There is a whole bunch of patches related to uncacheable accesses that
you will need. Just have a look at the patches I have posted in the last
three weeks.
Andreas
Date: Saturday, 18 April 2015 02:35
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Is the changelist on
you are talking about?
Can I just update these changes on the gem5 dev downloaded code setup?
ᐧ
Post by Davesh Shingari
Hello Andreas
Thanks for prompt reply. Can you please let me know what you mean by "You
should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request comes
from L1 cache corresponding to Master Id of 12.
I know the implementation is brittle and is temporary. I will be
modifying it to make it stable and configurable.
Post by Andreas Hansson
Hi Davesh,
Conceptually it looks ok (but rather brittle using a number like
that). You should only ever have to do this in the L1 (or the LSQ).
Also, for this to work, you need the patches for uncacheable access
that are currently on the review board. I’m hoping they can be pushed in
the next week or so.
Andreas
Date: Thursday, 16 April 2015 16:07
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot. That helped a lot. I implemented the configuration
matching my requirement.
Just one clarification needed. So in the access template in
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is
%d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?
And do I need to make these changes other places too i.e. should I
make these request uncacheable everywhere isUncacheable is being checked?
Thanks for your time.
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
All the classic memory system cache source files are in
src/mem/caches, and this is also where you can see how the coherency
protocol is implemented.
Andreas
Date: Thursday, 16 April 2015 01:24
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks for the reply. It makes much more sense now. Just one clarification.
If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.
"With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.
Thanks a lot for your time.
On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note that
you need the non-stable gem5 repo to support snooping for uncacheable
accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions.
Q.1
For building gem5.opt do we need to provide some specific arguments. I
mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or
PROTOCOL = 'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run
the simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM
with specification of "--caches --l2cache", I could see in config.ini that
L2cache was created, but I am confused how was it created as in which file
was involved. It will be highly appreciated if you could point out which
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1
cache of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the
gem5.opt (I know debugger and logs can be used, but is looking into
build/ARM/ directory enought to draw conclusions that a file was compiled)
On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide
a very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When
I look at the build_opts/ARM, then I can see Protocol as MI_example. If
that is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then
doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Davesh Shingari
2015-04-20 22:30:13 UTC
Permalink
Hi

Just on inform you.
When I am starting the system in detailed mode, the assertion fails for
isUncacheable. The error is:
gem5.opt: build/ARM/mem/cache/cache_impl.hh:1207: void
Cache<TagStore>::recvTimingResp(PacketPtr) [with TagStore = LRU, PacketPtr
= Packet*]: Assertion `!tgt_pkt->req->isUncacheable()' failed.

Workaround is: I am using default timing mode to get the checkpoint and
then using that checkpoint to start detailed mode. So far it is running
fine.
ᐧ
Post by Davesh Shingari
Hi Andreas
Thanks a lot. I found and applied the patches.
Thanks again for your help.
ᐧ
Post by Andreas Hansson
Hi Davesh,
There is a whole bunch of patches related to uncacheable accesses that
you will need. Just have a look at the patches I have posted in the last
three weeks.
Andreas
Date: Saturday, 18 April 2015 02:35
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Is the changelist on
you are talking about?
Can I just update these changes on the gem5 dev downloaded code setup?
ᐧ
On Thu, Apr 16, 2015 at 7:20 PM, Davesh Shingari <
Post by Davesh Shingari
Hello Andreas
Thanks for prompt reply. Can you please let me know what you mean by "You
should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request
comes from L1 cache corresponding to Master Id of 12.
I know the implementation is brittle and is temporary. I will be
modifying it to make it stable and configurable.
On Thu, Apr 16, 2015 at 6:21 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
Conceptually it looks ok (but rather brittle using a number like
that). You should only ever have to do this in the L1 (or the LSQ).
Also, for this to work, you need the patches for uncacheable access
that are currently on the review board. I’m hoping they can be pushed in
the next week or so.
Andreas
Date: Thursday, 16 April 2015 16:07
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot. That helped a lot. I implemented the configuration
matching my requirement.
Just one clarification needed. So in the access template in
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is
%d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?
And do I need to make these changes other places too i.e. should I
make these request uncacheable everywhere isUncacheable is being checked?
Thanks for your time.
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
All the classic memory system cache source files are in
src/mem/caches, and this is also where you can see how the coherency
protocol is implemented.
Andreas
Date: Thursday, 16 April 2015 01:24
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks for the reply. It makes much more sense now. Just one clarification.
If I understand clearly then you mean that mentioning of PROTOCOL is
irrelevant, but then how come MOESI gets selected (as you said Classic
memory model uses it, which file is associated with it). So if I change the
MOESI protocol files in src/mem/protocol, then the changes won't have any
effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.
"With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which
associated files implements that, because in build directory I can't see
any MOESI file.
Thanks a lot for your time.
On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <
Post by Andreas Hansson
Q1 Since you are not using Ruby the PROTOCOL is irrelevant
Q2 As with all gem5 objects there is a Python class (BaseCache.py)
instance created. Check out CacheConfig.py and the other config scripts.
Q3 I’d suggest to make them uncacheable based on masterId. Note
that you need the non-stable gem5 repo to support snooping for uncacheable
accesses.
Q4 The build/ directory contains all the built files.
Andreas
Date: Thursday, 16 April 2015 00:52
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
Hello Andreas
Thanks a lot for prompt reply. Sorry for long list of questions.
Q.1
For building gem5.opt do we need to provide some specific arguments.
I mean that right now by default when I built gem5.opt the default
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
*PROTOCOL = 'MI_example'*
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or
PROTOCOL = 'MOESI_CMP_token' ?
The reason is that when I built it by default configuration and run
the simulation, then in the
directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
see all the transitions associated with MI_example protocol.
Q.2
From where does L2 cache gets created. When I ran the gem5.opt for
ARM with specification of "--caches --l2cache", I could see in config.ini
that L2cache was created, but I am confused how was it created as in which
file was involved. It will be highly appreciated if you could point out
gem5-stable/src/mem/simple_mem.cc
gem5-stable/src/mem/cache/base.cc & cache.cc
I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't
be used for sure as it doesn't use Ruby.
Q.3
Can you give any suggestion on how can we bypass request from a L1
cache of a specific processor directly to main memory bypassing L2. I mean
suggestion on which file to look for. In x86 system we could have used
MachineId to know the requestor and in allocateCacheblock could have
bypassed the allocation on basis of l1cache id. Can you provide some
pointers in ARM?
Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the
gem5.opt (I know debugger and logs can be used, but is looking into
build/ARM/ directory enought to draw conclusions that a file was compiled)
On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <
Post by Andreas Hansson
Hi Davesh,
With ARM you should use the classic memory system (in some
configuration), and thus a MOESI protocol. There is no need to use Ruby.
The cache and crossbar models in the classic memory system provide
a very flexible set of components that you can use to build a wide range of
on-chip memory systems.
Andreas
Date: Wednesday, 15 April 2015 23:45
Subject: [gem5-users] ARM - Cache Coherence Protocol
Hi
In the ARM FS simulation which cache coherence model is used. When
I look at the build_opts/ARM, then I can see Protocol as MI_example. If
that is the one used then how come 2 level cache hierarchy is implemented
(because the MI example has 1 level cache hierarchy)?
And ARM uses Classic Memory Model instead of Ruby. If yes, then
doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu
Andreas Hansson
2015-04-20 22:34:05 UTC
Permalink
Hi Davesh,

That sounds rather unfortunate, and I wonder if something is not right with your patch queue. All the regressions work fine, and the memory system soak tests have not found any problems. That said, it could very well be a bug.

Once the last two patches are ok’ed on the reviewboard I shall go ahead and push them all. If there are still issues after that it would be good to get more details on how to reproduce.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Monday, 20 April 2015 23:30
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hi

Just on inform you.
When I am starting the system in detailed mode, the assertion fails for isUncacheable. The error is:
gem5.opt: build/ARM/mem/cache/cache_impl.hh:1207: void Cache<TagStore>::recvTimingResp(PacketPtr) [with TagStore = LRU, PacketPtr = Packet*]: Assertion `!tgt_pkt->req->isUncacheable()' failed.

Workaround is: I am using default timing mode to get the checkpoint and then using that checkpoint to start detailed mode. So far it is running fine.
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=50607c9f-e90e-410d-b543-7e457c2186cf]ᐧ

On Mon, Apr 20, 2015 at 10:47 AM, Davesh Shingari <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi Andreas

Thanks a lot. I found and applied the patches.
Thanks again for your help.
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=a50c2c8c-7776-46f6-ac94-62cb9638b94a]ᐧ

On Mon, Apr 20, 2015 at 5:52 AM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

There is a whole bunch of patches related to uncacheable accesses that you will need. Just have a look at the patches I have posted in the last three weeks.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Saturday, 18 April 2015 02:35

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Is the changelist on https://www.mail-archive.com/gem5-***@gem5.org/msg14217.html , the one you are talking about?

Can I just update these changes on the gem5 dev downloaded code setup?
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=2e8b264e-6370-4db6-9e33-eaf2ad52440a]ᐧ

On Thu, Apr 16, 2015 at 7:20 PM, Davesh Shingari <***@gmail.com<mailto:***@gmail.com>> wrote:
Hello Andreas

Thanks for prompt reply. Can you please let me know what you mean by "You should only ever have to do this in the L1 (or the LSQ)" ?
My implementation is for L2 cache line i.e. when cache line request comes from L1 cache corresponding to Master Id of 12.

I know the implementation is brittle and is temporary. I will be modifying it to make it stable and configurable.

On Thu, Apr 16, 2015 at 6:21 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

Conceptually it looks ok (but rather brittle using a number like that). You should only ever have to do this in the L1 (or the LSQ).

Also, for this to work, you need the patches for uncacheable access that are currently on the review board. I’m hoping they can be pushed in the next week or so.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 16:07

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot. That helped a lot. I implemented the configuration matching my requirement.

Just one clarification needed. So in the access template in cache_impl.hh I inserted the following logic:
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is %d\n", pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
[https://mailfoogae.appspot.com/t?sender=ac2hpbmdhcmlkYXZlc2hAZ21haWwuY29t&type=zerocontent&guid=45fea47d-7555-4791-a1db-da1c73d6b4fb]ᐧ
What I am expecting is that whenever request comes from L1 cache with master id 12, then that request will be uncacheable in L2, i.e. it won't be allocated a cache line. Is my assumption correct.
Is this what uncacheable does?

And do I need to make these changes other places too i.e. should I make these request uncacheable everywhere isUncacheable is being checked?

Thanks for your time.
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>


On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

All the classic memory system cache source files are in src/mem/caches, and this is also where you can see how the coherency protocol is implemented.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 01:24

To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks for the reply. It makes much more sense now. Just one clarification.

If I understand clearly then you mean that mentioning of PROTOCOL is irrelevant, but then how come MOESI gets selected (as you said Classic memory model uses it, which file is associated with it). So if I change the MOESI protocol files in src/mem/protocol, then the changes won't have any effect. Right?
Can you please tell the file which implements MOESI protocol for ARM system.

The reason I am asking is that I am confused because you say:
"With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol."
" Since you are not using Ruby the PROTOCOL is irrelevant"
So I am confused whether MOSEI is used or not? If yes, then which associated files implements that, because in build directory I can't see any MOESI file.

Thanks a lot for your time.

On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Q1 Since you are not using Ruby the PROTOCOL is irrelevant

Q2 As with all gem5 objects there is a Python class (BaseCache.py) instance created. Check out CacheConfig.py and the other config scripts.

Q3 I’d suggest to make them uncacheable based on masterId. Note that you need the non-stable gem5 repo to support snooping for uncacheable accesses.

Q4 The build/ directory contains all the built files.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Thursday, 16 April 2015 00:52
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] ARM - Cache Coherence Protocol

Hello Andreas

Thanks a lot for prompt reply. Sorry for long list of questions. Please help me in the following related doubts:

Q.1
For building gem5.opt do we need to provide some specific arguments. I mean that right now by default when I built gem5.opt the default configuration in build_opts/ARM is as follows:
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MI_example'
Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL = 'MOESI_CMP_token' ?

The reason is that when I built it by default configuration and run the simulation, then in the directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I see all the transitions associated with MI_example protocol.

Q.2
From where does L2 cache gets created. When I ran the gem5.opt for ARM with specification of "--caches --l2cache", I could see in config.ini that L2cache was created, but I am confused how was it created as in which file was involved. It will be highly appreciated if you could point out which file does that task:

gem5-stable/src/mem/simple_mem.cc

gem5-stable/src/mem/cache/base.cc & cache.cc

I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be used for sure as it doesn't use Ruby.

Q.3
Can you give any suggestion on how can we bypass request from a L1 cache of a specific processor directly to main memory bypassing L2. I mean suggestion on which file to look for. In x86 system we could have used MachineId to know the requestor and in allocateCacheblock could have bypassed the allocation on basis of l1cache id. Can you provide some pointers in ARM?

Q.4 (Not that important)
Is there a way to know that the specific file is compiled for the gem5.opt (I know debugger and logs can be used, but is looking into build/ARM/ directory enought to draw conclusions that a file was compiled)



On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <***@arm.com<mailto:***@arm.com>> wrote:
Hi Davesh,

With ARM you should use the classic memory system (in some configuration), and thus a MOESI protocol. There is no need to use Ruby.

The cache and crossbar models in the classic memory system provide a very flexible set of components that you can use to build a wide range of on-chip memory systems.

Andreas

From: Davesh Shingari <***@gmail.com<mailto:***@gmail.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Wednesday, 15 April 2015 23:45
To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: [gem5-users] ARM - Cache Coherence Protocol

Hi

In the ARM FS simulation which cache coherence model is used. When I look at the build_opts/ARM, then I can see Protocol as MI_example. If that is the one used then how come 2 level cache hierarchy is implemented (because the MI example has 1 level cache hierarchy)?

And ARM uses Classic Memory Model instead of Ruby. If yes, then doesn't it then implements MOESI protocol. if no, then is Ruby supported?
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>
--
Have a great day!

Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University

***@asu.edu<mailto:***@asu.edu>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Continue reading on narkive:
Loading...