[gem5-users] Re: CHi - assertion error when modelling "mostly inclusive" for private L2$

[Javed Osmany via gem5-users]

Hello

I have been debugging the assertion failure when the L3$ (residing in the HNF) 
clusivity = Mostly Exclusive.

All the failures are related when the config being modelled is L2$ for all CPUs 
is private & [L2$, L3$] clusivity == [Mostly Inclusive, Mostly_Exclusive].

Enabling some debug flags, a snippet of the trace at the failure point being:

12180159000: RubyGenerated: system.cpu2.l2: executing Pop_TriggerQueue
12180159000: RubyGenerated: system.cpu2.l2: executing Send_Data
12180159000: RubyGenerated: system.cpu2.l2: executing 
ProcessNextState_ClearPending
12180159000: RubyGenerated: system.cpu2.l2: next_state: BUSY_BLKD
ProtocolTrace: 12180159000  18  Cache TX_Data 
BUSY_BLKD>BUSY_BLKD [0xab040, line 0xab040]
ProtocolTrace: 12180159000   7Seq   Begin   >   
[0x24db90, line 0x24db80] LD
1218016: RubyGenerated: system.ruby.hnf1.cntrl: [Cache_Controller 25], 
Time: 24360320, state: BUSY_BLKD, event: CompAck, addr: 0xab040
1218016: RubyGenerated: system.ruby.hnf1.cntrl: executing Receive_ReqResp
1218016: RubyGenerated: system.ruby.hnf1.cntrl: executing 
UpdateDirState_FromReqResp
build/ARM/mem/ruby/protocol/Cache_Controller.cc:5477: panic: Runtime Error at 
CHI-cache-actions.sm:1947: assert failure.

Looking at around line 1947 in CHI-cache-actions.sm:

action(UpdateDirState_FromReqResp, desc="") { <== HNF1 cache controller 
executing this cache action
  peek(rspInPort, CHIResponseMsg) {
if ((in_msg.type == CHIResponseType:CompAck) && tbe.updateDirOnCompAck) {
  assert(tbe.requestor == in_msg.responder);

  tbe.dir_sharers.add(in_msg.responder);

  if (tbe.requestorToBeOwner) {
assert(tbe.dataMaybeDirtyUpstream);
assert(tbe.dir_ownerExists == false);
assert(tbe.requestorToBeExclusiveOwner == false);
tbe.dir_owner := in_msg.responder;
tbe.dir_ownerExists := true;
tbe.dir_ownerIsExcl := false;

  } else if (tbe.requestorToBeExclusiveOwner) {
assert(tbe.dataMaybeDirtyUpstream);
assert(tbe.dir_ownerExists == false);
assert(tbe.dir_sharers.count() == 1); <== Line 1947
tbe.dir_owner := in_msg.responder;
tbe.dir_ownerExists := true;
tbe.dir_ownerIsExcl := true;
  }
}
  }
  printTBEState(tbe);
}

So the problem _seems_ to be related to updating the directory state within 
HNF1.
The L2$ wants to make the requested cache line to be exclusive. Thus 
dir_sharers.count should be zero (as the cache line now only resides in a 
single L2$).

QS: Is this possibly a CHI bug?

P.S : I have also attached the gzipped version of the log file.

Tks

JO


From: Javed Osmany
Sent: 22 April 2022 12:05
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: CHi - assertion error when modelling "mostly inclusive" for 
private L2$

Hello

An update on my previous email...

Have been simulating the multicore system with Parsec/Splash2 benchmarks for 
different permutations of clusivity for L2$ and L3$. The results being in the 
following table. Note, by L3$, I mean the L3$ within the HNF

L2$ clusivity

L3$ clusivity

Comments

Strict Inclusive (sincl) (default)

Mostly inclusive (mincl) (default)

All tests complete okay

mincl

mincl

All tests complete okay

mincl

Mostly exclusive (mexcl)

10 tests abort with the assertion failure

sincl

mexcl

10 tests abort with the assertion failure


>From the above, the deduction being that setting L3$ clusivity to mostly 
>exclusive would be the cause of the problem.
The definition of mostly_inclusive (defined by default for the HNFCache 
controller in CHI_config.py) and mostly_exclusive (based on the write up @ 
https://www.gem5.org/documentation/general_docs/ruby/CHI/ and my understanding 
being that the L3$ now becomes a victim cache of the L2$) that I have used 
being:



mostly inclusive

mostly exclusive

comments

alloc_on_seq_acc

False

False



alloc_on_seq_line_write

False

False



alloc_on_readshared

True

False



alloc_on_readunique

False

False



alloc_on_readonce

True

False



alloc_on_writeback

True

True

For the L3$, writebacks and evictions being the mechanism of allocating a cache 
line

dealloc_on_unique

True

True

Upstream $line becomes unique, then deallocate from L3$

dealloc_on_shared

False

True

Upstream $line becomes shared, then deallocate from L3$

dealloc_backinv_unique

False

False

If the L3$ line is deallocated due to replacement, then don't back invalidate 
the upstream cache line.

dealloc_backinv_shared

False

False

If the L3$ line is deallocated due to replacement, then don't back invalidate 
the upstream cache line.











Any insight as to why the above encoding for mostly exclusive might be wrong 
and thus causing the assertions to fire, would be greatly appreciated.

Thanks in advance
JO



From: Javed Osmany
Sent: 21 April 2022 16:03
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Javed Osmany 

[gem5-users] Re: CHi - assertion error when modelling "mostly inclusive" for private L2$

[Javed Osmany via gem5-users]

Hello

An update on my previous email...

Have been simulating the multicore system with Parsec/Splash2 benchmarks for 
different permutations of clusivity for L2$ and L3$. The results being in the 
following table. Note, by L3$, I mean the L3$ within the HNF

L2$ clusivity

L3$ clusivity

Comments

Strict Inclusive (sincl) (default)

Mostly inclusive (mincl) (default)

All tests complete okay

mincl

mincl

All tests complete okay

mincl

Mostly exclusive (mexcl)

10 tests abort with the assertion failure

sincl

mexcl

10 tests abort with the assertion failure


>From the above, the deduction being that setting L3$ clusivity to mostly 
>exclusive would be the cause of the problem.
The definition of mostly_inclusive (defined by default for the HNFCache 
controller in CHI_config.py) and mostly_exclusive (based on the write up @ 
https://www.gem5.org/documentation/general_docs/ruby/CHI/ and my understanding 
being that the L3$ now becomes a victim cache of the L2$) that I have used 
being:



mostly inclusive

mostly exclusive

comments

alloc_on_seq_acc

False

False



alloc_on_seq_line_write

False

False



alloc_on_readshared

True

False



alloc_on_readunique

False

False



alloc_on_readonce

True

False



alloc_on_writeback

True

True

For the L3$, writebacks and evictions being the mechanism of allocating a cache 
line

dealloc_on_unique

True

True

Upstream $line becomes unique, then deallocate from L3$

dealloc_on_shared

False

True

Upstream $line becomes shared, then deallocate from L3$

dealloc_backinv_unique

False

False

If the L3$ line is deallocated due to replacement, then don't back invalidate 
the upstream cache line.

dealloc_backinv_shared

False

False

If the L3$ line is deallocated due to replacement, then don't back invalidate 
the upstream cache line.











Any insight as to why the above encoding for mostly exclusive might be wrong 
and thus causing the assertions to fire, would be greatly appreciated.

Thanks in advance
JO



From: Javed Osmany
Sent: 21 April 2022 16:03
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: CHi - assertion error when modelling "mostly inclusive" for private L2$

Hello

I am simulating a multicore Ruby system using CHI, using the Parsec/Splash2 
benchmarks & gem5-21.2.1.0.
It consists of three clusters :

1)  Little cluster of 4 CPUs, each CPU has private L1$ and L2$

2)  Middle cluster of 3 CPUs, each CPU has private L1$ and L2$

3)  Big cluster of 1 CPU with private L1$ and L2$.

By default, the L2$ and L3$ (residing in the HNF) have their clusivity set to 
strict_inclusive and mostly_inclusive respectively (CHI_config.py):

class CHI_L2Controller(CHI_Cache_Controller):
'''
Default parameters for a L2 Cache controller
'''

def __init__(self, ruby_system, cache, l2_clusivity, prefetcher):
super(CHI_L2Controller, self).__init__(ruby_system)
self.sequencer = NULL
self.cache = cache
self.use_prefetcher = False
self.allow_SD = True
self.is_HN = False
self.enable_DMT = False
self.enable_DCT = False
self.send_evictions = False
# Strict inclusive MOESI
 self.alloc_on_seq_acc = False
 self.alloc_on_seq_line_write = False
 self.alloc_on_readshared = True
 self.alloc_on_readunique = True
 self.alloc_on_readonce = True
 self.alloc_on_writeback = True
 self.dealloc_on_unique = False
 self.dealloc_on_shared = False
 self.dealloc_backinv_unique = True
 self.dealloc_backinv_shared = True

class CHI_HNFController(CHI_Cache_Controller):
'''
Default parameters for a coherent home node (HNF) cache controller
'''

#def __init__(self, ruby_system, cache, prefetcher, addr_ranges):
def __init__(self, ruby_system, cache, prefetcher, addr_ranges, 
hnf_enable_dmt, hnf_enable_dct, \
 num_tbe, num_repl_tbe, num_snp_tbe, unified_repl_tbe, 
l3_clusivity):
super(CHI_HNFController, self).__init__(ruby_system)
self.sequencer = NULL
self.cache = cache
self.use_prefetcher = False
self.addr_ranges = addr_ranges
self.allow_SD = True
self.is_HN = True
#self.enable_DMT = True
#self.enable_DCT = True
self.enable_DMT = hnf_enable_dmt
self.enable_DCT = hnf_enable_dct
self.send_evictions = False
# MOESI / Mostly inclusive for shared / Exclusive for unique
self.alloc_on_seq_acc = False
self.alloc_on_seq_line_write = False
self.alloc_on_readshared = True
self.alloc_on_readunique = False
self.alloc_on_readonce = True
self.alloc_on_writeback = True
self.dealloc_on_unique = True
self.dealloc_on_shared = False
self.dealloc_backinv_unique = False
self.dealloc_backinv_shared = False

The simulations complete okay for the default clusivity of L2$ and L3$.
However, if I change the 

[gem5-users] CHi - assertion error when modelling "mostly inclusive" for private L2$

[Javed Osmany via gem5-users]

Hello

I am simulating a multicore Ruby system using CHI, using the Parsec/Splash2 
benchmarks & gem5-21.2.1.0.
It consists of three clusters :

1)  Little cluster of 4 CPUs, each CPU has private L1$ and L2$

2)  Middle cluster of 3 CPUs, each CPU has private L1$ and L2$

3)  Big cluster of 1 CPU with private L1$ and L2$.

By default, the L2$ and L3$ (residing in the HNF) have their clusivity set to 
strict_inclusive and mostly_inclusive respectively (CHI_config.py):

class CHI_L2Controller(CHI_Cache_Controller):
'''
Default parameters for a L2 Cache controller
'''

def __init__(self, ruby_system, cache, l2_clusivity, prefetcher):
super(CHI_L2Controller, self).__init__(ruby_system)
self.sequencer = NULL
self.cache = cache
self.use_prefetcher = False
self.allow_SD = True
self.is_HN = False
self.enable_DMT = False
self.enable_DCT = False
self.send_evictions = False
# Strict inclusive MOESI
 self.alloc_on_seq_acc = False
 self.alloc_on_seq_line_write = False
 self.alloc_on_readshared = True
 self.alloc_on_readunique = True
 self.alloc_on_readonce = True
 self.alloc_on_writeback = True
 self.dealloc_on_unique = False
 self.dealloc_on_shared = False
 self.dealloc_backinv_unique = True
 self.dealloc_backinv_shared = True

class CHI_HNFController(CHI_Cache_Controller):
'''
Default parameters for a coherent home node (HNF) cache controller
'''

#def __init__(self, ruby_system, cache, prefetcher, addr_ranges):
def __init__(self, ruby_system, cache, prefetcher, addr_ranges, 
hnf_enable_dmt, hnf_enable_dct, \
 num_tbe, num_repl_tbe, num_snp_tbe, unified_repl_tbe, 
l3_clusivity):
super(CHI_HNFController, self).__init__(ruby_system)
self.sequencer = NULL
self.cache = cache
self.use_prefetcher = False
self.addr_ranges = addr_ranges
self.allow_SD = True
self.is_HN = True
#self.enable_DMT = True
#self.enable_DCT = True
self.enable_DMT = hnf_enable_dmt
self.enable_DCT = hnf_enable_dct
self.send_evictions = False
# MOESI / Mostly inclusive for shared / Exclusive for unique
self.alloc_on_seq_acc = False
self.alloc_on_seq_line_write = False
self.alloc_on_readshared = True
self.alloc_on_readunique = False
self.alloc_on_readonce = True
self.alloc_on_writeback = True
self.dealloc_on_unique = True
self.dealloc_on_shared = False
self.dealloc_backinv_unique = False
self.dealloc_backinv_shared = False

The simulations complete okay for the default clusivity of L2$ and L3$.
However, if I change the L2$ clusivity to "mostly_inclusive" some of the 
benchmarks are failing with an assertion error.

I took the default L3$ clusivity of mostly_inclusive to update the L2$ 
clusivity to be mostly_inclusive:

class CHI_L2Controller(CHI_Cache_Controller):
'''
Default parameters for a L2 Cache controller
'''

