[gem5-dev] Re: review backlog

2021-03-01 Thread Gabe Black via gem5-dev 
Ok, thanks, just want to make sure they don't get forgotten. This was also
a reminder for folks not working directly on the release.

Gabe

On Mon, Mar 1, 2021 at 4:02 PM Jason Lowe-Power  wrote:

> Hey Gabe,
>
> Just FYI, those of use working on the release still have to test and fix
> bugs that we find on the staging branch. In releases past, this has taken
> 2-4 weeks of 100% effort. We'll get to these new changes when we can!
>
> Cheers,
> Jason
>
> On Mon, Mar 1, 2021 at 3:56 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hi folks. Now that the release branch has been created, I'd appreciate it
>> if we could start draining out the review backlog that has built up. I have
>> the following series of changes out and ready for review if you're so
>> inclined, link to the last change in the set.
>>
>> Eliminating the arch/utility.hh header (5 CLs)
>> https://gem5-review.googlesource.com/c/public/gem5/+/39337
>>
>> Mostly eliminate the arch/types.hh header, and some other cleanups (12
>> CLs)
>> https://gem5-review.googlesource.com/c/public/gem5/+/41893
>>
>> SCons cleanup (24 CLs)
>> https://gem5-review.googlesource.com/c/public/gem5/+/41599
>>
>> Guest ABI implementation rework (1 CL)
>> https://gem5-review.googlesource.com/c/public/gem5/+/41600
>>
>> Drain most of the contents out of arch/registers.hh (10 CLs)
>> https://gem5-review.googlesource.com/c/public/gem5/+/41742
>>
>> Vector (predicate) register simplification, cleanup, streamlining (17 CLs)
>> https://gem5-review.googlesource.com/c/public/gem5/+/42003
>>
>> Some of these ~70 CLs have been reviewed already, but are being held up
>> by CLs ahead of them which have not. I've generally tried to pluck out CLs
>> which are already reviewed and which can jump the queue, but I think I've
>> already done that for all the CLs where it makes sense. Many of these are
>> really simple CLs which just delete things which aren't being used, so they
>> should be pretty easy to review.
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: review backlog

2021-03-01 Thread Jason Lowe-Power via gem5-dev 
Hey Gabe,

Just FYI, those of use working on the release still have to test and fix
bugs that we find on the staging branch. In releases past, this has taken
2-4 weeks of 100% effort. We'll get to these new changes when we can!

Cheers,
Jason

