Re: [gem5-users] problem with gem5 and McPat
Hello I also faced this problem. In my case it was caused by the fact that the parameters at the system level (number_of_cores, number_of_L2s, number_of_NoCs etc. in power.xml file) that had a value of 1 were not described afterwards in detailed. If you post your power.xml file I can take a look at it and maybe give you a bit more insight. Best regards, Alexandru Iordan From: Bojun Ma To: gem5 users mailing list Sent: Friday, July 13, 2012 8:39 AM Subject: [gem5-users] problem with gem5 and McPat Hi, All, Any one has successfully integrated McPAT with gem5? I used m5-mcpat-parser to get the power.xml file. But when I used it as the input of McPAT. Always Error: The value of homogeneous_cores or number_of_cores is not correct! Any idea of how to debug it? I traced the source code of McPAT, but cannot figure it out. Thanks in advance. Regards, Bojun Ma ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Ruby frequency not working?
Hi Xi, The clock is a parameter of type Clock, and it is specified in terms of a clock period in units of ticks internally. Hence, your setting as a frequency will end up being printed as a clock period. Hope it helps. Andreas From: gem5-users-boun...@gem5.org [gem5-users-boun...@gem5.org] On Behalf Of Xi Chen [xiche...@gmail.com] Sent: Thursday, July 12, 2012 6:53 PM To: gem5-users@gem5.org Subject: Re: [gem5-users] Ruby frequency not working? Hi all, I tried another way to adjust the frequency. Set –clock= to 0.5GHz, 0.33GHz, 0.2GHz, then in the config.ini file the corresponding clock under “system.ruby” became 2,3,5. So the frequency adjustment does work, but the question is why set clock to 2,3,4 GHz, the system does not change and set clock to 0.5,0.33 and 0.2 the real clock is 1/0.5=2, 1/0.33~3 and 1/0.2=5? Sorry for bothering! Thanks, Xi -- 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 http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Problem with the style checker when pulling
Hi all, I have run into this error when I have tried to update my working repository: Traceback (most recent call last): File "/home/npremill/work/simulators/mygem5-test/util/style.py", line 464, in check_style return do_check_style(ui, repo, **args) File "/home/npremill/work/simulators/mygem5-test/util/style.py", line 425, in do_check_style regions = modregions(wctx, fname) File "/home/npremill/work/simulators/mygem5-test/util/style.py", line 81, in modregions mod_regions.add(0, len(lines)) AttributeError: 'Regions' object has no attribute 'add' It seems that some people have already encountered this error but it has never been fixed. It seems that replacing in util/style.py (l. 81) mod_regions.add(0, len(lines)) by mod_regions.append(0, len(lines)) fix the error. However, I don't know if there is any other side effects. Nathanaël ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] How to fix "Unable to find destination for addr..."
Dear all,
My investigations regarding this error
fatal: Unable to find destination for addr 0x21620f580 on bus system.membus
reveals that this error can be fixed by increasing the main memory size.
Verification:
1) I have defined a 8192MB memory such as
physmem = PhysicalMemory(range=AddrRange("8192MB")
2) 8192MB equals 0x2, however the destination address is 0x21620f580
It is good to add a FAQ entry for this error.
Hope this help others.
--
// Naderan *Mahmood;
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Ruby frequency not working?
Hi Andreas, Thanks for the clarification. So when I set --clock in the command line, the config.ini file prints clock period, is that right? That is also explains why you cannot set more than 1GHz in Ruby network frequency, because 1GHz is the smallest clock period or we can treat it as base clock period, when you set more than 1GHz, you cannot shrink base clock period anymore but expand it by setting smaller clock frequency. Is my understanding correct? Thanks, Xi -- Hi Xi, The clock is a parameter of type Clock, and it is specified in terms of a clock period in units of ticks internally. Hence, your setting as a frequency will end up being printed as a clock period. Hope it helps. Andreas From: gem5-users-boun...@gem5.org [gem5-users-boun...@gem5.org] On Behalf Of Xi Chen [xiche...@gmail.com] Sent: Thursday, July 12, 2012 6:53 PM To: gem5-users@gem5.org Subject: Re: [gem5-users] Ruby frequency not working? Hi all, I tried another way to adjust the frequency. Set –clock= to 0.5GHz, 0.33GHz, 0.2GHz, then in the config.ini file the corresponding clock under “system.ruby” became 2,3,5. So the frequency adjustment does work, but the question is why set clock to 2,3,4 GHz, the system does not change and set clock to 0.5,0.33 and 0.2 the real clock is 1/0.5=2, 1/0.33~3 and 1/0.2=5? Sorry for bothering! Thanks, Xi -- 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. -- Xi Chen ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] forward invalidations to lsq
Hi Nilay,
Sorry for late response, I din't check my emails since last night :).
Anyway, so the checkviolations part that we are talking about, that takes care
of not having any CMP violation of coherence, but it does not re-execute a load
(not at the front of the commit queue) and following younger insts upon
receiving a snoop invalidation request, so in my understanding it does not
enforce the strict load-load ordering of a stronger model. So i add couple of
lines in checkSnoop: see the changes below
(1) the first if clause of checking the " // If there are no loads in the LSQ
we don't care" condition was wrong i guess in the existing code, it actually
was checking"If there are no loads in the LSQ we don't care" with the "if
(load_idx == loadTail)" clause. So with an additional if clause, I make sure
that if the snoop hits the front of the load queue, then nothing need to be
done.
(2) further I add a clause towards the end of checkSnoop () with needSC
condition to check, if the snoop hits a executed load that is not at the front
of the queue, reexecutes using ReExec (hopefully ReExec squashs all the younger
insts including that and re-fetches, as i understood from Ali's response)
The other changes that I did to maintain SC is to add few more constraints on
the load queue to ensure store-load ordering, ie a load in the load queue can
not retire from ROB until and unless the committed store instructions before
that in the program order are exposed to the memory system, as a result a load
can still receive snoop invalidates and need to be re-executed, if needed. I
can post my changes to enforce SC for review.
template
void
LSQUnit::checkSnoop(PacketPtr pkt)
{
int load_idx = loadHead;
if (!cacheBlockMask) {
assert(dcachePort);
Addr bs = dcachePort->peerBlockSize();
// Make sure we actually got a size
assert(bs != 0);
cacheBlockMask = ~(bs - 1);
}
// If there are no loads in the LSQ we don't care
if (load_idx == loadTail) {
DPRINTF(LSQUnit, "loadHead: %d, loadTail:%d\n", loadHead, loadTail);
//assert(0);
return;
}
// If this is the only load in the LSQ we don't care
if (loadTail == (load_idx + 1)) {
DPRINTF(LSQUnit, "loadHead: %d, loadTail:%d\n", loadHead, loadTail);
//assert(0);
return;
}
incrLdIdx(load_idx);
DPRINTF(LSQUnit, "Got snoop for address %#x\n", pkt->getAddr());
Addr invalidate_addr = pkt->getAddr() & cacheBlockMask;
while (load_idx != loadTail) {
DynInstPtr ld_inst = loadQueue[load_idx];
if (!ld_inst->effAddrValid || ld_inst->uncacheable()) {
incrLdIdx(load_idx);
continue;
}
Addr load_addr = ld_inst->physEffAddr & cacheBlockMask;
DPRINTF(LSQUnit, "-- inst [sn:%lli] load_addr: %#x to pktAddr:%#x\n",
ld_inst->seqNum, load_addr, invalidate_addr);
if (load_addr == invalidate_addr) {
if (ld_inst->possibleLoadViolation) {
DPRINTF(LSQUnit, "Conflicting load at addr %#x [sn:%lli]\n",
ld_inst->physEffAddr, pkt->getAddr(), ld_inst->seqNum);
// Mark the load for re-execution
ld_inst->fault = new ReExec;
} else {
// If a older load checks this and it's true
// then we might have missed the snoop
// in which case we need to invalidate to be sure
ld_inst->hitExternalSnoop = true;
if (needsSC == true){
ld_inst->fault = new ReExec;
}
}
}
incrLdIdx(load_idx);
}
return;
}
On 07/12/12, Nilay Vaish wrote:
> Dibakar, any progress on this front?
>
> On Wed, 27 Jun 2012, Ali Saidi wrote:
>
> >
> >
> >Hi Dibakar,
> >
> >I'm not saying that I believe this is correct for x86.
> >It seems like x86 does require more ordering than is currently provided
> >by the lsq. Hopefully someone with more x86 experience could chime in
> >and confirm that. The faulting mechanism needs an overhaul in the o3
> >cpu. There shouldn't be any fundamental difference.
> >
> >Thanks,
> >
> >Ali
> >
> >On
> >27.06.2012 18:08, Dibakar Gope wrote:
> >
> >>Hi Ali,
> >>
> >>from this thread,
> >http://www.mail-archive.com/gem5-dev@gem5.org/msg00782.html, I get an
> >idea that a snoop invalidate will make a younger load and its following
> >younger instructions to re-execute, if only an older load in the program
> >order to the same cache block see an updated value. But I am not still
> >sure, if it obeys the load-load ordering of a stronger consistency model
> >other than ARM. Suppose for example,
> >>C0 C1
> >>St A Ld C
> >>St B Ld A
> >>
> >
> >>In the above scenario, if the memory order becomes Ld A -> St A -> St
> >B -> Ld C and if C1 receives an invalidation for cache block A, before
> >Ld A make it to the front of the commit queue, still checkViolations()
> >code won't squash the Ld A and any younger instructions to maintain
> >strong consistency.
> >>
> >>My other doubt is that, can we make use of the
> >squashDueToMemOrder() squash mechanism instead of using ReExec fault, if
> >I want to squash the load A and younger instructions and re-fetch those
> >again in the above scenario? ReExec waits for the faulted instruction to
> >reach the front of
Re: [gem5-users] forward invalidations to lsq
If you could post it for review it would be a lot easier to
understand since the email seems to have stripped all indenting.
Thanks,
Ali
On 13.07.2012 12:47, Dibakar Gope wrote:
> Hi
Nilay,
>
> Sorry for late response, I din't check my emails since last
night :).
>
> Anyway, so the checkviolations part that we are talking
about, that takes care of not having any CMP violation of coherence, but
it does not re-execute a load (not at the front of the commit queue) and
following younger insts upon receiving a snoop invalidation request, so
in my understanding it does not enforce the strict load-load ordering of
a stronger model. So i add couple of lines in checkSnoop: see the
changes below
> (1) the first if clause of checking the " // If there
are no loads in the LSQ we don't care" condition was wrong i guess in
the existing code, it actually was checking"If there are no loads in the
LSQ we don't care" with the "if (load_idx == loadTail)" clause. So with
an additional if clause, I make sure that if the snoop hits the front of
the load queue, then nothing need to be done.
> (2) further I add a
clause towards the end of checkSnoop () with needSC condition to check,
if the snoop hits a executed load that is not at the front of the queue,
reexecutes using ReExec (hopefully ReExec squashs all the younger insts
including that and re-fetches, as i understood from Ali's response)
>
>
The other changes that I did to maintain SC is to add few more
constraints on the load queue to ensure store-load ordering, ie a load
in the load queue can not retire from ROB until and unless the committed
store instructions before that in the program order are exposed to the
memory system, as a result a load can still receive snoop invalidates
and need to be re-executed, if needed. I can post my changes to enforce
SC for review.
>
> template
> void
> LSQUnit::checkSnoop(PacketPtr
pkt)
> {
> int load_idx = loadHead;
>
> if (!cacheBlockMask) {
>
assert(dcachePort);
> Addr bs = dcachePort->peerBlockSize();
>
> //
Make sure we actually got a size
> assert(bs != 0);
>
> cacheBlockMask
= ~(bs - 1);
> }
>
> // If there are no loads in the LSQ we don't
care
> if (load_idx == loadTail) {
> DPRINTF(LSQUnit, "loadHead: %d,
loadTail:%dn", loadHead, loadTail);
> //assert(0);
> return;
> }
>
> //
If this is the only load in the LSQ we don't care
> if (loadTail ==
(load_idx + 1)) {
> DPRINTF(LSQUnit, "loadHead: %d, loadTail:%dn",
loadHead, loadTail);
> //assert(0);
> return;
> }
>
incrLdIdx(load_idx);
> DPRINTF(LSQUnit, "Got snoop for address %#xn",
pkt->getAddr());
> Addr invalidate_addr = pkt->getAddr() &
cacheBlockMask;
> while (load_idx != loadTail) {
> DynInstPtr ld_inst =
loadQueue[load_idx];
>
> if (!ld_inst->effAddrValid ||
ld_inst->uncacheable()) {
> incrLdIdx(load_idx);
> continue;
> }
>
>
Addr load_addr = ld_inst->physEffAddr & cacheBlockMask;
>
DPRINTF(LSQUnit, "-- inst [sn:%lli] load_addr: %#x to pktAddr:%#xn",
>
ld_inst->seqNum, load_addr, invalidate_addr);
>
> if (load_addr ==
invalidate_addr) {
> if (ld_inst->possibleLoadViolation) {
>
DPRINTF(LSQUnit, "Conflicting load at addr %#x [sn:%lli]n",
>
ld_inst->physEffAddr, pkt->getAddr(), ld_inst->seqNum);
>
> // Mark the
load for re-execution
> ld_inst->fault = new ReExec;
> } else {
> // If
a older load checks this and it's true
> // then we might have missed
the snoop
> // in which case we need to invalidate to be sure
>
ld_inst->hitExternalSnoop = true;
>
> if (needsSC == true){
>
>
ld_inst->fault = new ReExec;
> }
> }
> }
> incrLdIdx(load_idx);
> }
>
return;
> }
>
> On 07/12/12, Nilay Vaish wrote:
>
>> Dibakar, any
progress on this front? On Wed, 27 Jun 2012, Ali Saidi wrote:
>>
>>>
Hi Dibakar, I'm not saying that I believe this is correct for x86. It
seems like x86 does require more ordering than is currently provided by
the lsq. Hopefully someone with more x86 experience could chime in and
confirm that. The faulting mechanism needs an overhaul in the o3 cpu.
There shouldn't be any fundamental difference. Thanks, Ali On 27.06.2012
18:08, Dibakar Gope wrote:
>>>
Hi Ali, from this thread,
>>>
http://www.mail-archive.com/gem5-dev@gem5.org/msg00782.html [3], I get
an idea that a snoop invalidate will make a younger load and its
following younger instructions to re-execute, if only an older load in
the program order to the same cache block see an updated value. But I am
not still sure, if it obeys the load-load ordering of a stronger
consistency model other than ARM. Suppose for example,
>>>
C0 C1
St A Ld C St B Ld A
>
>
___
> gem5-users mailing
list
> gem5-users@gem5.org
>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Links:
--
[1] mailto:gem5-users@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
http://www.mail-archive.com/gem5-dev@gem5.org/msg00782.html
[4]
mailto:gem5-users@gem5.org
[5]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[6]
mailto:gem5-users@
Re: [gem5-users] forward invalidations to lsq
Sure I will do that; let me see how can I make a diff file with all the changes
(changes need to be made to obey store-load ordering of a stronger model too!)
and post it for review.
Thanks,
dibakar
On 07/13/12, Ali Saidi wrote:
>
>
>
>
>
>
> If you could post it for review it would be a lot easier to understand since
> the email seems to have stripped all indenting.
>
>
>
> Thanks,
>
> Ali
>
>
>
> On 13.07.2012 12:47, Dibakar Gope wrote:
>
> >
> > Hi Nilay, Sorry for late response, I din't check my emails since last night
> > :). Anyway, so the checkviolations part that we are talking about, that
> > takes care of not having any CMP violation of coherence, but it does not
> > re-execute a load (not at the front of the commit queue) and following
> > younger insts upon receiving a snoop invalidation request, so in my
> > understanding it does not enforce the strict load-load ordering of a
> > stronger model. So i add couple of lines in checkSnoop: see the changes
> > below (1) the first if clause of checking the " // If there are no loads in
> > the LSQ we don't care" condition was wrong i guess in the existing code, it
> > actually was checking"If there are no loads in the LSQ we don't care" with
> > the "if (load_idx == loadTail)" clause. So with an additional if clause, I
> > make sure that if the snoop hits the front of the load queue, then nothing
> > need to be done. (2) further I add a clause towards the end of checkSnoop
> > () with needSC condition to check,
if the snoop hits a executed load that is not at the front of the queue,
reexecutes using ReExec (hopefully ReExec squashs all the younger insts
including that and re-fetches, as i understood from Ali's response) The other
changes that I did to maintain SC is to add few more constraints on the load
queue to ensure store-load ordering, ie a load in the load queue can not retire
from ROB until and unless the committed store instructions before that in the
program order are exposed to the memory system, as a result a load can still
receive snoop invalidates and need to be re-executed, if needed. I can post my
changes to enforce SC for review. template void LSQUnit::checkSnoop(PacketPtr
pkt) { int load_idx = loadHead; if (!cacheBlockMask) { assert(dcachePort); Addr
bs = dcachePort->peerBlockSize(); // Make sure we actually got a size assert(bs
!= 0); cacheBlockMask = ~(bs - 1); } // If there are no loads in the LSQ we
don't care if (load_idx == loadTail) { DPRINTF(LSQUnit, "loa
dHead: %d, loadTail:%d\n", loadHead, loadTail); //assert(0); return; } // If
this is the only load in the LSQ we don't care if (loadTail == (load_idx + 1))
{ DPRINTF(LSQUnit, "loadHead: %d, loadTail:%d\n", loadHead, loadTail);
//assert(0); return; } incrLdIdx(load_idx); DPRINTF(LSQUnit, "Got snoop for
address %#x\n", pkt->getAddr()); Addr invalidate_addr = pkt->getAddr() &
cacheBlockMask; while (load_idx != loadTail) { DynInstPtr ld_inst =
loadQueue[load_idx]; if (!ld_inst->effAddrValid || ld_inst->uncacheable()) {
incrLdIdx(load_idx); continue; } Addr load_addr = ld_inst->physEffAddr &
cacheBlockMask; DPRINTF(LSQUnit, "-- inst [sn:%lli] load_addr: %#x to
pktAddr:%#x\n", ld_inst->seqNum, load_addr, invalidate_addr); if (load_addr ==
invalidate_addr) { if (ld_inst->possibleLoadViolation) { DPRINTF(LSQUnit,
"Conflicting load at addr %#x [sn:%lli]\n", ld_inst->physEffAddr,
pkt->getAddr(), ld_inst->seqNum); // Mark the load for re-execution
ld_inst->fault = new ReExec; } else {
// If a older load checks this and it's true // then we might have missed the
snoop // in which case we need to invalidate to be sure
ld_inst->hitExternalSnoop = true; if (needsSC == true){ ld_inst->fault = new
ReExec; } } } incrLdIdx(load_idx); } return; } On 07/12/12, Nilay Vaish wrote:
> >
> > > Dibakar, any progress on this front? On Wed, 27 Jun 2012, Ali Saidi
> > > wrote:
> > > > Hi Dibakar, I'm not saying that I believe this is correct for x86. It
> > > > seems like x86 does require more ordering than is currently provided by
> > > > the lsq. Hopefully someone with more x86 experience could chime in and
> > > > confirm that. The faulting mechanism needs an overhaul in the o3 cpu.
> > > > There shouldn't be any fundamental difference. Thanks, Ali On
> > > > 27.06.2012 18:08, Dibakar Gope wrote:
> > > > > Hi Ali, from this thread,
> > > > http://www.mail-archive.com/gem5-dev@gem5.org/msg00782.html, I get an
> > > > idea that a snoop invalidate will make a younger load and its following
> > > > younger instructions to re-execute, if only an older load in the
> > > > program order to the same cache block see an updated value. But I am
> > > > not still sure, if it obeys the load-load ordering of a stronger
> > > > consistency model other than ARM. Suppose for example,
> > > > > C0 C1 St A Ld C St B Ld A
> > > >
> > > > > In the above scenario, if the memory order becomes Ld A -> St A -> St
> > > > B -> Ld C and if C1 re
[gem5-users] Problem booting O3CPU on X86 FS
Hi, I'd like to boot a 03CPU on X86-FS, but the boot stops with the messages: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) SMP alternatives: switching to UP code Freeing SMP alternatives: 34k freed -- The command I used was: build/X86/gem5.opt configs/example/fs.py --kernel=x86_64-vmlinux-2.6.22.9.smp --cpu-type=detailed Could anyone help me to solve this problem? Thanks a lot. Anderson ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Problem booting O3CPU on X86 FS
On Fri, 13 Jul 2012, Anderson Faustino wrote: Hi, I'd like to boot a 03CPU on X86-FS, but the boot stops with the messages: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) SMP alternatives: switching to UP code Freeing SMP alternatives: 34k freed -- The command I used was: build/X86/gem5.opt configs/example/fs.py --kernel=x86_64-vmlinux-2.6.22.9.smp --cpu-type=detailed Could anyone help me to solve this problem? For how long did you let gem5 run? It can take upwards of an hour for the system to reach the stage when it can start the 'init' process. -- Nilay ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] questions about x86 fs
To whom it may concern,
When I tried to compile and run x86 full system mode (referred to
http://www.mail-archive.com/gem5-users@gem5.org/msg00071.html and
http://www.mail-archive.com/gem5-users@m5sim.org/msg05271.html). I got the
following output:
command line: build/X86/m5.opt configs/example/fs.py
--kernel=/home/ytian/Documents/Gem5/x86-files/binaries/x86_64-vmlinux-2.6.22.9
--script=configs/boot/ls.rcS
warning: add_child('terminal'): child 'terminal' already has parent
Global frequency set at 1 ticks per second
info: kernel located at:
/home/ytian/Documents/Gem5/x86-files/binaries/x86_64-vmlinux-2.6.22.9
0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012
Listening for com_1 connection on port 3457
warn: Reading current count from inactive timer.
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7001
REAL SIMULATION
info: Entering event queue @ 0. Starting simulation...
warn: Don't know what interrupt to clear for console.
warn: instruction 'fxsave' unimplemented
warn: Tried to clear PCI interrupt 14
warn: Unknown mouse command 0xe1.
warn: instruction 'wbinvd' unimplemented
-
Is this output correct? I've no idea why there is a warning
"add_child('terminal'): child 'terminal' already has parent" and how I can
fix it.
Also are the following warns predictable or something wrong with my
compilation and running? Can you please tell me what the expected output
is? Please give me any suggestions.
Thanks,
Yingying
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