def __init__(self, ruby_system, cache, l2_clusivity, prefetcher):
super(CHI_L2Controller, self).__init__(ruby_system)
self.sequencer = NULL
self.cache = cache
self.use_prefetcher = False
self.allow_SD = True
self.is_HN = False
self.enable_DMT = False
self.enable_DCT = False
self.send_evictions = False
# Strict inclusive MOESI
if (l2_clusivity == "sincl"):
self.alloc_on_seq_acc = False
self.alloc_on_seq_line_write = False
self.alloc_on_readshared = True
self.alloc_on_readunique = True
self.alloc_on_readonce = True
self.alloc_on_writeback = True
self.dealloc_on_unique = False
self.dealloc_on_shared = False
self.dealloc_backinv_unique = True
self.dealloc_backinv_shared = True
elif (l2_clusivity == "mincl"):
# Mostly inclusive MOESI
self.alloc_on_seq_acc = False
self.alloc_on_seq_line_write = False
self.alloc_on_readshared = True
self.alloc_on_readunique = False
self.alloc_on_readonce = True
self.alloc_on_writeback = True
self.dealloc_on_unique = True
self.dealloc_on_shared = False
self.dealloc_backinv_unique = False
self.dealloc_backinv_shared = False

The assertion error being:

log_parsec_volrend_134_8rnf_1snf_4hnf_3_clust_all_priv_l2.txt:build/ARM/mem/ruby/protocol/Cache_Controller.cc:5477:
 panic: Runtime Error at CHI-cache-actions.sm:1947: assert failure.

QS 1: Even though the L2$ is private, i am assuming that L2$ clusivity can be 
set to mostly_inclusive. Is that assumption correct?
QS2: If the answer to QS 1 is yes, then it would seem that the 
"mostly_inclusive" settings for 

[gem5-users] CHI - measure of the snoop traffic

[Javed Osmany via gem5-users]

Hello

I am modelling a Ruby based CHI multicore, 3-cluster system with two different 
configs.
In one config, all the cluster CPUs have a private L2$ and in the other config, 
for two clusters, the CPUs share an L2$.

I wanted to check the snoop out traffic at the L2$ controller and the HNCache 
controller (in the HNF a shared L3$ is modelled) for the two different configs.

In the stats.txt, I have been looking at the cpux.l2.snpOut.m_buf_msgs metric.
Each of the L2CacheController and HNFCacheController processes the incoming 
snpIn request and if the requested cache line resides in another CPU cache will 
send out the snpOut request to the CHI network.

Now in MessageBuffer.cc, we have

MessageBuffer::MessageBuffer(const Params )
: SimObject(p), m_stall_map_size(0),
m_max_size(p.buffer_size), m_time_last_time_size_checked(0),
m_time_last_time_enqueue(0), m_time_last_time_pop(0),
m_last_arrival_time(0), m_strict_fifo(p.ordered),
m_randomization(p.randomization),
m_allow_zero_latency(p.allow_zero_latency),
ADD_STAT(m_not_avail_count, "Number of times this buffer did not have "
"N slots available"),
ADD_STAT(m_buf_msgs, "Average number of messages in buffer"),


So as I understand it, each snpOut request that the CacheController generates 
will get buffered in the corresponding snpOut MessageBuffer first, then 
arbitrate for access to the network and once arbitration is won, the request is 
sent out to the CHI interconnect.

A  couple of questions:


1)  Will snpOut.m_buf_msgs give an accurate account of the number of snpOut 
requests that the CacheController has generated?

2)  Is it possible for the request to be buffered in the snpOut Message 
buffer and if there is no conflict to the network, the request could be sent 
out to the network on the next clock cycle? If yes, then will this be visible 
in the snpOut.m_buf_msgs metric?

3)  For snpOut.m_msg_bufs, how is the "Average number of messages in the 
buffer" actually being computed?

Tks in advance

JO

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

[gem5-users] Re: Re：CHI - data/tag latency modelling for HNF/L3$

[Javed Osmany via gem5-users]

Hello Fu

Thks for that. I was looking at CHI.py yesterday evening, but somehow missed 
that.

Best regards
JO



From: zexin Fu via gem5-users [mailto:gem5-users@gem5.org]
Sent: 08 April 2022 08:04
To: zexin Fu via gem5-users 
Cc: zexin Fu <1056844...@qq.com>
Subject: [gem5-users] Re: Re：CHI - data/tag latency modelling for HNF/L3$


Hi, Javed



I think you can add your config at CHI.py like:



class HNFCache(RubyCache):
dataArrayBanks = 1
dataAccessLatency = 1
tagArrayBanks = 1
tagAccessLatency = 1
size = options.l3_size

assoc = options.l3_assoc





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

[gem5-users] CHI - data/tag latency modelling for HNF/L3$

[Javed Osmany via gem5-users]

Hello

I am trying to model a multicore SOC system using Ruby and CHI and I am trying 
to model data/tag latency for the L3$ which resides in the HNF.

Looking in CHI.py and CHI_config.py, I could not see any mechanisms to model 
this.

Could someone please let me know if this is possible and if so whether I can 
make it a command line option?

Thanks in advance
JO


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

[gem5-users] Re: CHI

[Javed Osmany via gem5-users]

Hello Bobby

It was our local gitlab repository, where the problem resided.

Tks

JO


From: Bobby Bruce [mailto:bbr...@ucdavis.edu]
Sent: 03 March 2022 22:07
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: Re: [gem5-users] Re: CHI

Which gitlab repository was this? I don't believe we maintain one officially. 
The github repo is a mirror of https://gem5.googlesource.com/public/gem5 so 
should be up-to-date.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Mar 3, 2022 at 2:30 AM Javed Osmany via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hello

Just an update …

Previously I had cloned the latest gem5 version (21.2.1.0) from a gitlab 
repository (as I was having proxy issues in accessing github). Something must 
have gone wrong in the cloning, since that was causing the problem with the CHI 
protocol compilation.

I am now able to download the latest gem5 (21.2.1.0) directly from github and 
am now able to successfully compile it for the CHI protocol.

Regards
JO

From: Javed Osmany
Sent: 02 March 2022 15:44
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Javed Osmany mailto:javed.osm...@huawei.com>>
Subject: RE: CHI

Hello

So I thought the reason why my previous command line options were not being 
parsed in the latest version of gem5 (21..2.1.0) could be because the CHI.py 
and CHI_config.py files were not being compiled when generating the executable 
gem5.opt binary.

So I tried the following command:

rm -rf build/ARM
scons -j4 build/ARM/gem5.opt --default=ARM PROTOCOL=CHI

The above command terminates with:

Building in /home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/ARM
Using saved variables file 
/home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/variables/ARM

scons: *** Invalid value for option PROTOCOL: CHI.  Valid values are: 
['GPU_VIPER', 'GPU_VIPER_Baseline', 'GPU_VIPER_Region', 'GPU_RfO', 
'MOESI_AMD_Base', 'MESI_Two_Level', 'MESI_Three_Level', 'MI_example', 
'MOESI_CMP_directory', 'MOESI_CMP_token', 'MOESI_hammer', 'Garnet_standalone', 
'None', 'MSI']

Thus it looks like CHI is not supported in this latest version of gem5 ??

So looking in build_opts/ARM we have:

j00533938@lhrpbig12:~/gitlab/gem5-21.2.1.0/gem5/build_opts$<mailto:j00533938@lhrpbig12:~/gitlab/gem5-21.2.1.0/gem5/build_opts$>
 more ARM
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MOESI_CMP_directory'


Is CHI protocol not supported in the latest gem5 release?

Tks in advance

JO

From: Javed Osmany
Sent: 02 March 2022 15:00
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Javed Osmany mailto:javed.osm...@huawei.com>>
Subject: CHI

Hello

I am using the latest version of gem5 (21.2.1.0).

Previously, when using gem5 version 21.0.0.0, in the function “def 
define_options(parser)” (in CHI.py), I added some command line options as such:

def define_options(parser):
parser.add_option("--chi-config", action="store", type="string",
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")

I was then able to specify the options when running as:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0 …..

This then worked okay. The new command line options I added was recognised okay.

Now with gem5 21.2.1.0, I have added the same options to the 
define_options(parser) function (in CHI.py) as such:

def define_options(parser):
parser.add_argument("--chi-config", action="store", type=str,
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option

[gem5-users] Re: CHI

[Javed Osmany via gem5-users]

Hello

Just an update ...

Previously I had cloned the latest gem5 version (21.2.1.0) from a gitlab 
repository (as I was having proxy issues in accessing github). Something must 
have gone wrong in the cloning, since that was causing the problem with the CHI 
protocol compilation.

I am now able to download the latest gem5 (21.2.1.0) directly from github and 
am now able to successfully compile it for the CHI protocol.

Regards
JO

From: Javed Osmany
Sent: 02 March 2022 15:44
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: CHI

Hello

So I thought the reason why my previous command line options were not being 
parsed in the latest version of gem5 (21..2.1.0) could be because the CHI.py 
and CHI_config.py files were not being compiled when generating the executable 
gem5.opt binary.

So I tried the following command:

rm -rf build/ARM
scons -j4 build/ARM/gem5.opt --default=ARM PROTOCOL=CHI

The above command terminates with:

Building in /home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/ARM
Using saved variables file 
/home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/variables/ARM

scons: *** Invalid value for option PROTOCOL: CHI.  Valid values are: 
['GPU_VIPER', 'GPU_VIPER_Baseline', 'GPU_VIPER_Region', 'GPU_RfO', 
'MOESI_AMD_Base', 'MESI_Two_Level', 'MESI_Three_Level', 'MI_example', 
'MOESI_CMP_directory', 'MOESI_CMP_token', 'MOESI_hammer', 'Garnet_standalone', 
'None', 'MSI']

Thus it looks like CHI is not supported in this latest version of gem5 ??

So looking in build_opts/ARM we have:

j00533938@lhrpbig12:~/gitlab/gem5-21.2.1.0/gem5/build_opts$
 more ARM
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MOESI_CMP_directory'


Is CHI protocol not supported in the latest gem5 release?

Tks in advance

JO

From: Javed Osmany
Sent: 02 March 2022 15:00
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Javed Osmany mailto:javed.osm...@huawei.com>>
Subject: CHI

Hello

I am using the latest version of gem5 (21.2.1.0).

Previously, when using gem5 version 21.0.0.0, in the function "def 
define_options(parser)" (in CHI.py), I added some command line options as such:

def define_options(parser):
parser.add_option("--chi-config", action="store", type="string",
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")

I was then able to specify the options when running as:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0 .

This then worked okay. The new command line options I added was recognised okay.

Now with gem5 21.2.1.0, I have added the same options to the 
define_options(parser) function (in CHI.py) as such:

def define_options(parser):
parser.add_argument("--chi-config", action="store", type=str,
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")
 :
 :


But the following command does not work anymore:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0


The error message being:

command line: ./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 --verbose=true 
--num-clusters=0

Usage: se_kirin_custom.py [options]

se_kirin_custom.py: error: no such option: --verbose

Any pointers why the new command line options I had previously specified are 
now not working?

Tks in advance

JO

[gem5-users] Re: CHI

[Javed Osmany via gem5-users]

Hello

So I thought the reason why my previous command line options were not being 
parsed in the latest version of gem5 (21..2.1.0) could be because the CHI.py 
and CHI_config.py files were not being compiled when generating the executable 
gem5.opt binary.

So I tried the following command:

rm -rf build/ARM
scons -j4 build/ARM/gem5.opt --default=ARM PROTOCOL=CHI

The above command terminates with:

Building in /home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/ARM
Using saved variables file 
/home/j00533938/gitlab/gem5-21.2.1.0/gem5/build/variables/ARM

scons: *** Invalid value for option PROTOCOL: CHI.  Valid values are: 
['GPU_VIPER', 'GPU_VIPER_Baseline', 'GPU_VIPER_Region', 'GPU_RfO', 
'MOESI_AMD_Base', 'MESI_Two_Level', 'MESI_Three_Level', 'MI_example', 
'MOESI_CMP_directory', 'MOESI_CMP_token', 'MOESI_hammer', 'Garnet_standalone', 
'None', 'MSI']

Thus it looks like CHI is not supported in this latest version of gem5 ??

So looking in build_opts/ARM we have:

j00533938@lhrpbig12:~/gitlab/gem5-21.2.1.0/gem5/build_opts$ more ARM
TARGET_ISA = 'arm'
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
PROTOCOL = 'MOESI_CMP_directory'


Is CHI protocol not supported in the latest gem5 release?

Tks in advance

JO

From: Javed Osmany
Sent: 02 March 2022 15:00
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: CHI

Hello

I am using the latest version of gem5 (21.2.1.0).

Previously, when using gem5 version 21.0.0.0, in the function "def 
define_options(parser)" (in CHI.py), I added some command line options as such:

def define_options(parser):
parser.add_option("--chi-config", action="store", type="string",
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")

I was then able to specify the options when running as:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0 .

This then worked okay. The new command line options I added was recognised okay.

Now with gem5 21.2.1.0, I have added the same options to the 
define_options(parser) function (in CHI.py) as such:

def define_options(parser):
parser.add_argument("--chi-config", action="store", type=str,
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")
 :
 :


But the following command does not work anymore:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0


The error message being:

command line: ./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 --verbose=true 
--num-clusters=0

Usage: se_kirin_custom.py [options]

se_kirin_custom.py: error: no such option: --verbose

Any pointers why the new command line options I had previously specified are 
now not working?

Tks in advance

JO

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

[gem5-users] CHI

[Javed Osmany via gem5-users]

Hello

I am using the latest version of gem5 (21.2.1.0).

Previously, when using gem5 version 21.0.0.0, in the function "def 
define_options(parser)" (in CHI.py), I added some command line options as such:

def define_options(parser):
parser.add_option("--chi-config", action="store", type="string",
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")

I was then able to specify the options when running as:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0 .

This then worked okay. The new command line options I added was recognised okay.

Now with gem5 21.2.1.0, I have added the same options to the 
define_options(parser) function (in CHI.py) as such:

def define_options(parser):
parser.add_argument("--chi-config", action="store", type=str,
  default=None,
  help="NoC config. parameters and bindings. "
   "Required for CustomMesh topology")
## Add command line options specifically for the [Big, Middle, Little]
## Cluster.
parser.add_option("--verbose", action="store", type="string",
  default="false",
  help="Disable/Enable verbose printing for debugging")
parser.add_option("--num-clusters", action="store", type="string",
  default=0,
  help="Number of Clusters in the system")
 :
 :


But the following command does not work anymore:

./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kiri
n_custom.py --ruby --topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 
--num-dirs=1 --num-l3caches=1 --verbose=true --num-clusters=0


The error message being:

command line: ./build/ARM/gem5.opt 
--outdir=m5out_parsec_blackscoles_1_clust_little_4_cpu_all_shared_l2 
configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 --verbose=true 
--num-clusters=0

Usage: se_kirin_custom.py [options]

se_kirin_custom.py: error: no such option: --verbose

Any pointers why the new command line options I had previously specified are 
now not working?

Tks in advance

JO

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

[gem5-users] Re: Access to gem5 101 course

[Javed Osmany via gem5-users]

Hello

No progress on accessing that link for me.

However, the following two urls might give some insight.

http://pages.cs.wisc.edu/~david/courses/cs752/Fall2015/

https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/includes/schedule.html

BR
JO

-Original Message-
From: Ioannis Mavroidis via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 14 October 2021 10:40
To: gem5-users@gem5.org
Cc: imavr...@exapsys.eu
Subject: [gem5-users] Re: Access to gem5 101 course

Any news with this? It would be of great help if we could access the course!

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

[gem5-users] Re: CHI_config.py

[Javed Osmany via gem5-users]

Hello

>> If the answer to the above question is yes, then why even have that 
>> attribute for the class?

Looking in more detail, CHI_HNFController is derived from CHI_Cache_Controller 
class.
The CHI_Cache_Controller class is used to derive the CHI_L1Controller and 
CHI_L2Controller class objects. In these cases the number_of_snoop_TBEs 
attribute is used to handle the number of snoop requests the respective cache 
controller can receive.


Best regards
J.Osmany

From: Javed Osmany
Sent: 05 October 2021 16:33
To: gem5-users@gem5.org
Cc: Javed Osmany 
Subject: CHI_config.py

Hello

In CHI_config.py, for the class CHI_HNFController we have

class CHI_HNFController(CHI_Cache_controller):
  :
  :
# Some reasonable default TBE params
self.number_of_TBEs = 32
self.number_of_repl_TBEs = 32
self.number_of_snoop_TBEs = 1 # should not receive any snoop
self.unify_repl_TBEs = False
   :


The number_of_snoop_TBEs is set to 1 with the corresponding comment.
This seems to indicate that the number_of_snoop_TBEs can be left at 1 since the 
CHI_HNFController should not receive any snoop requests.
Is this because a RNF coherence request which gets a hit in the directory will 
generate a snoop request to one or more other RNFs which may be holding a copy 
of the cache line?
If the answer to the above question is yes, then why even have that attribute 
for the class?


Thanks in advance
J.Osmany
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] CHI_config.py

[Javed Osmany via gem5-users]

Hello

In CHI_config.py, for the class CHI_HNFController we have

class CHI_HNFController(CHI_Cache_controller):
  :
  :
# Some reasonable default TBE params
self.number_of_TBEs = 32
self.number_of_repl_TBEs = 32
self.number_of_snoop_TBEs = 1 # should not receive any snoop
self.unify_repl_TBEs = False
   :


The number_of_snoop_TBEs is set to 1 with the corresponding comment.
This seems to indicate that the number_of_snoop_TBEs can be left at 1 since the 
CHI_HNFController should not receive any snoop requests.
Is this because a RNF coherence request which gets a hit in the directory will 
generate a snoop request to one or more other RNFs which may be holding a copy 
of the cache line?
If the answer to the above question is yes, then why even have that attribute 
for the class?


Thanks in advance
J.Osmany
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: set cache line size under o3 cpu

[Javed Osmany via gem5-users]

Hello

This is because the fetchBufferSize in O3CPU.py is set to 64 bytes and you are 
trying to set the cache line size to 32 bytes.

In your local version of se.py, add the following code:

if (options.cacheline_size == 32):
DerivO3CPU.fetchBufferSize = 32


Best regards
J.Osmany

-Original Message-
From: yangyuqing--- via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 29 September 2021 12:29
To: gem5-users@gem5.org
Cc: yangyuq...@sjtu.edu.cn
Subject: [gem5-users] set cache line size under o3 cpu

When I simulate o3 cpu, I find that I can not set cache line size to 32B. 
The command is ./build/RISCV/gem5.opt --outdir=output/riscv 
configs/example/se.py \ --cpu-type=DerivO3CPU --num-cpus=2 --cpu-clock=1.5GHz 
--caches --l2cache --l1d_size=16kB \ --l1i_size=16kB --l2_size=256kB 
--l1d_assoc=4 --l1i_assoc=4 --l2_assoc=16 --cacheline_size=32 \
--mem-type=DDR4_2400_16x4 --mem-size=1GB \ -c 
./tests/test-progs/hello/bin/riscv/linux/hello.
It causes errors like: build/RISCV/cpu/o3/fetch.cc:115: fatal: fetch buffer 
size (64 bytes) is greater than the cache block size (32 bytes). 
So how to change cache line size when using o3 cpu?
___
gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to 
gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Access to gem5 101 course

[Javed Osmany via gem5-users]

Hello Scott

Ahh, no I can't access any of the parts of the courses, just realised. 

Tks
JO


-Original Message-
From: Scott Blankenberg via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 22 September 2021 23:02
To: gem5-users@gem5.org
Cc: scot...@synopsys.com
Subject: [gem5-users] Re: Access to gem5 101 course

Hello Javed Osmany,

Did you try clicking the links to the different parts of the course?

Thanks,

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

[gem5-users] Re: Access to gem5 101 course

[Javed Osmany via gem5-users]

The link is working okay for me.

Best regards
JO

From: Bobby Bruce via gem5-users [mailto:gem5-users@gem5.org]
Sent: 22 September 2021 18:53
To: gem5 users mailing list 
Cc: scot...@synopsys.com; Bobby Bruce 
Subject: [gem5-users] Re: Access to gem5 101 course

Yip, dead link for me as well. I'll see what we can do.

The Learning gem5 Tutorial should be sufficient though if you're new to gem5.
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Sep 20, 2021 at 10:16 AM Scott Blankenberg via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Dear all,

Can anyone still access the gem5 101 course at : 
https://www.gem5.org/documentation/learning_gem5/gem5_101/#:~:text=Branch%20prediction%20and%20predication%20are%20two%20common%20techniques,how%20to%20incorporate%20gem5%20into%20your%20research%20process.

When I click the links I get a page not found error.

Thanks,

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

[gem5-users] Re: CHI, Ruby - changing cacheline size

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you, once again, for the pointers.

Best regards
J.Osmany


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 27 August 2021 10:53
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI, Ruby - changing cacheline size

Hi again ;),

Yes, Ruby should support any cacheline size (at least as long as it is a power 
of two).
And yes, you need to change the parameter O3CPU.fetchBufferSize and defaulted 
to 64 bytes. Not sure if it has any other implications but O3_ARM_v7a_3 sets it 
to 16 for instance.

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

[gem5-users] CHI, Ruby - changing cacheline size

[Javed Osmany via gem5-users]

Hello

I am using CHI protocol and the Ruby memory system. I am trying to run the 
Parsec and Splash2 benchmarks by varying the cache line size using the command 
line option cacheline_size.

It works for cacheline_size = 64, 128, 256 but not for 32.

I am using gem5-21.0
Command I am using is

./build/ARM/gem5.opt --outdir=m5out_parsec_blackscoles_struct1_line_32 
configs/example/se_kirin_custom.py --ruby --top
ology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=8 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-middleclust=1 --num-cpu-
littleclust=2 --num-clusters=3 --cpu-type-bigclust=derivo3 
--cpu-type-middleclust=derivo3 --cpu-type-littleclust=derivo3 --bigclust-
l2cache=private --middleclust-l2cache=private --littleclust-l2cache=shared 
--num-bigclust-subclust=1 --num-middleclust-subclust=2 --
num-littleclust-subclust=2 --num-cpu-bigclust-subclust2=1 
--num-cpu-middleclust-subclust2=3 --num-cpu-littleclust-subclust2=2 --big-
cpu-clock=3GHz --middle-cpu-clock=2.6GHz --little-cpu-clock=2GHz 
--cacheline_size=32 --verbose=true --cmd=tests/parsec/blackscoles/p
arsec.blackscholes.hooks -o '4 tests/parsec/blackscoles/in_4K.txt 
tests/parsec/blackscoles/prices.txt'


The error message I get is:

Global frequency set at 1 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range 
assigned (512 Mbytes)
fatal: fetch buffer size (64 bytes) is greater than the cache block size (32 
bytes)

QS: is a cacheline size of 32 bytes supported in Ruby?
QS: If yes, do I need to change the fetch buffer size to be 32-bytes as well 
and if so where do I need to modify?


Thanks in advance
JO
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: CHI and Ruby Cache block size

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for the clarification.

Best regards
J.Osmany


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 17 August 2021 09:33
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI and Ruby Cache block size

Hi Javed,

First a note about the relationship of classes involved in the CHI model.
The L1 and L2 CHI caches are not derived from python class RubyCache 
corresponding to C++ class CacheMemory. CacheMemory is only responsible for 
managing the memory of the cache, not the protocol that goes around it. L1 and 
L2 CHI caches are 2 configurations of the same Cache_Controller class (same 
name in C++ and Python) generated by SLICC after the "Cache" state machine of 
the CHI protocol. A CacheMemory instance is then an attribute of this 
CHI_Cache_Controller class (composition in OOP).

About the block size, now. Regarding the CHI protocol, it expects the entire 
RubySystem to use the same block size, as all other Ruby protocols released in 
gem5. For convenience, the block size is stored as a static in the RubySystem 
class and accessed from there by many base components of a ruby model: Address, 
DataBlock, AbstractController, RubyPort, etc. The block size effectively is a 
constant global parameter for the whole simulation.

While convenient, this is is both limiting to model more exotic systems, and 
bad OOP practice. Refactoring of this part would be more than welcome, 
including by me ;) Not an easy job, though.

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

[gem5-users] CHI and Ruby Cache block size

[Javed Osmany via gem5-users]

Hello

I am using the CHI protocol with Ruby.

The CHI L1 Cache and L2 Cache are derived from the RubyCache class model.

My question: Within Ruby, is it possible to have different cache line size for 
the L1 and L2 caches?

I had a look at src/mem/ruby/structures/RubyCache.py and there is only 
block_size specified, which seems to imply that the same block size will be 
used for both L1 and L2 caches.

Thanks in advance

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

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

Many thanks for your thoughts.

Just checking, is Tiago's email tiago.m...@arm.com?

Best regards
J.Osmany


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 10 August 2021 09:59
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

Hi Javed,

I don't have a reliable answer for you. It is possible that the current CHI 
cache implementation cannot be shared, although it would surprise me. I would 
suggest you to ping Tiago Mück who wrote this stuff to ask him about that.

On your side, you can dig in the ProtocolTrace flag output. It can be quite 
easy to read once greped to the cacheline you want. It will tell you how you 
got into the RU state which violates the strict inclusiveness of the L2 claimed 
by the CHI_L2Controller class. You could benefit from the RubyGenerated flag as 
well to trace the actions executed by each controller. Also use --debug-start 
to reduce trace size and pipe output to gzip to compress it significantly (read 
with zcat). I have a working patch available to accelerate tracing when piping 
to gzip but I didn't have time to finalize the tests yet. You can find it here: 
https://gem5-review.googlesource.com/c/public/gem5/+/45025.

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

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

Just wondered if any further thoughts as how to resolve the CHI assertion error?

I have tried running the failing Parsec/Splash2 benchmarks and if I change to 
private L2 cache, then the tests pass. So the issue is definitely  related to 
the shared L2 cache implementation that I have added.

Furthermore, it is from the shared L2 cache controller that the assertion is 
firing.

Just thinking further, if the cache line is resident in an upstream cache (in 
state UC or UD) but not in the shared L2 cache (hence the final state being 
RU), this would imply that the L2$ is non-inclusive of the upstream L1 caches. 
Can you please confirm if this is the case?

Best regards
J.Osmany

_
From: Javed Osmany
Sent: 04 August 2021 08:38
To: gem5 users mailing list 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache


Hello Gabriel

>> I would then suggest two non-tested options. You can assign the L2 
>> controller to cpu.l2 after registering it as downstream_components of l1i 
>> and l1d. Let's hope it will set the desired name.

I tried this but was unsuccessful, so have left it for the time being to make 
progress.

I have been trying to run the parsec benchmarks and a majority of them are 
failing due to an assertion firing from CHI-cache-actions.sm.  The assertion 
error being:

panic: Runtime Error at CHI-cache-actions.sm:2611: assert failure.

The system being modelled consists of 8 CPUs, partitioned into three clusters, 
where one of the clusters has shared L2 cache and the other two clusters have 
private L2 cache per CPU.

The command being used to run is (also in the attachment):

./build/ARM/gem5.opt --debug-flags=RubySlicc 
--outdir=m5out_parsec_lu_cb_struct1 configs/example/se_kirin_custom.py --ruby 
--topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=8 --num-dirs=1 
--num-l3caches=1 --num-cpu-bigclust=1 --num-cpu-middleclust=1 
--num-cpu-littleclust=2 --num-clusters=3 --cpu-type-bigclust=derivo3 
--cpu-type-middleclust=derivo3 --cpu-type-littleclust=hpi 
--bigclust-l2cache=private --middleclust-l2cache=private 
--littleclust-l2cache=shared --num-bigclust-subclust=1 
--num-middleclust-subclust=2 --num-littleclust-subclust=2 
--num-cpu-bigclust-subclust2=1  --num-cpu-middleclust-subclust2=3 
--num-cpu-littleclust-subclust2=2 --big-cpu-clock=3GHz 
--middle-cpu-clock=2.6GHz --little-cpu-clock=2GHz --verbose=true 
--cmd=tests/parsec/splash2/lu_cb/splash2x.lu_cb.hooks -o " -p7 -n512 -b16"

The code in CHI-cache-actions.sm where the assertion is firing from is:

action(Finalize_UpdateCacheFromTBE, desc="") {
  assert(is_valid(tbe));
  State final := tbe.finalState;
  // JO
   DPRINTF(RubySlicc, "JO: CHI-cache-actions.sm: Final state value is %s\n", 
final);
  if ((final == State:UD_RSC) || (final == State:SD_RSC) || (final == 
State:UC_RSC) ||
  (final == State:SC_RSC) || (final == State:UD) || (final == 
State:UD_T) ||
  (final == State:SD) || (final == State:UC) || (final == State:SC) 
||
  (final == State:UC_RU)  || (final == State:UD_RU)  || (final == 
State:UD_RSD) ||
  (final == State:SD_RSD)) {
assert(tbe.dataBlkValid.isFull());
assert(tbe.dataValid);
assert(is_valid(cache_entry));
cache_entry.DataBlk := tbe.dataBlk;
DPRINTF(RubySlicc, "Cached data %s pfb %s\n", tbe.dataBlk, 
cache_entry.HWPrefetched);
  } else {
// make sure only deallocate the cache entry if data is invalid
assert(tbe.dataValid == false); <== This is the assertion which is firing.
if (is_valid(cache_entry)) {
  cache.deallocate(address);
  unset_cache_entry();
}
  }
}

I added a DPRINTF to check what the final state was before the assertion fires.
The final state being RU. This state is not encoded in the if (xxx) clause, 
hence we go the else clause and the assertion is firing.

21984560500: system.cpu2.l1i.downstream_destinations: 
CHI-cache-actions.sm:2598: JO: CHI-cache-actions.sm: Final state value is RU
panic: Runtime Error at CHI-cache-actions.sm:2611: assert failure.

The issue seems to be the final state, RU. The RU seems to be saying the state 
of the cache line in the upstream cache is unique, but it is not encoding the 
state of the cache line in the L2 cache.

Is this due to missing functionality in the SLICC encoding for CHI or is the 
shared L2$ implementation causing the problem?
Any pointers as how to resolve this assertion issue would be much appreciated.

I am attaching (as a winzip rar file) the updated CHI.py, CHI_config.py files. 
Also included is the custom version of the se.py used to run the test and the 
snippet of the trace file prior to the assertion firing when DPRINTF is enabled.

Best regards
J.Osmany


 << File: chi_parsec_splash2_lu_cb_shared_l2_assertion_error.rar >>
-Original Message-
From: Javed Osmany
Sent: 22 July 2021 11:52
To: 'gem5 users mailing list' 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: 

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

>> I would then suggest two non-tested options. You can assign the L2 
>> controller to cpu.l2 after registering it as downstream_components of l1i 
>> and l1d. Let's hope it will set the desired name.

I tried this but was unsuccessful, so have left it for the time being to make 
progress.

I have been trying to run the parsec benchmarks and a majority of them are 
failing due to an assertion firing from CHI-cache-actions.sm.  The assertion 
error being:

panic: Runtime Error at CHI-cache-actions.sm:2611: assert failure.

The system being modelled consists of 8 CPUs, partitioned into three clusters, 
where one of the clusters has shared L2 cache and the other two clusters have 
private L2 cache per CPU.

The command being used to run is (also in the attachment):

./build/ARM/gem5.opt --debug-flags=RubySlicc 
--outdir=m5out_parsec_lu_cb_struct1 configs/example/se_kirin_custom.py --ruby 
--topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=8 --num-dirs=1 
--num-l3caches=1 --num-cpu-bigclust=1 --num-cpu-middleclust=1 
--num-cpu-littleclust=2 --num-clusters=3 --cpu-type-bigclust=derivo3 
--cpu-type-middleclust=derivo3 --cpu-type-littleclust=hpi 
--bigclust-l2cache=private --middleclust-l2cache=private 
--littleclust-l2cache=shared --num-bigclust-subclust=1 
--num-middleclust-subclust=2 --num-littleclust-subclust=2 
--num-cpu-bigclust-subclust2=1  --num-cpu-middleclust-subclust2=3 
--num-cpu-littleclust-subclust2=2 --big-cpu-clock=3GHz 
--middle-cpu-clock=2.6GHz --little-cpu-clock=2GHz --verbose=true 
--cmd=tests/parsec/splash2/lu_cb/splash2x.lu_cb.hooks -o " -p7 -n512 -b16"

The code in CHI-cache-actions.sm where the assertion is firing from is:

action(Finalize_UpdateCacheFromTBE, desc="") {
  assert(is_valid(tbe));
  State final := tbe.finalState;
  // JO
   DPRINTF(RubySlicc, "JO: CHI-cache-actions.sm: Final state value is %s\n", 
final);
  if ((final == State:UD_RSC) || (final == State:SD_RSC) || (final == 
State:UC_RSC) ||
  (final == State:SC_RSC) || (final == State:UD) || (final == 
State:UD_T) ||
  (final == State:SD) || (final == State:UC) || (final == State:SC) 
||
  (final == State:UC_RU)  || (final == State:UD_RU)  || (final == 
State:UD_RSD) ||
  (final == State:SD_RSD)) {
assert(tbe.dataBlkValid.isFull());
assert(tbe.dataValid);
assert(is_valid(cache_entry));
cache_entry.DataBlk := tbe.dataBlk;
DPRINTF(RubySlicc, "Cached data %s pfb %s\n", tbe.dataBlk, 
cache_entry.HWPrefetched);
  } else {
// make sure only deallocate the cache entry if data is invalid
assert(tbe.dataValid == false); <== This is the assertion which is firing.
if (is_valid(cache_entry)) {
  cache.deallocate(address);
  unset_cache_entry();
}
  }
}

I added a DPRINTF to check what the final state was before the assertion fires.
The final state being RU. This state is not encoded in the if (xxx) clause, 
hence we go the else clause and the assertion is firing.

21984560500: system.cpu2.l1i.downstream_destinations: 
CHI-cache-actions.sm:2598: JO: CHI-cache-actions.sm: Final state value is RU
panic: Runtime Error at CHI-cache-actions.sm:2611: assert failure.

The issue seems to be the final state, RU. The RU seems to be saying the state 
of the cache line in the upstream cache is unique, but it is not encoding the 
state of the cache line in the L2 cache.

Is this due to missing functionality in the SLICC encoding for CHI or is the 
shared L2$ implementation causing the problem?
Any pointers as how to resolve this assertion issue would be much appreciated.

I am attaching (as a winzip rar file) the updated CHI.py, CHI_config.py files. 
Also included is the custom version of the se.py used to run the test and the 
snippet of the trace file prior to the assertion firing when DPRINTF is enabled.

Best regards
J.Osmany



-Original Message-
From: Javed Osmany
Sent: 22 July 2021 11:52
To: 'gem5 users mailing list' 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

Hi Gabriel

Many thanks for your insight and input.

I have taken on board your suggestion and simplified the customisation of 
CHI.py and CHI_config.py by just using the CHI_Config.CHI_RNF() class object 
and adding another method to CHI_Config.CHI_RNF(), called addSharedL2Cache.

Also I have started testing with 1 cluster which contains 1 CPU and permutating 
with shared/private L2 cache.

>> I would then suggest two non-tested options. You can assign the L2 
>> controller to cpu.l2 after registering it as downstream_components of l1i 
>> and l1d. Let's hope it will set the desired name.

Will try this out.

Best regards
J.Osmany


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 22 July 2021 08:40
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

Hi Javed,

Woops, I didn't see the split option in your first 

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hi Gabriel

Many thanks for your insight and input.

I have taken on board your suggestion and simplified the customisation of 
CHI.py and CHI_config.py by just using the CHI_Config.CHI_RNF() class object 
and adding another method to CHI_Config.CHI_RNF(), called addSharedL2Cache.

Also I have started testing with 1 cluster which contains 1 CPU and permutating 
with shared/private L2 cache.

>> I would then suggest two non-tested options. You can assign the L2 
>> controller to cpu.l2 after registering it as downstream_components of l1i 
>> and l1d. Let's hope it will set the desired name.

Will try this out.

Best regards
J.Osmany


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 22 July 2021 08:40
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

Hi Javed,

Woops, I didn't see the split option in your first post. My bad.

I think the l2 is actually named "system.cpu0.l1i.downstream_destinations" and 
you will find it in the ini file. I think this is due to the way gem5 sets 
SimObject names. When you assign a SimObject to several object attributes 
(cpu.l2, cpu.l1i and finally cpu.l1d), it will have one of the names according 
to the complex SimObject and SimObjectVector logic. for some reason, it does 
not end up as a child of cpu0.l1d despite it being the last in the list. I am 
regularly fighting SimObject naming logic as well, that's normal ;)

Also check the warnings in the output. Some of them will warn you about 
SimObject reparenting. Sadly, SimObject name is determined by the attribute you 
set it to and you are not supposed to change it.

I would then suggest two non-tested options. You can assign the L2 controller 
to cpu.l2 after registering it as downstream_components of l1i and l1d. Let's 
hope it will set the desired name.
The other "last resort" option is to violate SimObject._name privacy and set it 
manually after the SimObject has been assigned for the last time... I would 
advise against that, though.

Whenever possible, it is actually best to assign a SimObject at the time of 
object creation and never assign it again afterwards... Not always possible, 
though. Also make use of "private" attributes (i.e., attributes with a name 
starting with '_') as much as possible. It bypasses the SimObject assignment 
logic and solves many issues.

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

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

>> addSharedL2Cache is only called on lines 465 and 470 of CHI.py and these 
>> lines are touched only if options.littleclust_l2cache == 'shared'.
>> You don't set it in the command line and the default value is 'private', 
>> which explains why it never gets called.

The command line I use is the following and littleclust-l2cache=shared (please 
see highlighted below). The parser then translates this to 
options.littleclust_l2_cache=shared.

./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=0 --num-cpu-middleclust=0 --num-cpu-littleclust=4 
--num-clusters=1 --cpu-type-bigclust=derivo3 --cpu-type-middleclust=hpi  
--cpu-type-littleclust=timesimple --bigclust-l2cache=shared 
--middleclust-l2cache=shared --littleclust-l2cache=shared 
--num-bigclust-subclust=1 --num-middleclust-subclust=1 
--num-littleclust-subclust=1 --cmd=tests/test-progs/hello/bin/arm/linux/hello

I printed out the options as parsed when the command is run and it shows that 
littleclust_l2cache= shared:

Command Line Options extracted being:

{'num_cpus': 4, 'sys_voltage': '1.0V', .
'spec_input': 'ref', 'arm_iset': 'arm', 'stats_root': [], 'cmd': 
'tests/test-progs/hello/bin/arm/linux/hello', 'options': '',
..
'middleclust_l2cache': 'shared', 'littleclust_l2cache': 'shared', 
'big_cpu_clock': '4GHz', 'middle_cpu_clock': '2GHz', 'little_cpu_clock': 
'1GHz', 'l1i_size_big': '32kB', 'l1i_assoc_big': 2, 'l1d_size_big': '32kB', 
'l1d_assoc_big': 2, 'l2_size_big': '32kB', 'l2_assoc_big': 2, 
'l1i_size_little': '32kB', 'l1i_assoc_little': 2, 'l1d_size_little': '32kB', 
'l1d_assoc_little': 2, 'l2_size_little': '32kB', 'l2_assoc_little': 2, 
'l1i_size_middle': '32kB', 'l1i_assoc_middle': 2, 'l1d_size_middle': '32kB', 
'l1d_assoc_middle': 2, 'l2_size_middle': '32kB', 'l2_assoc_middle': 2, 
'num_bigclust_subclust': '1', 'num_middleclust_subclust': '1', 
'num_littleclust_subclust': '1', 'num_cpu_littleclust_subclust2': 1, 
'num_cpu_middleclust_subclust2': 1, 'num_cpu_bigclust_subclust2': 1, 
'topology': 'Pt2Pt', 'mesh_rows': 0, 'network': 'simple', 'router_latency': 1, 
'link_latency': 1, 'link_width_bits': 128, 'vcs_per_vnet': 4, 
'routing_algorithm': 0, 'network_fault_model': False, 
'garnet_deadlock_threshold': 5}

I am currently working on getting the littleCluster working for shared L2 cache 
and once this is working, then update and get the other two clusters working.

I have also added print statements inside 
CHI_config.CHI_RNF_CLUST_SHARED_L2.addSharedL2CacheL():

CHI_RNF_CLUST_SHARED_L2.addSharedL2, self._cntrls is: 
[,  
, 
, 
, 
, 
, 
, 
, 
]

So this shows the 4 x L1I controller and 4 x L1D controller and the single L2 
Controller. So far so good.

CHI_RNF_CLUST_SHARED_L2.addSharedL2, self.connectController is: >

So one L2 controller to connect to the CHI network.


CHI_RNF_CLUST_SHARED_L2.addSharedL2, self._ll_cntrls is: 
[]

So last level controller for this cluster is the single L2 controller. So far 
so good.

However, when I print out cntrl  from lines 621-623 of CHI.py:

# Setup data message size for all controllers
for cntrl in all_cntrls:
print ("CHI.py -- Cntrl is %s\n" % (cntrl))
cntrl.data_channel_size = params.data_width

I get the following output:

CHI.py -- Cntrl is .cpu0.l1i
CHI.py -- Cntrl is .cpu0.l1d
CHI.py -- Cntrl is .cpu1.l1i
CHI.py -- Cntrl is .cpu1.l1d
CHI.py -- Cntrl is .cpu2.l1i
CHI.py -- Cntrl is .cpu2.l1d
CHI.py -- Cntrl is .cpu3.l1i
CHI.py -- Cntrl is .cpu3.l1d
CHI.py -- Cntrl is .cpu0.l1i.downstream_destinations <== This 
looks wrong.
CHI.py -- Cntrl is .ruby.hnf.cntrl
CHI.py -- Cntrl is .ruby.snf.cntrl

And I don't see any control for the L2 cache and I don't see the implementation 
for L2 cache in the config.ini

Any further help, much appreciated.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 20 July 2021 13:51
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

Hi Javed,

addSharedL2Cache is only called on lines 465 and 470 of CHI.py and these lines 
are touched only if options.littleclust_l2cache == 'shared'.
You don't set it in the command line and the default value is 'private', which 
explains why it never gets called.

Also I suspect that on lines 475 and 481 at least, you intended to call 
addSharedL2Cache instead of addPrivL2Cache.

Maybe you could start over from the original CHI_config.py file and add the 
addSharedL2Cache to CHI_RNF to check that it works in a simpler case. There 
should really not be much to change from addPricL2Cache implementation to get a 
shared L2. Walk your way up from a single cluster and single cpu cluster to a 
single cluster and dual cpu to a multi cluster and multi cpu configuration. 
Once you are sure about what needs to be done for a shared L2 cache to work, 
you will 

[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

I have been debugging and delving into more details of the code for CHI.py and 
CHI_config.py.
In the attached Winrar archive are the latest customised versions of CHI.py and 
CHI_config.py that I have generated to date.

When defining one cluster with N x CPUs and checking the config.ini file, I 
noticed that the L2$ generated was a private one for each CPU in the cluster as 
opposed to the L2$ being shared between the CPUs in the cluster (this was 
making use of CHI_config.CHI_RNF() CHI_config.CHI_RNF.addPrivL2Cache())

Therefore,  in CHI_config.py, I took a copy of CHI_RNF() class object and
1)  Renamed it CHI_RNF_CLUST_SHARED_L2
2)  Generated a new method, CHI_RNF_CLUST_SHARED_L2.addSharedL2Cache()

The run script I am using being:

  ./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby 
--topology=Pt2Pt --cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --n
um-l3caches=1 --num-cpu-bigclust=0 --num-cpu-middleclust=0 
--num-cpu-littleclust=4 --num-clusters=1 --cpu-type-bigclust=derivo3 --c
pu-type-middleclust=hpi  --cpu-type-littleclust=timesimple 
--bigclust-l2cache=shared --middleclust-l2cache=shared --littleclust-l2c
ache=shared --num-bigclust-subclust=1 --num-middleclust-subclust=1 
--num-littleclust-subclust=1 --cmd=tests/test-progs/hello/bin/ar
m/linux/hello

This defines one cluster (littleCluster) with four CPUs. Each CPU has its 
private & split L1 cache. Furthermore, it defines a shared L2 cache, shared 
amongst the 4 CPUs in the cluster.

The HelloWorld program completes okay.
But checking the config.ini file (in the attachment),
1)  Can see the 4 x CPUs with their private L1 caches
2)  Cannot see the shared L2 cache which should be associated with the 
littleCluster.

Any insight into why I am unable to implement the shared L2Cache would be much 
appreciated.

Thanks in advance
JO


-Original Message-
From: Javed Osmany
Sent: 12 July 2021 09:29
To: gem5 users mailing list 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: CHI - Cluster CPUs having a private L2 cache

Hello Gabriel

Thank you for your reply. Will realise your suggestions.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 12 July 2021 09:23
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
mailto:gabriel.bus...@arteris.com>>
Subject: [gem5-users] Re: CHI - Cluster CPUs having a private L2 cache

Hi Javed,

This looks fine to me, at least regarding L2s being private.
CHI_config.py:538 in the line where you instantiate a cache memory per CPU and 
CHI_config.py:557 is the line where you instantiate the CHI ruby controller 
that makes use of that cache memory instance.

One way to check if two python variables point to the same instance or not is 
to test them with "is": ((a is b) == True) means that a and b are the same  
object. (a is not b) is the test syntax you want to test for non-identity. Just 
check that ruby_system.littleCluster._cpus[i].l2 as well as 
ruby_system.littleCluster._cpus[i].l2.cache are different for all i.

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



chi_one_cluster_four_cpu_shared_l2.rar
Description: chi_one_cluster_four_cpu_shared_l2.rar
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: CHI - Cluster CPUs having a private L2 cache

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for your reply. Will realise your suggestions.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 12 July 2021 09:23
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI - Cluster CPUs having a private L2 cache

Hi Javed,

This looks fine to me, at least regarding L2s being private.
CHI_config.py:538 in the line where you instantiate a cache memory per CPU and 
CHI_config.py:557 is the line where you instantiate the CHI ruby controller 
that makes use of that cache memory instance.

One way to check if two python variables point to the same instance or not is 
to test them with "is": ((a is b) == True) means that a and b are the same  
object. (a is not b) is the test syntax you want to test for non-identity. Just 
check that ruby_system.littleCluster._cpus[i].l2 as well as 
ruby_system.littleCluster._cpus[i].l2.cache are different for all i.

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

[gem5-users] CHI - Cluster CPUs having a private L2 cache

[Javed Osmany via gem5-users]

Hello

I am using CHI and I want to model the scenario where the CPUs are in a cluster 
and each cluster CPU has private L1 and L2 caches.

I have modified CHI.py and CHI_config.py.

In CHI_config.py, I have taken a copy of CHI_RNF() class object and renamed the 
copied version CHI_RNF_CLUST_PRIV_L2(). Within this new class object I have 
modified the code to realise a private L2cache for each CPU in the cluster.

I have tried to test with the generation of one cluster 
(ruby_system.littleCluster) with four CPUs.

I am attaching the WinZip rar file which includes the modified versions of 
CHI.py, CHI_config.py. Also included is the log file from generating one 
cluster and zero cluster.

Have added print statements for debugging. In particular, for the modified 
CHI.py, added print statement between lines   574-576, I get the following 
output:

CHI.py -- Cntrl is .cpu0.l1i
CHI.py -- Cntrl is .cpu0.l1d
CHI.py -- Cntrl is .cpu1.l1i
CHI.py -- Cntrl is .cpu1.l1d
CHI.py -- Cntrl is .cpu2.l1i
CHI.py -- Cntrl is .cpu2.l1d
CHI.py -- Cntrl is .cpu3.l1i
CHI.py -- Cntrl is .cpu3.l1d
CHI.py -- Cntrl is .cpu0.l2
CHI.py -- Cntrl is .cpu1.l2
CHI.py -- Cntrl is .cpu2.l2
CHI.py -- Cntrl is .cpu3.l2

When I look at the above debug output, it is not clear whether four private 
L2$'s have been generated or just one L2$ which is shared between all four 
CPUs. I am comparing the above with the output when zero clusters are specified 
(log file for zero clusters is also attached).

Could someone with more expertise in CHI implementation in GEM5 than myself, 
please let me know if the generated L2$'s for one cluster are private or shared>

Thanks in advance.

JO



chi_one_cluster.rar
Description: chi_one_cluster.rar
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello Gabriel

I have now fixed the issue causing the error. It was related to incorrect 
generation of the bigCluster and littleCluster.
The HelloWorld program is now executing okay when configured to generate the 
bigCluster and littleCluster.

There is one anomaly I wanted to clarify:

1) Running the HelloWorld program, but CHI.py configured for no clusters, I get 
the following info when I add print statement for cntrl at line 224 in CHI.py.