On Mon, Mar 1, 2021 at 3:56 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. Now that the release branch has been created, I'd appreciate it
> if we could start draining out the review backlog that has built up. I have
> the following series of changes out and ready for review if you're so
> inclined, link to the last change in the set.
>
> Eliminating the arch/utility.hh header (5 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/39337
>
> Mostly eliminate the arch/types.hh header, and some other cleanups (12 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41893
>
> SCons cleanup (24 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41599
>
> Guest ABI implementation rework (1 CL)
> https://gem5-review.googlesource.com/c/public/gem5/+/41600
>
> Drain most of the contents out of arch/registers.hh (10 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41742
>
> Vector (predicate) register simplification, cleanup, streamlining (17 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/42003
>
> Some of these ~70 CLs have been reviewed already, but are being held up by
> CLs ahead of them which have not. I've generally tried to pluck out CLs
> which are already reviewed and which can jump the queue, but I think I've
> already done that for all the CLs where it makes sense. Many of these are
> really simple CLs which just delete things which aren't being used, so they
> should be pretty easy to review.
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] review backlog

2021-03-01 Thread Gabe Black via gem5-dev 
Hi folks. Now that the release branch has been created, I'd appreciate it
if we could start draining out the review backlog that has built up. I have
the following series of changes out and ready for review if you're so
inclined, link to the last change in the set.

Eliminating the arch/utility.hh header (5 CLs)
https://gem5-review.googlesource.com/c/public/gem5/+/39337

Mostly eliminate the arch/types.hh header, and some other cleanups (12 CLs)
https://gem5-review.googlesource.com/c/public/gem5/+/41893

SCons cleanup (24 CLs)
https://gem5-review.googlesource.com/c/public/gem5/+/41599

Guest ABI implementation rework (1 CL)
https://gem5-review.googlesource.com/c/public/gem5/+/41600

Drain most of the contents out of arch/registers.hh (10 CLs)
https://gem5-review.googlesource.com/c/public/gem5/+/41742

Vector (predicate) register simplification, cleanup, streamlining (17 CLs)
https://gem5-review.googlesource.com/c/public/gem5/+/42003

Some of these ~70 CLs have been reviewed already, but are being held up by
CLs ahead of them which have not. I've generally tried to pluck out CLs
which are already reviewed and which can jump the queue, but I think I've
already done that for all the CLs where it makes sense. Many of these are
really simple CLs which just delete things which aren't being used, so they
should be pretty easy to review.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[release-staging-v21-0]: python: Add search functions to pystats groups

2021-03-01 Thread Jason Lowe-Power (Gerrit) via gem5-dev 
Jason Lowe-Power has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/42014 )



Change subject: python: Add search functions to pystats groups
..

python: Add search functions to pystats groups

This change adds three functions, a `children` function which will
iterate through all of the children of group based (optionally) on some
predicate. Then, it implements a `find` function and a `find_re`
function using the `children` function.

The `find` function allows users to match statistics or groups
within a group. For instance, you might want to find all of the groups
within the system which have the name "cpu{i}". This is useful for
aggregate statistic values across multiple components.

Example:
total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
   for cpu in simstat.system.find('cpu')])

The find function matches based on substring. If the name given the find
function is a substring of the stat name or the group name the
stat/group will be returned.

The `find_re` function is the same as find, but matches a regular
expression instead of a simple substring match.

Note: this was originally reviewed on
https://gem5-review.googlesource.com/c/public/gem5/+/41603 was rebased
incorrectly before merging. This change fixes the rebase and adds back
the children() and re_find() functions.

Change-Id: Idaa1e9efc56fd26de3285d3fa505087ddd78ac8a
Signed-off-by: Jason Lowe-Power 
---
M src/python/m5/ext/pystats/group.py
1 file changed, 57 insertions(+), 9 deletions(-)



diff --git a/src/python/m5/ext/pystats/group.py  
b/src/python/m5/ext/pystats/group.py

index 10887e2..f54d7a2 100644
--- a/src/python/m5/ext/pystats/group.py
+++ b/src/python/m5/ext/pystats/group.py
@@ -24,6 +24,7 @@
 # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+import re
 from typing import Dict, Iterator, List, Optional, Union

 from .jsonserializable import JsonSerializable
@@ -53,25 +54,72 @@
 for key,value in kwargs.items():
 setattr(self, key, value)

+def children(self, predicate: Optional[Callable[[str], bool]] = None
+ ) -> Iterator[Union["Group", Statistic]]:
+""" Iterate through all of the children, optionally with a  
predicate

+
+```
+>>> system.children(lambda _name: 'cpu' in name)
+[cpu0, cpu1, cpu2]
+```
+
+:param: predicate(str) -> bool: Optional. Each child's name is  
passed

+to this function. If it returns true, then the child is
+yielded. Otherwise, the child is skipped.
+If not provided then all children are returned.
+"""
+for attr in self.__dict__:
+# Check the provided predicate. If not a match, skip this child
+if predicate and not predicate(attr): continue
+obj = getattr(self, attr)
+if isinstance(obj, Group) or isinstance(obj, Statistic):
+yield obj
+
 def find(self, name: str) -> Iterator[Union["Group", Statistic]]:
 """ Find all stats that match the name
+
 This function searches all of the "children" in this group. It  
yields
 the set of attributes (children) that have the `name` as a  
substring.

 The order of the objects returned by the generator is arbitrary.
+
 ```
-system.find('cpu') -> [cpu0, cpu1, cpu2, cpu3, other_cpu, ...]
+>>> system.find('cpu')
+[cpu0, cpu1, cpu2, cpu3, other_cpu, ...]
 ```
+
 This is useful for performing aggregates over substats. For  
instance:

+
 ```
-total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
-   for cpu in simstat.system.find('cpu')])
+>>> total_instructions =  
sum([cpu.exec_context.thread_0.numInsts.value
+  for cpu in  
simstat.system.find('cpu')])

+10
 ```
+
+:param: name: The name to search for
 """
-for attr in self.__dict__:
-if name in attr:
-obj = getattr(self, attr)
-if isinstance(obj, Group) or isinstance(obj, Statistic):
-yield obj
+yield from self.children(lambda _name: _name in name)
+
+def find_re(self, regex: Union[str, re.Pattern]
+) -> Iterator[Union["Group", Statistic]]:
+""" Find all stats that match the name
+
+This function searches all of the "children" in this group. It  
yields

+the set of attributes (children) that have the `name` mathing the
+regex provided. The order of the objects returned by the generator  
is

+arbitrary.
+
+```
+>>> system.find_re('cpu[0-9]')
+[cpu0, cpu1, cpu2]
+```
+

[gem5-dev] Change in gem5/gem5[develop]: Revert "python: Add search functions to pystats groups"

2021-03-01 Thread Jason Lowe-Power (Gerrit) via gem5-dev 
Attention is currently required from: Andreas Sandberg, Bobby R. Bruce,  
Jason Lowe-Power.

Hello Andreas Sandberg, kokoro, Bobby R. Bruce, Jason Lowe-Power,

I'd like you to do a code review. Please visit

https://gem5-review.googlesource.com/c/public/gem5/+/42013

to review the following change.


Change subject: Revert "python: Add search functions to pystats groups"
..

Revert "python: Add search functions to pystats groups"

This reverts commit 649e5cd8e04d38bcab9227f8ff7c520bbe12d228.

Reason for revert: Rebase error

Change-Id: I28fc102e552334f28a271516bbc39d562caab299
---
M src/python/m5/ext/pystats/group.py
1 file changed, 1 insertion(+), 21 deletions(-)



diff --git a/src/python/m5/ext/pystats/group.py  
b/src/python/m5/ext/pystats/group.py

index 10887e2..41a5633 100644
--- a/src/python/m5/ext/pystats/group.py
+++ b/src/python/m5/ext/pystats/group.py
@@ -24,7 +24,7 @@
 # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-from typing import Dict, Iterator, List, Optional, Union
+from typing import Dict, List, Optional, Union

 from .jsonserializable import JsonSerializable
 from .statistic import Scalar, Statistic
@@ -53,26 +53,6 @@
 for key,value in kwargs.items():
 setattr(self, key, value)

-def find(self, name: str) -> Iterator[Union["Group", Statistic]]:
-""" Find all stats that match the name
-This function searches all of the "children" in this group. It  
yields
-the set of attributes (children) that have the `name` as a  
substring.

-The order of the objects returned by the generator is arbitrary.
-```
-system.find('cpu') -> [cpu0, cpu1, cpu2, cpu3, other_cpu, ...]
-```
-This is useful for performing aggregates over substats. For  
instance:

-```
-total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
-   for cpu in simstat.system.find('cpu')])
-```
-"""
-for attr in self.__dict__:
-if name in attr:
-obj = getattr(self, attr)
-if isinstance(obj, Group) or isinstance(obj, Statistic):
-yield obj
-
 class Vector(Group):
 """
 The Vector class is used to store vector information. However, in gem5

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/42013
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I28fc102e552334f28a271516bbc39d562caab299
Gerrit-Change-Number: 42013
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-Attention: Andreas Sandberg 
Gerrit-Attention: Bobby R. Bruce 
Gerrit-Attention: Jason Lowe-Power 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: python: Add search functions to pystats groups

2021-03-01 Thread Jason Lowe-Power (Gerrit) via gem5-dev 
Jason Lowe-Power has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41603 )


Change subject: python: Add search functions to pystats groups
..

python: Add search functions to pystats groups

This change adds three functions, a `children` function which will
iterate through all of the children of group based (optionally) on some
predicate. Then, it implements a `find` function and a `find_re`
function using the `children` function.

The `find` function allows users to match statistics or groups
within a group. For instance, you might want to find all of the groups
within the system which have the name "cpu{i}". This is useful for
aggregate statistic values across multiple components.

Example:
total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
   for cpu in simstat.system.find('cpu')])

The find function matches based on substring. If the name given the find
function is a substring of the stat name or the group name the
stat/group will be returned.

The `find_re` function is the same as find, but matches a regular
expression instead of a simple substring match.