The command used to run being:

./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-littleclust=3 --num-clusters=0 
--cpu-type-bigclust=DerivO3CPU --cpu-type-littleclust=DerivO3CPU 
--cmd=tests/test-progs/hello/bin/arm/linux/hello


CHI.py -- Cntrl is .cpu0.l1i
CHI.py -- Cntrl is .cpu0.l1d
CHI.py -- Cntrl is .cpu0.l2
CHI.py -- Cntrl is .cpu1.l1i
CHI.py -- Cntrl is .cpu1.l1d
CHI.py -- Cntrl is .cpu1.l2
CHI.py -- Cntrl is .cpu2.l1i
CHI.py -- Cntrl is .cpu2.l1d
CHI.py -- Cntrl is .cpu2.l2
CHI.py -- Cntrl is .cpu3.l1i
CHI.py -- Cntrl is .cpu3.l1d
CHI.py -- Cntrl is .cpu3.l2
CHI.py -- Cntrl is .ruby.hnf.cntrl
CHI.py -- Cntrl is .ruby.snf.cntrl

As can be seen the L2 Caches for each CPU is private, as expected.

2) Running the HelloWorld program, but CHI.py configured for [bigCluster, 
littleCluster], I get the following info when I add print statement for cntrl 
at line 224 in CHI.py. The command used to run being


./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-littleclust=3 --num-clusters=2 
--cpu-type-bigclust=DerivO3CPU --cpu-type-littleclust=DerivO3CPU 
--cmd=tests/test-progs/hello/bin/arm/linux/hello



CHI.py -- Cntrl is .cpu0.l1i
CHI.py -- Cntrl is .cpu0.l1d
CHI.py -- Cntrl is .cpu1.l1i
CHI.py -- Cntrl is .cpu1.l1d
CHI.py -- Cntrl is .cpu2.l1i
CHI.py -- Cntrl is .cpu2.l1d
CHI.py -- Cntrl is .cpu0.l2
CHI.py -- Cntrl is .cpu1.l2
CHI.py -- Cntrl is .cpu2.l2
CHI.py -- Cntrl is .cpu3.l1i
CHI.py -- Cntrl is .cpu3.l1d
CHI.py -- Cntrl is .cpu3.l2
CHI.py -- Cntrl is .ruby.hnf.cntrl
CHI.py -- Cntrl is .ruby.snf.cntrl

In this case, littleCluster consists of CPU[2:0] and bigCluster consists of 
CPU[3].
Now for CPU[2:0], the debug info being:

CHI.py -- Cntrl is .cpu0.l2
  CHI.py -- Cntrl is .cpu1.l2
  CHI.py -- Cntrl is .cpu2.l2


Is this showing that the L2Cache is shared between CPU[2:0] or is it showing 
that each of CPU[0], CPU[1] and CPU[2] has a private L2Cache?

Similarly for CPU[3]'s L2 Cache.

Thanks in advance

Best regards
JO
-Original Message-
From: Javed Osmany
Sent: 28 June 2021 12:58
To: gem5 users mailing list 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hello Gabriel

Thank you for the pointer.

Best regards

J.Osmany

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 28 June 2021 12:49
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
mailto:gabriel.bus...@arteris.com>>
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

This is an error from the dot file processing tool.
For some reason, likely a hard coded string buffer size, it does not support 
lines longer that 16384 lines.
Luckily, you don’t need it and can ignore this error.

The second error says that one of the parameters has no set value.
In your case, this is data_channel_size in Cache_Controller.
See CHI.py line 225 to see what you need to do.

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

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

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for the pointer.

Best regards

J.Osmany

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 28 June 2021 12:49
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

This is an error from the dot file processing tool.
For some reason, likely a hard coded string buffer size, it does not support 
lines longer that 16384 lines.
Luckily, you don’t need it and can ignore this error.

The second error says that one of the parameters has no set value.
In your case, this is data_channel_size in Cache_Controller.
See CHI.py line 225 to see what you need to do.

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

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hi Gabriel

Outlook blocked the attachments.
Resending the two files as WinRar archive.

Best regards
JO


_
From: Javed Osmany
Sent: 28 June 2021 11:35
To: gem5 users mailing list 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode


Hello Gabriel

Have tried to follow your flow. Have generated the custom version of CHI.py and 
se.py (both files attached).

I have used HelloWorld program to pipe flush.

The command I have used to run being:

./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-littleclust=3 --num-clusters=2 
--cpu-type-bigclust=DerivO3CPU --cpu-type-littleclust=DerivO3CPU 
--cmd=tests/test-progs/hello/bin/arm/linux/hello


1.  The Ruby memory system seems to have been generated with the two 
clusters (bigCluster and littleCluster) (checking m5out/config.ini)

[system.ruby]
type=RubySystem
children=bigCluster clk_domain hnf littleCluster network power_state snf
access_backing_store=false
all_instructions=false
block_size_bytes=64
clk_domain=system.ruby.clk_domain
eventq_index=0
hot_lines=false
memory_size_bits=48
num_of_sequencers=2
number_of_virtual_networks=4
phys_mem=Null
power_model=
power_state=system.ruby.power_state
randomization=false
system=system

2. However, I am getting the following run time errors:

warn: sys_port_proxy.slave is deprecated. `slave` is now called `in_ports`
warn: cntrl.memory is deprecated. The request port for Ruby memory output to 
the main memory is now called `memory_out_port`

Global frequency set at 1 ticks per second
warn: system.ruby.network.ext_links0.ext_node adopting orphan SimObject param 
'sequencer'
warn: system.ruby.network.ext_links1.ext_node adopting orphan SimObject param 
'sequencer'
['dot', '-Tsvg', '/tmp/tmp6kqukhxa'] return code: 1

stdout, stderr:
 b''
b'Error: /tmp/tmp6kqukhxa: syntax error in line 5993 scanning a quoted string 
(missing endquote? longer than 16384?)\nString 
starting:"adaptive_routingfalse\\buffer_size4\\clk_domainsystem.rub\n'
 <== Not sure which file the syntax error is occurring

warn: failed to generate dot output from m5out/config.dot
warn: DRAM device capacity (8192 Mbytes) does not match the address range 
assigned (512 Mbytes)
fatal: system.cpu0.l1d.data_channel_size without default or user set value


Any pointers as to where I should look to resolve the  errors?

Thanks in advance
JO



-Original Message-
From: Javed Osmany
Sent: 24 June 2021 10:09
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Gabriel Busnot 
mailto:gabriel.bus...@arteris.com>>; Javed Osmany 
mailto:javed.osm...@huawei.com>>
Subject: RE: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hello Gabriel

Thank you for the updated information.
Will try to follow for the implementation.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 24 June 2021 08:33
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
mailto:gabriel.bus...@arteris.com>>
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