Change-Id: I31c2a029d8a6b1d97225ab4efa34a4d13147ea32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41603
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M src/python/m5/ext/pystats/group.py
1 file changed, 21 insertions(+), 1 deletion(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/python/m5/ext/pystats/group.py  
b/src/python/m5/ext/pystats/group.py

index 41a5633..10887e2 100644
--- a/src/python/m5/ext/pystats/group.py
+++ b/src/python/m5/ext/pystats/group.py
@@ -24,7 +24,7 @@
 # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-from typing import Dict, List, Optional, Union
+from typing import Dict, Iterator, List, Optional, Union

 from .jsonserializable import JsonSerializable
 from .statistic import Scalar, Statistic
@@ -53,6 +53,26 @@
 for key,value in kwargs.items():
 setattr(self, key, value)

+def find(self, name: str) -> Iterator[Union["Group", Statistic]]:
+""" Find all stats that match the name
+This function searches all of the "children" in this group. It  
yields
+the set of attributes (children) that have the `name` as a  
substring.

+The order of the objects returned by the generator is arbitrary.
+```
+system.find('cpu') -> [cpu0, cpu1, cpu2, cpu3, other_cpu, ...]
+```
+This is useful for performing aggregates over substats. For  
instance:

+```
+total_instruuctions = sum([cpu.exec_context.thread_0.numInsts.value
+   for cpu in simstat.system.find('cpu')])
+```
+"""
+for attr in self.__dict__:
+if name in attr:
+obj = getattr(self, attr)
+if isinstance(obj, Group) or isinstance(obj, Statistic):
+yield obj
+
 class Vector(Group):
 """
 The Vector class is used to store vector information. However, in gem5

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41603
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I31c2a029d8a6b1d97225ab4efa34a4d13147ea32
Gerrit-Change-Number: 41603
Gerrit-PatchSet: 6
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Jenkins build is back to normal : Weekly #10

2021-03-01 Thread jenkins-no-reply--- via gem5-dev 
See 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: configs: Ruby fixes for SimpleMemory

2021-03-01 Thread Gerrit 
Tiago Mück has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41817 )


Change subject: configs: Ruby fixes for SimpleMemory
..

configs: Ruby fixes for SimpleMemory

Change-Id: Idc21c8c616ef953d161685ec459765ef21ac9bc3
Signed-off-by: Tiago Mück 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41817
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M configs/ruby/Ruby.py
1 file changed, 6 insertions(+), 3 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/ruby/Ruby.py b/configs/ruby/Ruby.py
index 4779005..2bed341 100644
--- a/configs/ruby/Ruby.py
+++ b/configs/ruby/Ruby.py
@@ -1,4 +1,4 @@
-# Copyright (c) 2012, 2017-2018 ARM Limited
+# Copyright (c) 2012, 2017-2018, 2021 ARM Limited
 # All rights reserved.
 #
 # The license below extends only to copyright in the software and shall
@@ -131,13 +131,16 @@
 dram_intf = MemConfig.create_mem_intf(mem_type, r, index,
 options.num_dirs, int(math.log(options.num_dirs, 2)),
 intlv_size, options.xor_low_bit)
-mem_ctrl = m5.objects.MemCtrl(dram = dram_intf)
+if issubclass(mem_type, DRAMInterface):
+mem_ctrl = m5.objects.MemCtrl(dram = dram_intf)
+else:
+mem_ctrl = dram_intf

 if options.access_backing_store:
 dram_intf.kvm_map=False

 mem_ctrls.append(mem_ctrl)
-dir_ranges.append(mem_ctrl.dram.range)
+dir_ranges.append(dram_intf.range)

 if crossbar != None:
 mem_ctrl.port = crossbar.master



1 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the  
submitted one.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41817
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Idc21c8c616ef953d161685ec459765ef21ac9bc3
Gerrit-Change-Number: 41817
Gerrit-PatchSet: 3
Gerrit-Owner: Tiago Mück 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Tiago Mück 
Gerrit-Reviewer: kokoro 
Gerrit-CC: Giacomo Travaglini 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: renamed prefetch stats

2021-03-01 Thread Gerrit 
Tiago Mück has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41816 )


Change subject: mem-ruby: renamed prefetch stats
..

mem-ruby: renamed prefetch stats

Splitting hw_prefetches into prefetch_hits and prefetch_misses so both
events can be tracked separately. Also added appropriate functions to
increment stats. Renamed m_prefetches for consistency.

sw_prefetches is not used and has been removed. The sequencer converts
SW prefetch requests into a RubyRequestType_LD/RubyRequestType_ST
which are handled as demand requests by the all current protocols.

Change-Id: Iafa6b31c84843ddd1fad98fa7e5afed02b8c4b4d
Signed-off-by: Tiago Mück 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41816
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/mem/ruby/protocol/RubySlicc_Types.sm
M src/mem/ruby/structures/CacheMemory.cc
M src/mem/ruby/structures/CacheMemory.hh
3 files changed, 29 insertions(+), 12 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/mem/ruby/protocol/RubySlicc_Types.sm  
b/src/mem/ruby/protocol/RubySlicc_Types.sm

index c3a2f2d..e5ecb00 100644
--- a/src/mem/ruby/protocol/RubySlicc_Types.sm
+++ b/src/mem/ruby/protocol/RubySlicc_Types.sm
@@ -215,6 +215,8 @@

   void profileDemandHit();
   void profileDemandMiss();
+  void profilePrefetchHit();
+  void profilePrefetchMiss();
 }

 structure (WireBuffer, inport="yes", outport="yes", external = "yes") {
diff --git a/src/mem/ruby/structures/CacheMemory.cc  
b/src/mem/ruby/structures/CacheMemory.cc

index 8d98ef3..1436e9a 100644
--- a/src/mem/ruby/structures/CacheMemory.cc
+++ b/src/mem/ruby/structures/CacheMemory.cc
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2020 ARM Limited
+ * Copyright (c) 2020-2021 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -533,10 +533,10 @@
   ADD_STAT(m_demand_misses, "Number of cache demand misses"),
   ADD_STAT(m_demand_accesses, "Number of cache demand accesses",
m_demand_hits + m_demand_misses),
-  ADD_STAT(m_sw_prefetches, "Number of software prefetches"),
-  ADD_STAT(m_hw_prefetches, "Number of hardware prefetches"),
-  ADD_STAT(m_prefetches, "Number of prefetches",
-   m_sw_prefetches + m_hw_prefetches),
+  ADD_STAT(m_prefetch_hits, "Number of cache prefetch hits"),
+  ADD_STAT(m_prefetch_misses, "Number of cache prefetch misses"),
+  ADD_STAT(m_prefetch_accesses, "Number of cache prefetch accesses",
+   m_prefetch_hits + m_prefetch_misses),
   ADD_STAT(m_accessModeType, "")
 {
 numDataArrayReads
@@ -573,13 +573,13 @@
 .init(8)
 .flags(Stats::pdf | Stats::dist | Stats::nozero | Stats::nonan);

-m_sw_prefetches
+m_prefetch_hits
 .flags(Stats::nozero);

-m_hw_prefetches
+m_prefetch_misses
 .flags(Stats::nozero);

-m_prefetches
+m_prefetch_accesses
 .flags(Stats::nozero);

 m_accessModeType
@@ -747,3 +747,16 @@
 {
 cacheMemoryStats.m_demand_misses++;
 }
+
+void
+CacheMemory::profilePrefetchHit()
+{
+cacheMemoryStats.m_prefetch_hits++;
+}
+
+void
+CacheMemory::profilePrefetchMiss()
+{
+cacheMemoryStats.m_prefetch_misses++;
+}
+
diff --git a/src/mem/ruby/structures/CacheMemory.hh  
b/src/mem/ruby/structures/CacheMemory.hh

index 84b9d87..7b378f4 100644
--- a/src/mem/ruby/structures/CacheMemory.hh
+++ b/src/mem/ruby/structures/CacheMemory.hh
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2020 ARM Limited
+ * Copyright (c) 2020-2021 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -228,9 +228,9 @@
   Stats::Scalar m_demand_misses;
   Stats::Formula m_demand_accesses;

-  Stats::Scalar m_sw_prefetches;
-  Stats::Scalar m_hw_prefetches;
-  Stats::Formula m_prefetches;
+  Stats::Scalar m_prefetch_hits;
+  Stats::Scalar m_prefetch_misses;
+  Stats::Formula m_prefetch_accesses;

   Stats::Vector m_accessModeType;
   } cacheMemoryStats;
@@ -240,6 +240,8 @@
   // each time they are called
   void profileDemandHit();
   void profileDemandMiss();
+  void profilePrefetchHit();
+  void profilePrefetchMiss();
 };

 std::ostream& operator<<(std::ostream& out, const CacheMemory& obj);



1 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the  
submitted one.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41816
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Iafa6b31c84843ddd1fad98fa7e5afed02b8c4b4d
Gerrit-Change-Number: 418

[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: notify controller on coalescing

2021-03-01 Thread Gerrit 
Tiago Mück has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41815 )


Change subject: mem-ruby: notify controller on coalescing
..

mem-ruby: notify controller on coalescing

Sequencer notifies controllers when coalescing requests.
notifyCoalesced can be overridden by protocols to, for instance,
account for coalesced requests in hit/miss stats and/or prefetcher
training.

Change-Id: Ia9c8d64cac2cd3ce859a76a1dc1324e3fc6a7b90
Signed-off-by: Tiago Mück 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41815
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
Reviewed-by: Jason Lowe-Power 
---
M src/mem/ruby/slicc_interface/AbstractController.hh
M src/mem/ruby/system/Sequencer.cc
M src/mem/ruby/system/Sequencer.hh
3 files changed, 27 insertions(+), 9 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/mem/ruby/slicc_interface/AbstractController.hh  
b/src/mem/ruby/slicc_interface/AbstractController.hh

index 079bdd3..4b632db 100644
--- a/src/mem/ruby/slicc_interface/AbstractController.hh
+++ b/src/mem/ruby/slicc_interface/AbstractController.hh
@@ -137,6 +137,15 @@
 virtual void enqueuePrefetch(const Addr &, const RubyRequestType&)
 { fatal("Prefetches not implemented!");}

+//! Notifies controller of a request coalesced at the sequencer.
+//! By default, it does nothing. Behavior is protocol-specific
+virtual void notifyCoalesced(const Addr& addr,
+ const RubyRequestType& type,
+ const RequestPtr& req,
+ const DataBlock& data_blk,
+ const bool& was_miss)
+{ }
+
 //! Function for collating statistics from all the controllers of this
 //! particular type. This function should only be called from the
 //! version 0 of this controller type.
diff --git a/src/mem/ruby/system/Sequencer.cc  
b/src/mem/ruby/system/Sequencer.cc

index 0a80905..58cace6 100644
--- a/src/mem/ruby/system/Sequencer.cc
+++ b/src/mem/ruby/system/Sequencer.cc
@@ -473,19 +473,18 @@
 aliased_stores++;
 }
 markRemoved();
-ruby_request = false;
 hitCallback(&seq_req, data, success, mach, externalHit,
 initialRequestTime, forwardRequestTime,
-firstResponseTime);
+firstResponseTime, !ruby_request);
+ruby_request = false;
 } else {
 // handle read request
 assert(!ruby_request);
 markRemoved();
-ruby_request = false;
 aliased_loads++;
 hitCallback(&seq_req, data, true, mach, externalHit,
 initialRequestTime, forwardRequestTime,
-firstResponseTime);
+firstResponseTime, !ruby_request);
 }
 seq_req_list.pop_front();
 }
@@ -538,10 +537,10 @@
   firstResponseTime);
 }
 markRemoved();
-ruby_request = false;
 hitCallback(&seq_req, data, true, mach, externalHit,
 initialRequestTime, forwardRequestTime,
-firstResponseTime);
+firstResponseTime, !ruby_request);
+ruby_request = false;
 seq_req_list.pop_front();
 }

@@ -557,7 +556,8 @@
const MachineType mach, const bool externalHit,
const Cycles initialRequestTime,
const Cycles forwardRequestTime,
-   const Cycles firstResponseTime)
+   const Cycles firstResponseTime,
+   const bool was_coalesced)
 {
 warn_once("Replacement policy updates recently became the  
responsibility "
   "of SLICC state machines. Make sure to setMRU() near  
callbacks "

@@ -567,6 +567,14 @@
 Addr request_address(pkt->getAddr());
 RubyRequestType type = srequest->m_type;

+if (was_coalesced) {
+// Notify the controller about a coalesced request so it can  
properly

+// account for it in its hit/miss stats and/or train prefetchers
+// (this is protocol-dependent)
+m_controller->notifyCoalesced(request_address, type, pkt->req,
+  data, externalHit);
+}
+
 // Load-linked handling
 if (type == RubyRequestType_Load_Linked) {
 Addr line_addr = makeLineAddress(request_address);
diff --git a/src/mem/ruby/system/Sequencer.hh  
b/src/mem/ruby/system/Sequencer.hh

index 904d764..d8ffb86 100644
--- a/src/mem/ruby/system/Sequencer.hh
+++ b/src/mem/ruby/system/Sequencer.hh
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2019-2020 ARM Limited
+ * Copyright (c) 2019-2021 ARM Limited
  * All rights re

[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: fix MI_example functional read

2021-03-01 Thread Gerrit 
Tiago Mück has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41853 )


Change subject: mem-ruby: fix MI_example functional read
..

mem-ruby: fix MI_example functional read

Changing AccessPermission to Read_Write for transient states waiting
on memory when to or from Invalid. In all cases the memory will have
the latest data, so this also modifies functionalRead to always send
the access to memory.

Change-Id: I99f557539b4f9d0d2f99558752b7ddb7e85ab3c6
Signed-off-by: Tiago Mück 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41853
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/mem/ruby/protocol/MI_example-dir.sm
1 file changed, 25 insertions(+), 12 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/mem/ruby/protocol/MI_example-dir.sm  
b/src/mem/ruby/protocol/MI_example-dir.sm

index ed315e8..11d2862 100644
--- a/src/mem/ruby/protocol/MI_example-dir.sm
+++ b/src/mem/ruby/protocol/MI_example-dir.sm
@@ -1,4 +1,16 @@
 /*
+ * Copyright (c) 2021 ARM Limited
+ * All rights reserved.
+ *
+ * The license below extends only to copyright in the software and shall
+ * not be construed as granting a license to any other intellectual
+ * property including but not limited to intellectual property relating
+ * to a hardware implementation of the functionality of the software
+ * licensed hereunder.  You may use the software subject to the license
+ * terms below provided that you ensure that this notice is replicated
+ * unmodified and in its entirety in all distributions of the software,
+ * modified or unmodified, in source code or in binary form.
+ *
  * Copyright (c) 2009-2012 Mark D. Hill and David A. Wood
  * Copyright (c) 2010-2012 Advanced Micro Devices, Inc.
  * All rights reserved.
@@ -56,13 +68,17 @@
 M_DRD, AccessPermission:Busy, desc="Blocked on an invalidation for a  
DMA read";
 M_DWR, AccessPermission:Busy, desc="Blocked on an invalidation for a  
DMA write";


-M_DWRI, AccessPermission:Busy, desc="Intermediate state M_DWR-->I";
-M_DRDI, AccessPermission:Busy, desc="Intermediate state M_DRD-->I";
+M_DWRI, AccessPermission:Read_Write, desc="Intermediate state  
M_DWR-->I";
+M_DRDI, AccessPermission:Read_Write, desc="Intermediate state  
M_DRD-->I";


-IM, AccessPermission:Busy, desc="Intermediate state I-->M";
-MI, AccessPermission:Busy, desc="Intermediate state M-->I";
-ID, AccessPermission:Busy, desc="Intermediate state for DMA_READ when  
in I";
-ID_W, AccessPermission:Busy, desc="Intermediate state for DMA_WRITE  
when in I";

+IM, AccessPermission:Read_Write, desc="Intermediate state I-->M";
+MI, AccessPermission:Read_Write, desc="Intermediate state M-->I";
+ID, AccessPermission:Read_Write, desc="Intermediate state for DMA_READ  
when in I";
+ID_W, AccessPermission:Read_Write, desc="Intermediate state for  
DMA_WRITE when in I";

+
+// Note: busy states when we wait for memory in transitions from or  
to 'I'
+// have AccessPermission:Read_Write so this controller can get the  
latest

+// data from memory during a functionalRead
   }

   // Events
@@ -180,12 +196,9 @@
   }

   void functionalRead(Addr addr, Packet *pkt) {
-TBE tbe := TBEs[addr];
-if(is_valid(tbe)) {
-  testAndRead(addr, tbe.DataBlk, pkt);
-} else {
-  functionalMemoryRead(pkt);
-}
+// if this is called; state is always either invalid or data was just  
been WB

+// to memory (and we are waiting for an ack), so go directly to memory
+functionalMemoryRead(pkt);
   }

   int functionalWrite(Addr addr, Packet *pkt) {

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41853
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I99f557539b4f9d0d2f99558752b7ddb7e85ab3c6
Gerrit-Change-Number: 41853
Gerrit-PatchSet: 2
Gerrit-Owner: Tiago Mück 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Tiago Mück 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 v21.0.0.0 Staging branch created

2021-03-01 Thread Bobby Bruce via gem5-dev 
It wouldn't be a gem5 release email without one embarrassing/confusing
typo. :)

Yes, we will be running many rigorous tests across our benchmark suite!
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Mar 1, 2021 at 10:31 AM Jason Lowe-Power 
wrote:

> I assume you mean "**NOW** begin running rigorous tests" ;)
>
> Cheers,
> Jason
>
> On Mon, Mar 1, 2021 at 10:27 AM Bobby Bruce via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Dear all,
>>
>> As of 10:30AM PST the gem5 Staging Branch for gem5 v21.0.0.0 has been
>> created from the gem5 develop branch. We will not begin running rigorous
>> tests on this branch to ensure the upcoming release is as stable and
>> bug-free as possible. After this we will merge the release branch into the
>> stable branch, thus officially releasing gem5.
>>
>> In line with our contribution guidelines (
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/CONTRIBUTING.md),
>> we permit alterations to be submitted to this staging branch though
>> these should strictly be "last-minute" bug fixes, stability improvements,
>> and small alterations that will not affect the functionality of the
>> codebase (documentation/README improvements, etc.). All other changes
>> should continue to be submitted to the gem5 develop branch. The staging
>> branch will be periodically merged into the develop branch so bug fixes
>> etc. are available to developers working on the develop branch.
>>
>> We would like to thank everyone for the contributions made over the past
>> few months. This release would not be possible without your efforts.
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 v21.0.0.0 Staging branch created

2021-03-01 Thread Jason Lowe-Power via gem5-dev 
I assume you mean "**NOW** begin running rigorous tests" ;)

Cheers,
Jason

On Mon, Mar 1, 2021 at 10:27 AM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> As of 10:30AM PST the gem5 Staging Branch for gem5 v21.0.0.0 has been
> created from the gem5 develop branch. We will not begin running rigorous
> tests on this branch to ensure the upcoming release is as stable and
> bug-free as possible. After this we will merge the release branch into the
> stable branch, thus officially releasing gem5.
>
> In line with our contribution guidelines (
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/CONTRIBUTING.md),
> we permit alterations to be submitted to this staging branch though these
> should strictly be "last-minute" bug fixes, stability improvements, and
> small alterations that will not affect the functionality of the codebase
> (documentation/README improvements, etc.). All other changes should
> continue to be submitted to the gem5 develop branch. The staging branch
> will be periodically merged into the develop branch so bug fixes etc. are
> available to developers working on the develop branch.
>
> We would like to thank everyone for the contributions made over the past
> few months. This release would not be possible without your efforts.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 v21.0.0.0 Staging branch created

2021-03-01 Thread Bobby Bruce via gem5-dev 
Dear all,

As of 10:30AM PST the gem5 Staging Branch for gem5 v21.0.0.0 has been
created from the gem5 develop branch. We will not begin running rigorous
tests on this branch to ensure the upcoming release is as stable and
bug-free as possible. After this we will merge the release branch into the
stable branch, thus officially releasing gem5.

In line with our contribution guidelines (
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/CONTRIBUTING.md),
we permit alterations to be submitted to this staging branch though these
should strictly be "last-minute" bug fixes, stability improvements, and
small alterations that will not affect the functionality of the codebase
(documentation/README improvements, etc.). All other changes should
continue to be submitted to the gem5 develop branch. The staging branch
will be periodically merged into the develop branch so bug fixes etc. are
available to developers working on the develop branch.

We would like to thank everyone for the contributions made over the past
few months. This release would not be possible without your efforts.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: gpu-compute: Explicitly set driver to nullptr in constructor

2021-03-01 Thread Bobby R. Bruce (Gerrit) via gem5-dev 
Bobby R. Bruce has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/41973 )


Change subject: gpu-compute: Explicitly set driver to nullptr in constructor
..

gpu-compute: Explicitly set driver to nullptr in constructor

We have a fail_if in attachDriver to prevent driver from being
overwritten. However, the fail_if only checks for if the driver
is not nullptr.

Previously, in some cases driver was set to garbage, which made
the fail_if trip the first time we were assigning the driver.

This patch explicitly sets driver to nullptr in the constructor, thus
ensuring that it will be nullptr the first time we call attachDriver

Change-Id: I325f6033e785025a912e3af3888c66cee0332f40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41973
Reviewed-by: Matt Sinclair 
Maintainer: Matt Sinclair 
Tested-by: kokoro 
---
M src/gpu-compute/gpu_command_processor.cc
1 file changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Matt Sinclair: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/gpu-compute/gpu_command_processor.cc  
b/src/gpu-compute/gpu_command_processor.cc

index da21076..5a9bbd5 100644
--- a/src/gpu-compute/gpu_command_processor.cc
+++ b/src/gpu-compute/gpu_command_processor.cc
@@ -42,7 +42,7 @@
 #include "sim/syscall_emul_buf.hh"

 GPUCommandProcessor::GPUCommandProcessor(const Params &p)
-: HSADevice(p), dispatcher(*p.dispatcher)
+: HSADevice(p), dispatcher(*p.dispatcher), driver(nullptr)
 {
 dispatcher.setCommandProcessor(this);
 }

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/41973
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I325f6033e785025a912e3af3888c66cee0332f40
Gerrit-Change-Number: 41973
Gerrit-PatchSet: 3
Gerrit-Owner: Kyle Roarty 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: Matthew Poremba 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: cpu: Adding stridedGen

2021-03-01 Thread Mahyar Samani (Gerrit) via gem5-dev 
Mahyar Samani has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/40515 )


Change subject: cpu: Adding stridedGen
..

cpu: Adding stridedGen

This patch adds the source code for a mode of traffic generator to
generate strided access pattern to the memory. The main difference
between a stridedGen and linearGen are in the way startAddr and
nextAddr are set. In stridedGen instead of increasing the current
address by blocksize to generate nextAddr, it is increased by
strideSize. Also, the offset param is used to indicate the order
of any instances of traffic generator in an array (similar to
threadId.x in CUDA)

Change-Id: I80df414faf1c73f68e87400654675a553de0caa5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40515
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
Reviewed-by: Jason Lowe-Power 
---
M src/cpu/testers/traffic_gen/PyTrafficGen.py
M src/cpu/testers/traffic_gen/SConscript
M src/cpu/testers/traffic_gen/base.cc
M src/cpu/testers/traffic_gen/base.hh
A src/cpu/testers/traffic_gen/strided_gen.cc
A src/cpu/testers/traffic_gen/strided_gen.hh
6 files changed, 269 insertions(+), 0 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/testers/traffic_gen/PyTrafficGen.py  
b/src/cpu/testers/traffic_gen/PyTrafficGen.py

index 962f8e0..baf4ef5 100644
--- a/src/cpu/testers/traffic_gen/PyTrafficGen.py
+++ b/src/cpu/testers/traffic_gen/PyTrafficGen.py
@@ -60,6 +60,7 @@
 PyBindMethod("createDramRot"),
 PyBindMethod("createHybrid"),
 PyBindMethod("createNvm"),
+PyBindMethod("createStrided")
 ]

 @cxxMethod(override=True)
diff --git a/src/cpu/testers/traffic_gen/SConscript  
b/src/cpu/testers/traffic_gen/SConscript

index 987ed67..640d81a 100644
--- a/src/cpu/testers/traffic_gen/SConscript
+++ b/src/cpu/testers/traffic_gen/SConscript
@@ -49,6 +49,7 @@
 Source('nvm_gen.cc')
 Source('random_gen.cc')
 Source('stream_gen.cc')
+Source('strided_gen.cc')

 DebugFlag('TrafficGen')
 SimObject('BaseTrafficGen.py')
diff --git a/src/cpu/testers/traffic_gen/base.cc  
b/src/cpu/testers/traffic_gen/base.cc

index 320de92..3c28d00 100644
--- a/src/cpu/testers/traffic_gen/base.cc
+++ b/src/cpu/testers/traffic_gen/base.cc
@@ -51,6 +51,7 @@
 #include "cpu/testers/traffic_gen/nvm_gen.hh"
 #include "cpu/testers/traffic_gen/random_gen.hh"
 #include "cpu/testers/traffic_gen/stream_gen.hh"
+#include "cpu/testers/traffic_gen/strided_gen.hh"
 #include "debug/Checkpoint.hh"
 #include "debug/TrafficGen.hh"
 #include "enums/AddrMap.hh"
@@ -520,6 +521,22 @@
 }

 std::shared_ptr
+BaseTrafficGen::createStrided(Tick duration,
+ Addr start_addr, Addr end_addr, Addr  
blocksize,

+ Addr stride_size, int gen_id,
+ Tick min_period, Tick max_period,
+ uint8_t read_percent, Addr data_limit)
+{
+return std::shared_ptr(new StridedGen(*this, requestorId,
+  duration, start_addr,
+  end_addr, blocksize,
+  system->cacheLineSize(),
+  stride_size, gen_id,
+  min_period, max_period,
+  read_percent,  
data_limit));

+}
+
+std::shared_ptr
 BaseTrafficGen::createTrace(Tick duration,
 const std::string& trace_file, Addr  
addr_offset)

 {
diff --git a/src/cpu/testers/traffic_gen/base.hh  
b/src/cpu/testers/traffic_gen/base.hh

index 018028b..a1a1efc 100644
--- a/src/cpu/testers/traffic_gen/base.hh
+++ b/src/cpu/testers/traffic_gen/base.hh
@@ -314,6 +314,13 @@
 Enums::AddrMap addr_mapping,
 unsigned int nbr_of_ranks);

+std::shared_ptr createStrided(
+Tick duration,
+Addr start_addr, Addr end_addr, Addr blocksize,
+Addr stride_size, int gen_id,
+Tick min_period, Tick max_period,
+uint8_t read_percent, Addr data_limit);
+
 std::shared_ptr createTrace(
 Tick duration,
 const std::string& trace_file, Addr addr_offset);
diff --git a/src/cpu/testers/traffic_gen/strided_gen.cc  
b/src/cpu/testers/traffic_gen/strided_gen.cc

new file mode 100644
index 000..0b77872
--- /dev/null
+++ b/src/cpu/testers/traffic_gen/strided_gen.cc
@@ -0,0 +1,113 @@
+/*
+ * Copyright (c) 2012-2013, 2016-2017 ARM Limited
+ * All rights reserved
+ *
+ * The license below extends only to copyright in the software and shall
+ * not be construed as granting a license to any other intellectual
+ * property including but not limited to intellectual property relating
+ * to a hardware implementation of the functionality of the software
+ * lice

[gem5-dev] Re: de-templating the O3 CPU

2021-03-01 Thread Jason Lowe-Power via gem5-dev 
Hey Gabe,

I love this idea! It would be nice if you could document the code as you
go, too. It could serve as a good learning tool in the future.

Cheers,
Jason

On Mon, Mar 1, 2021 at 7:56 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> +2, +1, Merged
>
> 😊
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev 
> > Sent: 27 February 2021 10:13
> > To: gem5 Developer List 
> > Cc: Gabe Black 
> > Subject: [gem5-dev] de-templating the O3 CPU
> >
> > Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to
> make it
> > possible to switch in different parts of the CPU to change how, for
> example, a
> > pipeline stage is implemented.
> >
> > Realistically, the different parts of the CPU are probably too
> interdependent
> > for that to actually work, and all the templates and indirection make
> the code a
> > lot more complicated than it really needs to be.
> >
> > Also, there is a pseudo-generic dynamic instruction base class in
> > cpu/base_dyn_inst.hh which could, again theoretically, be used as a base
> class
> > for other CPUs to reuse. Unfortunately that too is probably too tied to
> its only
> > consumer, the O3 CPU, to be realistically reusable.
> >
> > I would like to merge the base dynamic instruction class into the O3
> version,
> > and then de-templatize the whole O3 CPU. I think that will make the code
> a lot
> > easier to work on, and I think our ability to maintain and update O3 is
> > something we need to improve in at least the medium term.
> >
> > Any thoughts? Objections? Votes of support?
> >
> > Gabe
> 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.
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: de-templating the O3 CPU

2021-03-01 Thread Giacomo Travaglini via gem5-dev 
+2, +1, Merged

😊

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 27 February 2021 10:13
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] de-templating the O3 CPU
>
> Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to make 
> it
> possible to switch in different parts of the CPU to change how, for example, a
> pipeline stage is implemented.
>
> Realistically, the different parts of the CPU are probably too interdependent
> for that to actually work, and all the templates and indirection make the 
> code a
> lot more complicated than it really needs to be.
>
> Also, there is a pseudo-generic dynamic instruction base class in
> cpu/base_dyn_inst.hh which could, again theoretically, be used as a base class
> for other CPUs to reuse. Unfortunately that too is probably too tied to its 
> only
> consumer, the O3 CPU, to be realistically reusable.
>
> I would like to merge the base dynamic instruction class into the O3 version,
> and then de-templatize the whole O3 CPU. I think that will make the code a lot
> easier to work on, and I think our ability to maintain and update O3 is
> something we need to improve in at least the medium term.
>
> Any thoughts? Objections? Votes of support?
>
> Gabe
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.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: vector register indexing modes and renaming?

2021-03-01 Thread Giacomo Travaglini via gem5-dev 


> -Original Message-
> From: Gabe Black 
> Sent: 27 February 2021 05:47
> To: Giacomo Travaglini 
> Cc: gem5 Developer List 
> Subject: Re: [gem5-dev] vector register indexing modes and renaming?
>
> Another question/clarification:
>
> Does any data actually get shared between the two rename modes? I think you
> said there is not, but now I can't find that.

Data *do* get shared, even if in gem5 we have separate physical registers.
In fact, when rename mode changes [1], (meta)data is copied from one register 
file to the other.
For example, say we have an AArch64 kernel running at EL1 and my AArch32 
(basically armv7) floating point application running at EL0.

My application will be using vector elements; however, every time there is an 
exception to AArch64, cpu will switch
Rename mode and data will be copied / mapping will be adjusted. Any FP & SIMD 
operation at this point will use vector registers.
When the kernel finishes its stuff, and goes back to AArch32, vector elements 
will be repopulated.

> Would it work just as well to have
> two register files which operate entirely independently?

As I mentioned before, they operate independently, but they sync up when we 
pass from one mode
To the other. Another way to look at it is that they are mutually exclusive.

> From what I can tell
> the "V" registers of Neon in aarch64 overlap with the SVE registers, and the 
> "Q"
> registers of armv7 Neon overlap with the "S", "D", "Q" registers of the same,
> but I think "V" and "Q" are independent? Maybe reused but not guaranteed to
> alias?
>

I would say the rule of thumb for understanding AArch64-AArch32 mapping (and 
it's the underlying cause of using different renaming modes) is to bear in mind 
that AArch64, differently from AArch32, uses an unpacked approach for FP & SIMD 
registers.
Prior to Armv8, smaller FP registers were packed into bigger registers [2]. 
Having for example 32 double precision registers (D0-D31) meant having a 
maximum of 16 quad word registers (Q0-Q15).
This setup has been abandoned in Armv8 [3]. As an example, S1, or D1 are not 
packed anymore in Q0. Those are in fact the 32/64 LSBits of Q1.
This means the newly added (V16-V31) are not accessible in AArch32.

So to answer your question regarding V and Q. Until Q/V15, they alias 
perfectly; V16-V31 are simply not
Defined/accessible in AArch32 so they are not aliased.

All AArch32 SIMD data is accessible from AArch64. It just won't stick to the 
same naming. AArch32 D1 and AArch64 D1 hold different data.
If I really wanted to access AArch32 D1 from AArch64 I would have to read the 
64 MSB of V0. This is a software and not an hardware problem (I just posted 
this example to stress the difference between aliasing and reachability)

> BTW, test cases would be very helpful if possible. I've made good progress
> cleaning away debris and am getting to the point where I'll want to make
> changes which I'm a lot less comfortable making blind.
>
> Gabe
>
> On Thu, Feb 25, 2021 at 10:40 PM Gabe Black   > wrote:
>
>
> I will ask within Arm if there's something we can
> provide to you.
> In the meantime I gave a quick look at NEON enabled
> libraries [1]; the Ne10 library provides a set of functions optimized for NEON
> and a set
> of examples making use of it [2] (e.g FIR filter, GEMM
> etc etc).
>
> You could probably cross-compile those examples and
> use them in SE mode (recommending to use the O3 model)
>
>
>
>
> Ok, thanks, I'll take a look. This might even be something we
> want in the testing infrastructure? I might look into that when I have a 
> chance.
>
>
> I took a look at this, and unfortunately I don't think I can use it. The
> example only builds for armv7 and not aarch64, and when I tried to build it 
> for
> armv7 I get a bunch of compiler errors. Do you have any other suggestions?

Richard kindly pointed me to the following SVE tutorial:

https://gitlab.com/arm-hpc/training/arm-sve-tools

But I believe it is worth noting we are actually interested on testing armv7 
(AArch32) SIMD as well, so that won't probably be enough.
I will dig more, and I will keep you posted

>
> Gabe

Kind Regards

Giacomo

[1]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/rename_map.cc#L173
[2]: 
https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/NEON-and-floating-point-registers/NEON-in-AArch32-execution-state-
[3]: 
https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/NEON-and-floating-point-registers/Floating-point-register-organization-in-AArch64


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.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe

[gem5-dev] Re: de-templating the O3 CPU

2021-03-01 Thread Gabe Black via gem5-dev 
Hi Nathanael, I intend to split it into multiple steps, if nothing else
just to make reviewing the changes more feasible.

Gabe

On Mon, Mar 1, 2021 at 1:51 AM Nathanael Premillieu <
nathanael.premill...@huawei.com> wrote:

> Hi Gabe,
>
>
>
> I totally agree with you on this.
>
> I think it’s also quite a blocker when learning gem5 as it makes the code
> difficult to follow and understand.
>
> Do you intend to do it as one big patch or split that into several steps
> (if that’s possible)?
>
>
>
> Thanks,
>
> Nathanael
>
>
>
> *From:* Gabe Black via gem5-dev [mailto:gem5-dev@gem5.org]
> *Sent:* Saturday, February 27, 2021 11:13 AM
> *To:* gem5 Developer List 
> *Cc:* Gabe Black 
> *Subject:* [gem5-dev] de-templating the O3 CPU
>
>
>
> Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to
> make it possible to switch in different parts of the CPU to change how, for
> example, a pipeline stage is implemented.
>
>
>
> Realistically, the different parts of the CPU are probably too
> interdependent for that to actually work, and all the templates and
> indirection make the code a lot more complicated than it really needs to be.
>
>
>
> Also, there is a pseudo-generic dynamic instruction base class in
> cpu/base_dyn_inst.hh which could, again theoretically, be used as a base
> class for other CPUs to reuse. Unfortunately that too is probably too tied
> to its only consumer, the O3 CPU, to be realistically reusable.
>
>
>
> I would like to merge the base dynamic instruction class into the O3
> version, and then de-templatize the whole O3 CPU. I think that will make
> the code a lot easier to work on, and I think our ability to maintain and
> update O3 is something we need to improve in at least the medium term.
>
>
>
> Any thoughts? Objections? Votes of support?
>
>
>
> Gabe
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: de-templating the O3 CPU

2021-03-01 Thread Nathanael Premillieu via gem5-dev 
Hi Gabe,

I totally agree with you on this.
I think it’s also quite a blocker when learning gem5 as it makes the code 
difficult to follow and understand.
Do you intend to do it as one big patch or split that into several steps (if 
that’s possible)?

Thanks,
Nathanael

From: Gabe Black via gem5-dev [mailto:gem5-dev@gem5.org]
Sent: Saturday, February 27, 2021 11:13 AM
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] de-templating the O3 CPU

Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to make 
it possible to switch in different parts of the CPU to change how, for example, 
a pipeline stage is implemented.

Realistically, the different parts of the CPU are probably too interdependent 
for that to actually work, and all the templates and indirection make the code 
a lot more complicated than it really needs to be.

Also, there is a pseudo-generic dynamic instruction base class in 
cpu/base_dyn_inst.hh which could, again theoretically, be used as a base class 
for other CPUs to reuse. Unfortunately that too is probably too tied to its 
only consumer, the O3 CPU, to be realistically reusable.

I would like to merge the base dynamic instruction class into the O3 version, 
and then de-templatize the whole O3 CPU. I think that will make the code a lot 
easier to work on, and I think our ability to maintain and update O3 is 
something we need to improve in at least the medium term.

Any thoughts? Objections? Votes of support?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s