2- Yes, I meant to define L1ICache_big, L1ICache_little, etc. If you need 
different cache configurations. However, I didn't get that you need private 
L2s. But if you call the big and little clusters by the term "cluster", then I 
believe that each cluster has a single entry point to the coherent interconnect 
which usually is the master port of a shared cache. In that case, the CHI RN-F 
is what maps to such concept of CPU cluster. I would recommend starting with 
private L1s and shared L2 until things work, as this is natively supported by 
the CHI config files. Then, hack your way through the CHI config files to make 
the L2 private and add a shared L3 if needed. You will have to modify 
CHI_config.CHI_RNF.

3- create_system in CHI.py expects system to be populated with CPUs 
(system.cpu). The only thing that differs between a CPU type and another really 
is its accuracy : atomic, minor, O3, etc. The performance of the simulated CPU 
then depends on the specific parameters of that CPU but you can look at that 
later. Having said that, I would write something like:

assert(len(system.cpu) == options.num_cpus_little + options.num_cpus.big) 
ruby_system.little_cluster = CHI_RNF(system.cpu[:options.num_cpus_little], 
) ruby_system.big_cluster = 
CHI_RNF(system.cpu[-options.num_cpus_big:], )
ruby_system.little_cluster.addPrivL2Cache(...)
ruby_system.big_cluster.addPrivL2Cache(...)

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

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello Gabriel

Have tried to follow your flow. Have generated the custom version of CHI.py and 
se.py (both files attached).

I have used HelloWorld program to pipe flush.

The command I have used to run being:

./build/ARM/gem5.opt configs/example/se_kirin_custom.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-littleclust=3 --num-clusters=2 
--cpu-type-bigclust=DerivO3CPU --cpu-type-littleclust=DerivO3CPU 
--cmd=tests/test-progs/hello/bin/arm/linux/hello


1.  The Ruby memory system seems to have been generated with the two 
clusters (bigCluster and littleCluster) (checking m5out/config.ini)

[system.ruby]
type=RubySystem
children=bigCluster clk_domain hnf littleCluster network power_state snf
access_backing_store=false
all_instructions=false
block_size_bytes=64
clk_domain=system.ruby.clk_domain
eventq_index=0
hot_lines=false
memory_size_bits=48
num_of_sequencers=2
number_of_virtual_networks=4
phys_mem=Null
power_model=
power_state=system.ruby.power_state
randomization=false
system=system

2. However, I am getting the following run time errors:

warn: sys_port_proxy.slave is deprecated. `slave` is now called `in_ports`
warn: cntrl.memory is deprecated. The request port for Ruby memory output to 
the main memory is now called `memory_out_port`

Global frequency set at 1 ticks per second
warn: system.ruby.network.ext_links0.ext_node adopting orphan SimObject param 
'sequencer'
warn: system.ruby.network.ext_links1.ext_node adopting orphan SimObject param 
'sequencer'
['dot', '-Tsvg', '/tmp/tmp6kqukhxa'] return code: 1

stdout, stderr:
 b''
b'Error: /tmp/tmp6kqukhxa: syntax error in line 5993 scanning a quoted string 
(missing endquote? longer than 16384?)\nString 
starting:"adaptive_routingfalse\\buffer_size4\\clk_domainsystem.rub\n'
 <== Not sure which file the syntax error is occurring

warn: failed to generate dot output from m5out/config.dot
warn: DRAM device capacity (8192 Mbytes) does not match the address range 
assigned (512 Mbytes)
fatal: system.cpu0.l1d.data_channel_size without default or user set value


Any pointers as to where I should look to resolve the  errors?

Thanks in advance
JO



-Original Message-
From: Javed Osmany
Sent: 24 June 2021 10:09
To: gem5 users mailing list 
Cc: Gabriel Busnot ; Javed Osmany 

Subject: RE: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hello Gabriel

Thank you for the updated information.
Will try to follow for the implementation.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 24 June 2021 08:33
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
mailto:gabriel.bus...@arteris.com>>
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

2- Yes, I meant to define L1ICache_big, L1ICache_little, etc. If you need 
different cache configurations. However, I didn't get that you need private 
L2s. But if you call the big and little clusters by the term "cluster", then I 
believe that each cluster has a single entry point to the coherent interconnect 
which usually is the master port of a shared cache. In that case, the CHI RN-F 
is what maps to such concept of CPU cluster. I would recommend starting with 
private L1s and shared L2 until things work, as this is natively supported by 
the CHI config files. Then, hack your way through the CHI config files to make 
the L2 private and add a shared L3 if needed. You will have to modify 
CHI_config.CHI_RNF.

3- create_system in CHI.py expects system to be populated with CPUs 
(system.cpu). The only thing that differs between a CPU type and another really 
is its accuracy : atomic, minor, O3, etc. The performance of the simulated CPU 
then depends on the specific parameters of that CPU but you can look at that 
later. Having said that, I would write something like:

assert(len(system.cpu) == options.num_cpus_little + options.num_cpus.big) 
ruby_system.little_cluster = CHI_RNF(system.cpu[:options.num_cpus_little], 
) ruby_system.big_cluster = 
CHI_RNF(system.cpu[-options.num_cpus_big:], )
ruby_system.little_cluster.addPrivL2Cache(...)
ruby_system.big_cluster.addPrivL2Cache(...)

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



CHI.py
Description: CHI.py


se_kirin_custom.py
Description: se_kirin_custom.py
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for the updated information.
Will try to follow for the implementation.

Best regards
JO

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 24 June 2021 08:33
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

2- Yes, I meant to define L1ICache_big, L1ICache_little, etc. If you need 
different cache configurations. However, I didn't get that you need private 
L2s. But if you call the big and little clusters by the term "cluster", then I 
believe that each cluster has a single entry point to the coherent interconnect 
which usually is the master port of a shared cache. In that case, the CHI RN-F 
is what maps to such concept of CPU cluster. I would recommend starting with 
private L1s and shared L2 until things work, as this is natively supported by 
the CHI config files. Then, hack your way through the CHI config files to make 
the L2 private and add a shared L3 if needed. You will have to modify 
CHI_config.CHI_RNF.

3- create_system in CHI.py expects system to be populated with CPUs 
(system.cpu). The only thing that differs between a CPU type and another really 
is its accuracy : atomic, minor, O3, etc. The performance of the simulated CPU 
then depends on the specific parameters of that CPU but you can look at that 
later. Having said that, I would write something like:

assert(len(system.cpu) == options.num_cpus_little + options.num_cpus.big) 
ruby_system.little_cluster = CHI_RNF(system.cpu[:options.num_cpus_little], 
) ruby_system.big_cluster = 
CHI_RNF(system.cpu[-options.num_cpus_big:], )
ruby_system.little_cluster.addPrivL2Cache(...)
ruby_system.big_cluster.addPrivL2Cache(...)

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

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for the pointer.
Made a start on this and just wanted to check if I have understood you 
correctly..

>> 1- Define two more options in CHI.py to specify the number of big (B) 
and the number of little (L) cpus from the command line

Okay, Done.

   >>  2- Define the L1ICache, L1DCache and L2DCache for each the big and the 
little cluster

Do you mean for each of the Big and Little CPUs?
I originally want the L1$ and L2$ to be private for each CPU.

>> 3- Pass the first B cpus as a single list together with the correct 
caches to the first CHI_RNF. Assign the result to ruby_system.bigCluster.

So I tried to following code: Initially assuming that the L1 caches are the 
same for all the CPU is the system

big_cpu = []
for i in range(int(options.num_cpu_bigclust)):
big_cpu.append(options.cpu_type_bigclust)

print ("Big CPUs are: %s" % (big_cpu))   ## Since number of big cluster 
cpu is set to 1, it prints out: Big CPUs are: ['DerivO3CPU']

# now define the big cluster
# pass the b_cpu list to the CHI_RNF() class
ruby_system.bigCluster = [ CHI_RNF([b_cpu], ruby_system, L1ICache, 
L1DCache, system.cache_line_size.value)
  for b_cpu in big_cpu ]


I am not sure if the above code matches your expectation (high level)??.
I am passing the number of big cpus as a list and currently assuming the 
default L1ICache and L1DCache.

Furthermore, the above generates the following error: For both the Big and 
Little CPU I have used DerivO3CPU


Error: could not create sytem for ruby protocol CHI
Traceback (most recent call last):
  File "", line 1, in 
  File "build/ARM/python/m5/main.py", line 455, in main
exec(filecode, scope)
  File "configs/example/se.py", line 254, in 
Ruby.create_system(options, False, system)
  File "/home/j00533938/github/gem5-21.0/gem5/configs/ruby/Ruby.py", line 194, 
in create_system
% protocol)
  File "", line 1, in 
  File "/home/j00533938/github/gem5-21.0/gem5/configs/ruby/CHI.py", line 279, 
in create_system
for b_cpu in big_cpu ]
  File "/home/j00533938/github/gem5-21.0/gem5/configs/ruby/CHI.py", line 279, 
in 
for b_cpu in big_cpu ] <== This is complaining about the above code that I 
have added, highlighted in purple
  File "/home/j00533938/github/gem5-21.0/gem5/configs/ruby/CHI_config.py", line 
401, in __init__
ruby_system = ruby_system)
AttributeError: 'str' object has no attribute 'inst_sequencer'

The command line I have used being:

./build/ARM/gem5.opt configs/example/se.py --ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=4 --num-dirs=1 --num-l3caches=1 
--num-cpu-bigclust=1 --num-cpu-littleclust=3 --cpu-type-bigclust=DerivO3CPU  
--cpu-type-littleclust=DerivO3CPU 
--cmd=tests/test-progs/hello/bin/arm/linux/hello


The issue seems to be the following code that I have added:

ruby_system.bigCluster = [ CHI_RNF([b_cpu], ruby_system, L1ICache, L1DCache, 
system.cache_line_size.value)
  for b_cpu in big_cpu ]


Any pointers to help resolve the issue, much appreciated.

Best regards
JO
-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org]
Sent: 21 June 2021 17:02
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

I don't think that you want to use devices.CpuCluster as it is used to manage 
classic caches while you want to use Ruby caches.

My first approach would be, using se.py as is:
1- Define two more options in CHI.py to specify the number of big (B) and 
the number of little (L) cpus from the command line
2- Define the L1ICache, L1DCache and L2DCache for each the big and the 
little cluster
3- Pass the first B cpus as a single list together with the correct caches 
to the first CHI_RNF. Assign the result to ruby_system.bigCluster.
4- Pass the last L cpus as a single list together with the correct caches 
to the second CHI_RNF. Assign the result to ruby_system.littleCluster.
5- Add the private L2 cache of the correct type to both cluster.
Keep everything else as is.

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

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

[gem5-users] Re: [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Many thanks for the pointers, Gabriel.

Best Regards

J.Osmany
 

-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 21 June 2021 17:02
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: [Big, Little] clusters with CHI and SE mode

Hi Javed,

I don't think that you want to use devices.CpuCluster as it is used to manage 
classic caches while you want to use Ruby caches.

My first approach would be, using se.py as is:
1- Define two more options in CHI.py to specify the number of big (B) and 
the number of little (L) cpus from the command line
2- Define the L1ICache, L1DCache and L2DCache for each the big and the 
little cluster
3- Pass the first B cpus as a single list together with the correct caches 
to the first CHI_RNF. Assign the result to ruby_system.bigCluster.
4- Pass the last L cpus as a single list together with the correct caches 
to the second CHI_RNF. Assign the result to ruby_system.littleCluster.
5- Add the private L2 cache of the correct type to both cluster.
Keep everything else as is.

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

[gem5-users] [Big, Little] clusters with CHI and SE mode

[Javed Osmany via gem5-users]

Hello

I am trying to model a system such as

1) Initially there are two clusters, [big, little]

a.  Have studied fs_bigLITTLE.py to see how the different clusters are 
generated.

2) Make use of CHI

3) Run the system in SE mode.

The command I am planning to use is the following (using HelloWorld to 
pipeflush initially)

./build/ARM/gem5.opt configs/example/se.py -ruby --topology=Pt2Pt 
--cpu-type=DerivO3CPU --num-cpus=2 --num-dirs=1 --num-l3caches=1  
--cmd=tests/test-progs/hello/bin/arm/linux/hello

So I started making modifications in CHI.py.
High level the plan being

1) Generate RNF_Big for the number of cpus and the type of CPU in the big 
cluster.

2) Then add a private L2$ for each RNF in  RNF_Big (intent originally being 
to have private L2$ for each RNF. Change this late to have shared L2$)

3) Repeat (1) and (2) for the Little cluster (ie Generate RNF_Little)

The code snippet being:

##
   ## Map each BigCluster CPU into an
## RNF
##
for i in range(options.num_cpus_bigclust):
ruby_system.rnf_big = [ CHI_RNF([cpu], ruby_system, L1ICache, L1DCache,
system.cache_line_size.value)
  for cpu in options.cpu_type_bigclust ]


# Now add a private L2 cache for each RNF in BigCluster
for rnf_big in ruby_system.rnf_big:
rnf_big.addPrivL2Cache(L2Cache)


#
## Map each LittleCluster CPU into an
## RNF
#
for i in range(options.num_cpus_littleclust):
ruby_system.rnf_little = [ CHI_RNF([cpu], ruby_system, L1ICache, 
L1DCache,
   system.cache_line_size.value)
 for cpu in options.cpu_type_littleclust ]


# Now add a private L2 cache for each RNF in LittleCluster
for rnf_little in ruby_system.rnf_little:
rnf_little.addPrivL2Cache(L2Cache)



Next I want to map

1) ruby_system.rnf_big ==> ruby_system.rnf_bigCluster

2) ruby_system.rnf_little ==> ruby_system.rnf_littleCluster.


So from looking in fs_bigLITTLE.py, I have added the following class inside 
create_system() of CHI.py for BigCluster:

## Define the class for BigCluster and LittleCluster
## Extracted from fs_bigLITTLE.py
#
# BigCluster class
class BigCluster(devices.CpuCluster):
# This defines the constructor function for the BigCluster class.
def __init__(self, system, num_cpus, cpu_clock, cpu_voltage="1.0V"):
# Dont understand what cpu_config is doing ???
cpu_config = [ ObjectList.cpu_list.get("DerivO3CPU"),
   devices.L1I, devices.L1D, devices.WalkCache, devices.L2 ]
# super() allows access to the __init__() (constructor) of the base 
class
# namely devices.CpuCluster class.
super(BigCluster, self).__init__(system, num_cpus, cpu_clock,
 cpu_voltage, *cpu_config)

And then to instantiate the BigCluster, the tentative code being:

##
## Generate Big Cluster
##
if options.num_cpus_bigclust > 0:
## Call to BigCluster() class
ruby_system.bigCluster = BigCluster(ruby_system, 
options.num_cpu_bigclust,
options.big_cpu_clock)
ruby_system.mem_mode = ruby_system.bigCluster.memoryMode()
else:
m5.fatal("Number of CPUs in Big Cluster is Zero.")

Pretty certain this is not going to work. But I don't know how to solve this.

For the class BigCluster(), I would like to pass the following for cpu_config:

 cpu_config = [ruby_system.rnf_big, ## this is the actual cpu being used in 
the RNF for the big cluster
   None,   ## L1I$ has 
already been define
   None,   ## L1D$ has 
already been defined
   devices.WalkCache,
   None)## L2$ has 
already been defined.



Any thought/pointers as how to get the above resolved will be much appreciated.


Best regards
JO

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

[gem5-users] Re: CHI and caches

[Javed Osmany via gem5-users]

Many thanks for the clarification, Gabriel.

Best regards
JO


-Original Message-
From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] 
Sent: 18 June 2021 17:02
To: gem5-users@gem5.org
Cc: Gabriel Busnot 
Subject: [gem5-users] Re: CHI and caches

Hi,

O3_ARM_v7a_3 comes with predefined cache configurations that correspond to this 
specific CPU: O3_ARM_v7a_DCache, O3_ARM_v7a_ICache, etc.
However, these caches are effectively used only if CacheConfig.config_cache() 
is called. This does not happen if --ruby is used with the fs.py and se.py 
files.

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

[gem5-users] CHI and caches

[Javed Osmany via gem5-users]

Hello

I have been studying the CHI documentation and the configs/ruby/CHI.py file.

Both the code and the documentation mention about

1)  Map each CPU in the system to an RNF with private and split L1 caches

2)  Add a private L2 cache to each RNF


So what happens if the CPU model already has implemented L1/L2 caches (ie - if 
cpu type is O3_ARM_v7a_3)? Are the existing caches stripped out and CHI 
compliant caches added?

Thanks in advance?
JO

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

[gem5-users] Re: System() and RubySystem()

[Javed Osmany via gem5-users]

Many thanks for the clarification Giacomo.

Best regards
JO

-Original Message-
From: Giacomo Travaglini [mailto:giacomo.travagl...@arm.com] 
Sent: 16 June 2021 11:36
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: System() and RubySystem()

Hi Javed,

You are correct in your assumptions. I believe the confusion arises from the 
overuse of the "System" keyword. As a summary, The System class (defined in 
src/sim/system.hh) is the child of the Root node and encompasses most of the 
simulated models (cpu, memory subsystem, devices, etc).

The RubySystem is a child of the System class (system.ruby = RubySystem() adds 
the RubySystem to the SimObject hierarchy under the system node).
In other words, the RubySystem is a subsystem, whose only purpose is to parent 
ruby memory models. It is not a replacement for the System class nor a 
different implementation

Kind regards

Giacomo

> -Original Message-
> From: Javed Osmany via gem5-users 
> Sent: 16 June 2021 11:17
> To: gem5 users mailing list 
> Cc: Javed Osmany 
> Subject: [gem5-users] FW: System() and RubySystem()
>
> Hello
>
>
>
> Wondering if any help to clear up the issues listed in my previous email?
>
>
>
> Tks
>
> JO
>
>
>
> From: Javed Osmany
> Sent: 14 June 2021 14:18
> To: gem5 users mailing list 
> Cc: Javed Osmany 
> Subject: System() and RubySystem()
>
>
>
> Hello
>
>
>
> Trying to understand the following:
>
>
>
> So in example config scripts I see the following:
>
>
>
> system = System() // Is this then instantiating the default 
> overall system ??
>
>
>
> Now, I understand that there are two types of memory system, namely 
> classic and Ruby.
>
>
>
> And then if "-ruby" is specified on the command line, the script 
> Ruby.py is called.
>
> Within Ruby.py, the function creat_system() is called and in Ruby.py 
> (lines
> 193 - 194), we have the code
>
>
>
>system.ruby = Ruby.System() // Is this then instantiating the 
> Ruby memory system within the overall System() ??
>
>ruby= system.ruby // This is then just an alias ??
>
>
>
>
>
> Thanks in advance.
>
> J.Osmany

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-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] FW: System() and RubySystem()

[Javed Osmany via gem5-users]

Hello

Wondering if any help to clear up the issues listed in my previous email?

Tks
JO

From: Javed Osmany
Sent: 14 June 2021 14:18
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: System() and RubySystem()

Hello

Trying to understand the following:

So in example config scripts I see the following:

system = System() // Is this then instantiating the default overall 
system ??

Now, I understand that there are two types of memory system, namely classic and 
Ruby.

And then if "-ruby" is specified on the command line, the script Ruby.py is 
called.
Within Ruby.py, the function creat_system() is called and in Ruby.py (lines 193 
- 194), we have the code

   system.ruby = Ruby.System() // Is this then instantiating the Ruby 
memory system within the overall System() ??
   ruby= system.ruby // This is then just an alias ??


Thanks in advance.
J.Osmany
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] System() and RubySystem()

[Javed Osmany via gem5-users]

Hello

Trying to understand the following:

So in example config scripts I see the following:

system = System() // Is this then instantiating the default overall 
system ??

Now, I understand that there are two types of memory system, namely classic and 
Ruby.

And then if "-ruby" is specified on the command line, the script Ruby.py is 
called.
Within Ruby.py, the function creat_system() is called and in Ruby.py (lines 193 
- 194), we have the code

   system.ruby = Ruby.System() // Is this then instantiating the Ruby 
memory system within the overall System() ??
   ruby= system.ruby // This is then just an alias ??


Thanks in advance.
J.Osmany
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Arm bitLITTLE config

[Javed Osmany via gem5-users]

Hello  Giacomo

Many thanks for your answers.

Best regards
JO 

-Original Message-
From: Giacomo Travaglini [mailto:giacomo.travagl...@arm.com] 
Sent: 09 June 2021 15:44
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: Arm bitLITTLE config

Hi Javed

> -Original Message-
> From: Javed Osmany via gem5-users 
> Sent: 09 June 2021 15:01
> To: gem5 users mailing list 
> Cc: Javed Osmany 
> Subject: [gem5-users] Arm bitLITTLE config
>
> Hello
>
>
>
> The system I would like to model consists of three clusters [Big, 
> Middle, Little]
>
> Each cluster can have different CPU types and either private or shared 
> L2 cache.
>
>
>
> Can the config/example/arm/fs_bigLITTLE.py config
>
> 1)  Support three different clusters?

Not out of the box. But bear in mind that gem5 configs are in general meant to 
be example configs to be extended by users to reflect own hardware organizations

>
> 2)  If the answer to 1) is no, is it possible to extend it to model three
> different clusters

Yes, it shouldn't be that complicated

>
> a.   If extension is possible, any insight into how to achieve this would 
> be
> much appreciated

Gem5 standard library (m5) doesn't really have a notion of a cluster. You can 
add an extra cluster by adapting the fs_bigLITTLE script. No C++ change and no 
recompilation is likely needed

>
> 3)  As the name implies (fs_bigLITTLE.py) this config needs to be run in 
> Full
> System mode.
>
> a.   Is there a version of bigLITTLE config that can be run in SE mode?


No there isn't, but we should probably consider adding it

>
>i.  I am 
> trying to run the PARSEC benchmarks
> and would like to run in SE mode to study coherence performance.
>
>
>
> Thanks in advance
>
>
>
> JO

Kind regards

Giacomo

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-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Arm bitLITTLE config

[Javed Osmany via gem5-users]

Hello

The system I would like to model consists of three clusters [Big, Middle, 
Little]
Each cluster can have different CPU types and either private or shared L2 cache.

Can the config/example/arm/fs_bigLITTLE.py config

1)  Support three different clusters?

2)  If the answer to 1) is no, is it possible to extend it to model three 
different clusters

a.   If extension is possible, any insight into how to achieve this would 
be much appreciated

3)  As the name implies (fs_bigLITTLE.py) this config needs to be run in 
Full System mode.

a.   Is there a version of bigLITTLE config that can be run in SE mode?

   i.  I am 
trying to run the PARSEC benchmarks and would like to run in SE mode to study 
coherence performance.

Thanks in advance

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

[gem5-users] Re: Running CHI protocol configurations

[Javed Osmany via gem5-users]

Hello Gabriel

Thank you for your answers.

To address the points you have raised:

>> [GB] First, downstream_destination is the set of possible destinations for 
>> this component. It does not mean that it will actually communicate will all 
>> of them. It depends on the rest of your configuration.

The command line I am using to run the simple test being:

./build/ARM/gem5.opt configs/example/se.py --ruby --topology=Pt2Pt --num-cpus=4 
--num-dirs=2 --num-l3caches=2 --cmd=tests/test-progs/hello/bin/arm/linux/hello

So this is making use of the default CHI.py and CHI_config.py

>> Second, you don’t specify explicitly which snf a given hnf communicates 
>> with. Instead, each hnf is responsible for a given [set of] address ranges 
>> and each snf is also responsible for a [set of] address ranges. There is no 
>> need for hnf and snf address ranges to correspond.

As mentioned above, I am using the default configs. Therefore, where could I 
find the above information (ie which snf a given hnf communicates with). I 
could not see it in config.ini.



>> However, if you setup an hnf and a snf to be mapped to the same address 
>> ranges, they will exclusively communicate with each other.

That makes sense.


>> With the default CHI.py file, I believe this corresponds to configurations 
>> where --num-dirs and num-l3caches are equal.

Yes. I tried using different values for –num-dirs and num-l3caches and this 
then generated a run time error.


Best regards
JO
From: Gabriel Busnot [mailto:gabriel.bus...@arteris.com]
Sent: 02 June 2021 15:44
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: Running CHI protocol configurations

Hi Javed,

Answers inline.

Best,
Gabriel

From: Javed Osmany via gem5-users 
mailto:gem5-users@gem5.org>>
Sent: 02 June 2021 16:21
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: Javed Osmany mailto:javed.osm...@huawei.com>>
Subject: [gem5-users] Running CHI protocol configurations


[EXTERNAL EMAIL]
Hello

Have generated an ARM ISA gem5.opt executable, where the PROTOCOL CHI.

Running the simple “Hello World” program on a config of [4 RNFs, 2 HNFs, 2 
SNFs] and looking at the config.ini file, there are a few things I don’t 
understand.

The command I use being:

./build/ARM/gem5.opt configs/example/se.py --ruby --topology=Pt2Pt --num-cpus=4 
--num-dirs=2 --num-l3caches=2 --cmd=tests/test-progs/hello/bin/arm/linux/hello

From config.ini, we have

[system]
type=System
children=clk_domain cpu0 cpu1 cpu2 cpu3 cpu_clk_domain cpu_voltage_domain 
dvfs_handler mem_ctrls0 mem_ctrls1 redirect_paths0 redirect_paths1 
redirect_paths2 ruby sys_port_proxy voltage_domain workload
  :
mem_mode=timing
mem_ranges=0:536870912 <== Memory is 512 MBytes
memories=system.mem_ctrls0.dram system.mem_ctrls1.dram

[system.ruby]
type=RubySystem
children=clk_domain hnf0 hnf1 network power_state rnf0 rnf1 rnf2 rnf3 snf0 snf1 
<== So have instantiated the 4 x RNFs, 2 x HNFs, 2 x SNFs
access_backing_store=false
all_instructions=false
block_size_bytes=64
clk_domain=system.ruby.clk_domain
eventq_index=0
hot_lines=false
memory_size_bits=48
num_of_sequencers=4
number_of_virtual_networks=4
phys_mem=Null
power_model=
power_state=system.ruby.power_state
randomization=false
system=system

[system.ruby.hnf0.cntrl]
type=Cache_Controller
children=cache datIn datOut mandatoryQueue power_state prefetchQueue 
replTriggerQueue reqIn reqOut reqRdy retryTriggerQueue rspIn rspOut snpIn 
snpOut snpRdy triggerQueue
addr_ranges=0:536870912:0:64 <== What does this mean?? (range is 0: 512 Mbytes. 
What does :0:64 imply??) (Similar query for system.ruby.h
nf1.cntrl.addr_range)

[GB] This is an interleaved address range. In that particular case, hnf are 
interleaved on 64 bytes blocks and there are as many interleavings as there are 
hnf (2 in your case). 0:64 means that it is the interleaving with ID 0 and 64 
is the base 10 representation of the interleaving mask (single mask in that 
case). Please look carefully at AddrRange in src/python/m5/params.py for more 
details about address interleaving in gem5.
  :
downstream_destinations=system.ruby.snf0.cntrl system.ruby.snf1.cntrl <== If I 
wanted a configuration where hnf0.cntrl only communicated to 
system.ruby.snf0.cntrl, would I need to generate a custom version of 
CHI_configs.py or do I need to provide a custom version of CHI.py and 
CHI_configs.py?
[GB] First, downstream_destination is the set of possible destinations for this 
component. It does not mean that it will actually communicate will all of them. 
It depends on the rest of your configuration.
Second, you don’t specify explicitly which snf a given hnf communicates with. 
Instead, each hnf is responsible for a given [set of] address ranges and each 
snf is also responsible for a [set of] address ranges. There is no need for hnf 
and snf address ranges to correspond.
However, if you setup an hnf

[gem5-users] Running CHI protocol configurations

[Javed Osmany via gem5-users]

Hello

Have generated an ARM ISA gem5.opt executable, where the PROTOCOL CHI.

Running the simple "Hello World" program on a config of [4 RNFs, 2 HNFs, 2 
SNFs] and looking at the config.ini file, there are a few things I don't 
understand.

The command I use being:

./build/ARM/gem5.opt configs/example/se.py --ruby --topology=Pt2Pt --num-cpus=4 
--num-dirs=2 --num-l3caches=2 --cmd=tests/test-progs/hello/bin/arm/linux/hello

>From config.ini, we have

[system]
type=System
children=clk_domain cpu0 cpu1 cpu2 cpu3 cpu_clk_domain cpu_voltage_domain 
dvfs_handler mem_ctrls0 mem_ctrls1 redirect_paths0 redirect_paths1 
redirect_paths2 ruby sys_port_proxy voltage_domain workload
  :
mem_mode=timing
mem_ranges=0:536870912 <== Memory is 512 MBytes
memories=system.mem_ctrls0.dram system.mem_ctrls1.dram

[system.ruby]
type=RubySystem
children=clk_domain hnf0 hnf1 network power_state rnf0 rnf1 rnf2 rnf3 snf0 snf1 
<== So have instantiated the 4 x RNFs, 2 x HNFs, 2 x SNFs
access_backing_store=false
all_instructions=false
block_size_bytes=64
clk_domain=system.ruby.clk_domain
eventq_index=0
hot_lines=false
memory_size_bits=48
num_of_sequencers=4
number_of_virtual_networks=4
phys_mem=Null
power_model=
power_state=system.ruby.power_state
randomization=false
system=system

[system.ruby.hnf0.cntrl]
type=Cache_Controller
children=cache datIn datOut mandatoryQueue power_state prefetchQueue 
replTriggerQueue reqIn reqOut reqRdy retryTriggerQueue rspIn rspOut snpIn 
snpOut snpRdy triggerQueue
addr_ranges=0:536870912:0:64 <== What does this mean?? (range is 0: 512 Mbytes. 
What does :0:64 imply??) (Similar query for system.ruby.hnf1.cntrl.addr_range)
  :
downstream_destinations=system.ruby.snf0.cntrl system.ruby.snf1.cntrl <== If I 
wanted a configuration where hnf0.cntrl only communicated to 
system.ruby.snf0.cntrl, would I need to generate a custom version of 
CHI_configs.py or do I need to provide a custom version of CHI.py and 
CHI_configs.py?


[system.ruby.hnf0.cntrl.cache]
type=RubyCache
children=replacement_policy
assoc=16
block_size=0 <== Why is the block size 0 ??
   :

Thanks in advance
JO
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Using the CHI protocol for GEM5

[Javed Osmany via gem5-users]

Hello Giacomo

Thanks for the info.

Yes, I have been going through the documentation and the blog.

Best regards
JO

-Original Message-
From: Giacomo Travaglini [mailto:giacomo.travagl...@arm.com] 
Sent: 18 May 2021 14:52
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: RE: Using the CHI protocol for GEM5

Hi Javed,

> -Original Message-
> From: Javed Osmany via gem5-users 
> Sent: 18 May 2021 14:16
> To: gem5-users@gem5.org
> Cc: Javed Osmany 
> Subject: [gem5-users] Using the CHI protocol for GEM5
>
> Hello
>
>
>
> Previously, when experimenting with MESI or MOESI coherence protocol, 
> the approach was to build the gem5.opt for the specific protocol. For 
> example
>
>
>
> scons -j4 build/ARM_MESI_3_level/gem5.opt --default=ARM 
> PROTOCOL=MESI_Three_Level SLICC_HTML=True
>
>
>
>
>
> I would like to experiment with the CHI protocol. Do I also need to 
> build the gem5.opt executable with PROTOCOL=CHI?

Yes, you could explicitly select CHI via the PROTOCOL option, though it is not 
strictly necessary (CHI is the current default for Arm builds):

$rm -rf build -> clean the environment if you were building with another 
protocol $scons -j4 build/ARM/gem5.opt -> This will build CHI

>
>
>
> Any pointers to where the above is detailed would be appreciated.

I recommend you to have a look at the guide provided by Tiago [1]

>
>
>
> Tks in advance
>
>
>
> JO
>
>

Kind regards

Giacomo

[1]: http://www.gem5.org/documentation/general_docs/ruby/CHI/
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-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Using the CHI protocol for GEM5

[Javed Osmany via gem5-users]

Hello

Previously, when experimenting with MESI or MOESI coherence protocol, the 
approach was to build the gem5.opt for the specific protocol. For example

scons -j4 build/ARM_MESI_3_level/gem5.opt --default=ARM 
PROTOCOL=MESI_Three_Level SLICC_HTML=True


I would like to experiment with the CHI protocol. Do I also need to build the 
gem5.opt executable with PROTOCOL=CHI?

Any pointers to where the above is detailed would be appreciated.

Tks in advance

JO

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

[gem5-users] Re: Running Gem5/Ruby tests

[Javed Osmany via gem5-users]

Hello

Looking in /usr/lib64 on my system, it shows:

[j00533938@lhrplinux1 lib64]$ pwd
/usr/lib64
[j00533938@lhrplinux1 lib64]$ /bin/ls -al libstdc*
lrwxrwxrwx 1 root root 19 Sep 26  2019 libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 991616 Aug  6  2019 libstdc++.so.6.0.19

Just wondering if this is an issue with not linking to the correct version of 
libstdc++.so

Tks in advance.


JO


From: Javed Osmany
Sent: 02 June 2020 16:11
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: Running Gem5/Ruby tests

Hello

I am trying to get started running some very simple tests on Gem5/Ruby. 
However, I am getting errors:

[j00533938@lhrplinux1 gem5]$ ./build/X86_MSI/gem5.opt configs/example/se.py 
--ruby --cpu_type=timing -c tests/test-progs/hello/bin/x86/linux/hello
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not 
found (required by ./build/X86_MSI/gem5.opt)
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not 
found (required by ./build/X86_MSI/gem5.opt)


[j00533938@lhrplinux1 gem5]$ ./build/X86/gem5.opt configs/example/se.py 
--ruby --cpu_type=timing -c tests/test-progs/hello/bin/x86/linux/hello
./build/X86/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found 
(required by ./build/X86/gem5.opt)
./build/X86/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 
(required by ./build/X86/gem5.opt)


./build/X86_MSI/gem5.opt configs/learning_gem5/part3/simple_ruby.py
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not 
found (required by ./build/X86_MSI/gem5.opt)
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not 
found (required by ./build/X86_MSI/gem5.opt)


Any pointers to fix the above issues, greatly appreciated.

Thanks in advance.

JO

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

[gem5-users] Running Gem5/Ruby tests

[Javed Osmany via gem5-users]

Hello

I am trying to get started running some very simple tests on Gem5/Ruby. 
However, I am getting errors:

[j00533938@lhrplinux1 gem5]$ ./build/X86_MSI/gem5.opt configs/example/se.py 
--ruby --cpu_type=timing -c tests/test-progs/hello/bin/x86/linux/hello
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not 
found (required by ./build/X86_MSI/gem5.opt)
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not 
found (required by ./build/X86_MSI/gem5.opt)


[j00533938@lhrplinux1 gem5]$ ./build/X86/gem5.opt configs/example/se.py 
--ruby --cpu_type=timing -c tests/test-progs/hello/bin/x86/linux/hello
./build/X86/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found 
(required by ./build/X86/gem5.opt)
./build/X86/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 
(required by ./build/X86/gem5.opt)


./build/X86_MSI/gem5.opt configs/learning_gem5/part3/simple_ruby.py
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not 
found (required by ./build/X86_MSI/gem5.opt)
./build/X86_MSI/gem5.opt: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not 
found (required by ./build/X86_MSI/gem5.opt)


Any pointers to fix the above issues, greatly appreciated.

Thanks in advance.

JO

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

[gem5-users] Re: GEM5/Ruby and MESI_Three_Level protocol

[Javed Osmany via gem5-users]

Hello

Okay. I had not realised that some of the files were shared between 
MESI_Three_Level and MESI_Two_Level.
That would explain why MESI_Three_level is comiling okay.

Tks for the pointer.

Best regards

J.Osmany


From: Shehab Elsayed [mailto:shehaby...@gmail.com]
Sent: 28 May 2020 16:49
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: Re: [gem5-users] GEM5/Ruby and MESI_Three_Level protocol

Which files do you think are missing? There are some shared files between 
MESI_Three_Level and MESI_Two-Level such as the L2 controller. You can find a 
list of all files used by the MESI_Three_Level protocol in 
src/mem/ruby/protocol/MESI_Three_Level.slicc. I hope this helps.

On Thu, May 28, 2020 at 11:37 AM Javed Osmany via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hello


1.   I am able to successfully generate the executable gem5 simulator for 
[ARM ISA, MESI_Three_Level protocol]. The command I used being:

a.   scons -j4 build/ARM_MESI_3_level/gem5.opt --default=ARM 
PROTOCOL=MESI_Three_Level SLICC_HTML=True


2.   Also, I am able successfully generate the executable gem5 simulator 
for [X86 ISA, MESI_Three_Level protocol]. The command I used being:

a.   scons -j4 build/X86_MESI_3_level/gem5.opt --default=X86 
PROTOCOL=MESI_Three_Level SLICC_HTML=True

However, if I look in src/mem/ruby/protocol, the code for MESI_Three_Level is 
as follows:

[j00533938@lhrplinux1 protocol]$ ll MESI_Three_Level*
-rw-rw-r-- 1 j00533938 j00533938 40031 May 28 09:17 MESI_Three_Level-L0cache.sm
-rw-rw-r-- 1 j00533938 j00533938 36841 May 28 09:17 MESI_Three_Level-L1cache.sm
-rw-rw-r-- 1 j00533938 j00533938  4270 May 28 09:17 MESI_Three_Level-msg.sm
-rw-rw-r-- 1 j00533938 j00533938   316 Mar 20 17:42 MESI_Three_Level.slicc


Therefore, it looks to me that the code for MESI_Three_Level is not complete. 
Thus it is not clear to me how the executable gem5 simulator for 
MESI_Three_Level is being generated.


Any thoughts on this please?

Thanks in advance.
JO

___
gem5-users mailing list -- gem5-users@gem5.org<mailto:gem5-users@gem5.org>
To unsubscribe send an email to 
gem5-users-le...@gem5.org<mailto:gem5-users-le...@gem5.org>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] GEM5/Ruby and MESI_Three_Level protocol

[Javed Osmany via gem5-users]

Hello


1.   I am able to successfully generate the executable gem5 simulator for 
[ARM ISA, MESI_Three_Level protocol]. The command I used being:

a.   scons -j4 build/ARM_MESI_3_level/gem5.opt --default=ARM 
PROTOCOL=MESI_Three_Level SLICC_HTML=True


2.   Also, I am able successfully generate the executable gem5 simulator 
for [X86 ISA, MESI_Three_Level protocol]. The command I used being:

a.   scons -j4 build/X86_MESI_3_level/gem5.opt --default=X86 
PROTOCOL=MESI_Three_Level SLICC_HTML=True

However, if I look in src/mem/ruby/protocol, the code for MESI_Three_Level is 
as follows:

[j00533938@lhrplinux1 protocol]$ ll MESI_Three_Level*
-rw-rw-r-- 1 j00533938 j00533938 40031 May 28 09:17 MESI_Three_Level-L0cache.sm
-rw-rw-r-- 1 j00533938 j00533938 36841 May 28 09:17 MESI_Three_Level-L1cache.sm
-rw-rw-r-- 1 j00533938 j00533938  4270 May 28 09:17 MESI_Three_Level-msg.sm
-rw-rw-r-- 1 j00533938 j00533938   316 Mar 20 17:42 MESI_Three_Level.slicc


Therefore, it looks to me that the code for MESI_Three_Level is not complete. 
Thus it is not clear to me how the executable gem5 simulator for 
MESI_Three_Level is being generated.


Any thoughts on this please?

Thanks in advance.
JO

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

[gem5-users] Re: GEM5/Ruby

[Javed Osmany via gem5-users]

Many Thanks Jason for the answer and pointers.


Best Regards

J.Osmany
From: Jason Lowe-Power [mailto:ja...@lowepower.com]
Sent: 18 May 2020 21:25
To: gem5 users mailing list 
Cc: Javed Osmany 
Subject: Re: [gem5-users] GEM5/Ruby

Hi Javed,

Unfortunately, there's no protocols in gem5 out of the box that model *exactly* 
what you need. However, SLICC allows you to write your own protocols! It sounds 
like that is what would be best if you need such a specific coherence protocol. 
See http://www.gem5.org/documentation/general_docs/ruby/slicc/ and 
http://www.gem5.org/documentation/learning_gem5/part3/MSIintro/ for more 
information.

Cheers,
Jason

On Mon, May 18, 2020 at 8:43 AM Javed Osmany via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hello

I would like to define a multicore system in GEM5 and then use the Ruby memory 
system to simulate the different coherence protocols.

In my system I have three levels of caches (L1I$, L1D$ (using MSI), unified L2$ 
(using MOESI) and LLC (using MESI))

How to generate the optimised GEM5 executable simulator to handle the three 
different coherence protocol in the system?


Thanks in advance

JO
___
gem5-users mailing list -- gem5-users@gem5.org<mailto:gem5-users@gem5.org>
To unsubscribe send an email to 
gem5-users-le...@gem5.org<mailto:gem5-users-le...@gem5.org>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] GEM5/Ruby

[Javed Osmany via gem5-users]

Hello

I would like to define a multicore system in GEM5 and then use the Ruby memory 
system to simulate the different coherence protocols.

In my system I have three levels of caches (L1I$, L1D$ (using MSI), unified L2$ 
(using MOESI) and LLC (using MESI))

How to generate the optimised GEM5 executable simulator to handle the three 
different coherence protocol in the system?


Thanks in advance

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