date:20151029

[gem5-dev] changeset in gem5: kvm, arm: Fix compilation errors due to API c...

2015-10-29 Thread Victor Garcia

changeset 555325cbf464 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=555325cbf464
description:
kvm, arm: Fix compilation errors due to API changes

The checkpoint changes, along with the SMT patches have changed a
number of APIs. Adapt the ArmKvmCPU accordingly.

diffstat:

 src/arch/arm/kvm/arm_cpu.cc   |  4 ++--
 src/arch/arm/kvm/armv8_cpu.cc |  2 +-
 src/arch/arm/kvm/armv8_cpu.hh |  2 +-
 src/arch/arm/kvm/base_cpu.cc  |  4 ++--
 src/arch/arm/kvm/gic.hh   |  2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diffs (64 lines):

diff -r 524c44cf8278 -r 555325cbf464 src/arch/arm/kvm/arm_cpu.cc
--- a/src/arch/arm/kvm/arm_cpu.cc   Thu Oct 29 08:48:20 2015 -0400
+++ b/src/arch/arm/kvm/arm_cpu.cc   Thu Oct 29 08:48:23 2015 -0400
@@ -270,8 +270,8 @@
 Tick
 ArmKvmCPU::kvmRun(Tick ticks)
 {
-bool simFIQ(interrupts->checkRaw(INT_FIQ));
-bool simIRQ(interrupts->checkRaw(INT_IRQ));
+bool simFIQ(interrupts[0]->checkRaw(INT_FIQ));
+bool simIRQ(interrupts[0]->checkRaw(INT_IRQ));
 
 if (fiqAsserted != simFIQ) {
 fiqAsserted = simFIQ;
diff -r 524c44cf8278 -r 555325cbf464 src/arch/arm/kvm/armv8_cpu.cc
--- a/src/arch/arm/kvm/armv8_cpu.cc Thu Oct 29 08:48:20 2015 -0400
+++ b/src/arch/arm/kvm/armv8_cpu.cc Thu Oct 29 08:48:23 2015 -0400
@@ -123,7 +123,7 @@
 }
 
 void
-ArmV8KvmCPU::dump()
+ArmV8KvmCPU::dump() const
 {
 inform("Integer registers:\n");
 inform("  PC: %s\n", getAndFormatOneReg(INT_REG(regs.pc)));
diff -r 524c44cf8278 -r 555325cbf464 src/arch/arm/kvm/armv8_cpu.hh
--- a/src/arch/arm/kvm/armv8_cpu.hh Thu Oct 29 08:48:20 2015 -0400
+++ b/src/arch/arm/kvm/armv8_cpu.hh Thu Oct 29 08:48:23 2015 -0400
@@ -83,7 +83,7 @@
 ArmV8KvmCPU(ArmV8KvmCPUParams *params);
 virtual ~ArmV8KvmCPU();
 
-void dump() override;
+void dump() const override;
 
   protected:
 void updateKvmState() override;
diff -r 524c44cf8278 -r 555325cbf464 src/arch/arm/kvm/base_cpu.cc
--- a/src/arch/arm/kvm/base_cpu.cc  Thu Oct 29 08:48:20 2015 -0400
+++ b/src/arch/arm/kvm/base_cpu.cc  Thu Oct 29 08:48:23 2015 -0400
@@ -86,8 +86,8 @@
 Tick
 BaseArmKvmCPU::kvmRun(Tick ticks)
 {
-bool simFIQ(interrupts->checkRaw(INT_FIQ));
-bool simIRQ(interrupts->checkRaw(INT_IRQ));
+bool simFIQ(interrupts[0]->checkRaw(INT_FIQ));
+bool simIRQ(interrupts[0]->checkRaw(INT_IRQ));
 
 if (fiqAsserted != simFIQ) {
 fiqAsserted = simFIQ;
diff -r 524c44cf8278 -r 555325cbf464 src/arch/arm/kvm/gic.hh
--- a/src/arch/arm/kvm/gic.hh   Thu Oct 29 08:48:20 2015 -0400
+++ b/src/arch/arm/kvm/gic.hh   Thu Oct 29 08:48:23 2015 -0400
@@ -80,7 +80,7 @@
 void drainResume() override { verifyMemoryMode(); }
 
 void serialize(CheckpointOut ) const override;
-void unserialize(Checkpoint *cp, const std::string )  override;
+void unserialize(CheckpointIn )  override;
 
   public: // PioDevice
 AddrRangeList getAddrRanges() const { return addrRanges; }
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: dev: Fix segfault in flash device

2015-10-29 Thread Sascha Bischoff

changeset 406240a8e7ef in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=406240a8e7ef
description:
dev: Fix segfault in flash device

Fix a bug in which the flash device would write out of bounds and
could either trigger a segfault and corrupt the memory of other
objects. This was caused by using pageSize in the place of
pagesPerBlock when running the garbage collector.

Also, added an assert to flag this condition in the future.

diffstat:

 src/dev/arm/flash_device.cc |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diffs (13 lines):

diff -r 8e240cd8132a -r 406240a8e7ef src/dev/arm/flash_device.cc
--- a/src/dev/arm/flash_device.cc   Thu Oct 29 08:48:24 2015 -0400
+++ b/src/dev/arm/flash_device.cc   Thu Oct 29 08:48:25 2015 -0400
@@ -379,7 +379,8 @@
 block = locationTable[logic_page_addr].block * pagesPerBlock;
 
 //assumption: clean will improve locality
-for (uint32_t count = 0; count < pageSize; count++) {
+for (uint32_t count = 0; count < pagesPerBlock; count++) {
+assert(block + count < pagesPerDisk);
 locationTable[block + count].page = (block + count) %
 pagesPerBlock;
 ++count;
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: arm: Add secure flag to TableWalker request w...

2015-10-29 Thread Nathanael Premillieu

changeset 4daf60db14d7 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=4daf60db14d7
description:
arm: Add secure flag to TableWalker request when needed

diffstat:

 src/arch/arm/table_walker.cc |  11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diffs (35 lines):

diff -r 406240a8e7ef -r 4daf60db14d7 src/arch/arm/table_walker.cc
--- a/src/arch/arm/table_walker.cc  Thu Oct 29 08:48:25 2015 -0400
+++ b/src/arch/arm/table_walker.cc  Thu Oct 29 08:48:26 2015 -0400
@@ -523,6 +523,10 @@
 flag.set(Request::UNCACHEABLE);
 }
 
+if (currState->isSecure) {
+flag.set(Request::SECURE);
+}
+
 bool delayed;
 delayed = fetchDescriptor(l1desc_addr, (uint8_t*)>l1Desc.data,
   sizeof(uint32_t), flag, L1, ,
@@ -685,9 +689,6 @@
 flag.set(Request::UNCACHEABLE);
 }
 
-if (currState->isSecure)
-flag.set(Request::SECURE);
-
 currState->longDesc.lookupLevel = start_lookup_level;
 currState->longDesc.aarch64 = false;
 currState->longDesc.grainSize = Grain4KB;
@@ -934,6 +935,10 @@
 flag.set(Request::UNCACHEABLE);
 }
 
+if (currState->isSecure) {
+flag.set(Request::SECURE);
+}
+
 currState->longDesc.lookupLevel = start_lookup_level;
 currState->longDesc.aarch64 = true;
 currState->longDesc.grainSize = tg;
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: dev: Fix draining for UFSHostDevice and Flash...

2015-10-29 Thread Sascha Bischoff

changeset 8e240cd8132a in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8e240cd8132a
description:
dev: Fix draining for UFSHostDevice and FlashDevice

This patch fixes the drain logic for the UFSHostDevice and the
FlashDevice. In the case of the FlashDevice, the logic for CheckDrain
needed to be reversed, whilst in the case of the UFSHostDevice check
drain was never being called. In both cases the system would never
complete draining if the initial attampt to drain failed.

diffstat:

 src/dev/arm/flash_device.cc |  2 +-
 src/dev/arm/ufs_device.cc   |  4 
 2 files changed, 5 insertions(+), 1 deletions(-)

diffs (33 lines):

diff -r 555325cbf464 -r 8e240cd8132a src/dev/arm/flash_device.cc
--- a/src/dev/arm/flash_device.cc   Thu Oct 29 08:48:23 2015 -0400
+++ b/src/dev/arm/flash_device.cc   Thu Oct 29 08:48:24 2015 -0400
@@ -605,7 +605,7 @@
 void
 FlashDevice::checkDrain()
 {
-if (drainState() == DrainState::Draining)
+if (drainState() != DrainState::Draining)
 return;
 
 if (planeEvent.when() > curTick()) {
diff -r 555325cbf464 -r 8e240cd8132a src/dev/arm/ufs_device.cc
--- a/src/dev/arm/ufs_device.cc Thu Oct 29 08:48:23 2015 -0400
+++ b/src/dev/arm/ufs_device.cc Thu Oct 29 08:48:24 2015 -0400
@@ -1822,6 +1822,8 @@
 pendingDoorbells = 0;
 DPRINTF(UFSHostDevice, "Clear doorbell %X\n", UFSHCIMem.TRUTRLDBR);
 
+checkDrain();
+
 /**step6 raise interrupt*/
 gic->sendInt(intNum);
 DPRINTF(UFSHostDevice, "Send interrupt @ transaction: 0x%8x!\n",
@@ -1838,6 +1840,8 @@
 gic->clearInt(intNum);
 DPRINTF(UFSHostDevice, "Clear interrupt: 0x%8x!\n", countInt);
 
+checkDrain();
+
 if (!(UFSHCIMem.TRUTRLDBR)) {
 idlePhaseStart = curTick();
 }
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: Clarify cache MSHR handling on fill

2015-10-29 Thread Andreas Hansson

changeset 524c44cf8278 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=524c44cf8278
description:
mem: Clarify cache MSHR handling on fill

This patch addresses the upgrading of deferred targets in the MSHR,
and makes it clearer by explicitly calling out what is happening
(deferred targets are promoted if we get exclusivity without asking
for it).

diffstat:

 src/mem/cache/cache.cc |  16 ++--
 src/mem/cache/mshr.cc  |   7 +++
 src/mem/cache/mshr.hh  |   2 +-
 3 files changed, 14 insertions(+), 11 deletions(-)

diffs (78 lines):

diff -r 741b3059946e -r 524c44cf8278 src/mem/cache/cache.cc
--- a/src/mem/cache/cache.ccSun Oct 25 16:01:52 2015 -0700
+++ b/src/mem/cache/cache.ccThu Oct 29 08:48:20 2015 -0400
@@ -1190,7 +1190,6 @@
 
 // Initial target is used just for stats
 MSHR::Target *initial_tgt = mshr->getTarget();
-CacheBlk *blk = tags->findBlock(pkt->getAddr(), pkt->isSecure());
 int stats_cmd_idx = initial_tgt->pkt->cmdToIndex();
 Tick miss_latency = curTick() - initial_tgt->recvTime;
 PacketList writebacks;
@@ -1212,16 +1211,20 @@
 miss_latency;
 }
 
+// upgrade deferred targets if we got exclusive
+if (!pkt->sharedAsserted()) {
+mshr->promoteExclusive();
+}
+
 bool is_fill = !mshr->isForward &&
 (pkt->isRead() || pkt->cmd == MemCmd::UpgradeResp);
 
+CacheBlk *blk = tags->findBlock(pkt->getAddr(), pkt->isSecure());
+
 if (is_fill && !is_error) {
 DPRINTF(Cache, "Block for addr %#llx being updated in Cache\n",
 pkt->getAddr());
 
-// give mshr a chance to do some dirty work
-mshr->handleFill(pkt, blk);
-
 blk = handleFill(pkt, blk, writebacks);
 assert(blk != NULL);
 }
@@ -1262,9 +1265,10 @@
 // from above.
 if (tgt_pkt->cmd == MemCmd::WriteLineReq) {
 assert(!is_error);
-
+// we got the block in exclusive state, so promote any
+// deferred targets if possible
+mshr->promoteExclusive();
 // NB: we use the original packet here and not the response!
-mshr->handleFill(tgt_pkt, blk);
 blk = handleFill(tgt_pkt, blk, writebacks);
 assert(blk != NULL);
 
diff -r 741b3059946e -r 524c44cf8278 src/mem/cache/mshr.cc
--- a/src/mem/cache/mshr.cc Sun Oct 25 16:01:52 2015 -0700
+++ b/src/mem/cache/mshr.cc Thu Oct 29 08:48:20 2015 -0400
@@ -430,11 +430,10 @@
 
 
 void
-MSHR::handleFill(PacketPtr pkt, CacheBlk *blk)
+MSHR::promoteExclusive()
 {
-if (!pkt->sharedAsserted()
-&& !(hasPostInvalidate() || hasPostDowngrade())
-&& deferredTargets.needsExclusive) {
+if (deferredTargets.needsExclusive &&
+!(hasPostInvalidate() || hasPostDowngrade())) {
 // We got an exclusive response, but we have deferred targets
 // which are waiting to request an exclusive copy (not because
 // of a pending invalidate).  This can happen if the original
diff -r 741b3059946e -r 524c44cf8278 src/mem/cache/mshr.hh
--- a/src/mem/cache/mshr.hh Sun Oct 25 16:01:52 2015 -0700
+++ b/src/mem/cache/mshr.hh Thu Oct 29 08:48:20 2015 -0400
@@ -282,7 +282,7 @@
 
 bool promoteDeferredTargets();
 
-void handleFill(PacketPtr pkt, CacheBlk *blk);
+void promoteExclusive();
 
 bool checkFunctional(PacketPtr pkt);
 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Fwd: Line Address in SLICC

2015-10-29 Thread Potter, Brandon

Hi,

We should be able to figure it out with a little digging.

It appears that the output is generated with "--debug-flags=RubySlicc".  From 
the "*.sm" files, we can see that some of the actions have:
DPRINTF(RubySlicc, "Address: %#x, Data Block: %s\n", address, tbe.DataBlk);

These "*.sm" files are used to help generate code when gem5 compiles the Ruby 
protocol (which it seems that we're generating MOESI_CMP_directory).  Within 
the build folder in gem5, execute:
find ./build | xargs grep -I "$ACTION_NAME"
where $ACTION_NAME is the action name that encapsulates the DPRINTF above.

With "c_sendData..." supplied, it should generate a list of files like the 
following:
./build/X86/mem/protocol/L2Cache_Transitions.cc:
c_sendDataFromTBEToL1GETS(m_tbe_ptr, m_cache_entry_ptr, addr);
./build/X86/mem/protocol/L2Cache_Controller.hh:void 
c_sendDataFromTBEToL1GETS(L2Cache_TBE*& m_tbe_ptr, L2Cache_Entry*& ...

./build/X86/mem/protocol/L2Cache_Controller.cc:L2Cache_Controller::c_sendDataFromTBEToL1GETS(L2Cache_TBE*&
 m_tbe_ptr, ...
./build/X86/mem/protocol/L2Cache_Controller.cc:DPRINTF(RubyGenerated, 
"executing c_sendDataFromTBEToL1GETS\n");
./build/X86/mem/protocol/L2Cache_Controller.cc:   fatal("Error in 
action L2Cache:c_sendDataFromTBEToL1GETS: "

We figure out where the declaration is in the files above (looks like it's in 
"L2CacheController.cc").

In examining the file, we notice that "addr" is passed as a parameter into the 
functions.  The only place that it looks to be called from is 
"L2Cache_Transitions.cc"; it appears under "doTransitionWorker" which is called 
from "doTransition".
find ./build | xargs grep -I "doTransition"

This generates many files, but L2Cache_Wakeup.cc looks promising.  From 
examining the file, it looks like all of the addresses come from 
"((in_msg_ptr)).m_addr".  Seems like "in_msg_ptr" can any one of multiple 
message types (RequestMsg, TriggerMsg, ResponseMsg, etc..).
find ./build -name "RequestMsg.*"

Within the resulting files (Request.hh, Request.cc), it's not explicitly clear 
if the address is a line address or a normal address.  (It mentions that the 
address is a physical address though.)  However, we notice the 
"RequestMsg::print" statement.  Specifically, look at printAddress(m_addr).
find ./build | xargs grep -I "printAddress".

The definition of "printAddress" comes from 
"build/***/mem/ruby/common/Address.cc".  The function is masking the low order 
bits:
"<< maskLowOrderBits(addr, RubySystem::getBlockSizeBits())"
Given this information, it only makes sense for the m_addr in the message files 
to be a full address and not the line address.

Also, the data block output has the form: [ 0xXX 0xXX]; a byte can also be 
represented as 0xXX.  There are 64 of these 0xXX (just like a cache line).  So, 
it makes sense to suspect that this is the data for the line address that our 
full address would create.  You might try to verify that. :)

Regards,
Brandon

From: gem5-dev  on behalf of P Pinky 

Sent: Thursday, October 29, 2015 5:13 AM
To: gem5 Developer List
Subject: [gem5-dev] Fwd: Line Address in SLICC

Hi all

 I have tried to print the line address in protocol files from the
in_msg.LineAddress.

 So by tracing the file, i got the following output.

355500: system.ruby.l1_cntrl0: MOESI_CMP_directory-L1cache.sm:364: *Line
address: 2097216*

407000: system.ruby.l2_cntrl0: MOESI_CMP_directory-L2cache.sm:799: *Address:
2097216*, Data Block: [ 0x1 0x2d 0xca 0x17 0x0 0x0 0x48 0x1 0x2d 0xab 0x1f
0x0 0x0 0x48 0x1 0x2d 0xac 0x1f 0x0 0x0 0x48 0x1 0x2d 0x95 0x3f 0x0 0x0
0x48 0x8d 0x3d 0x9e 0xff 0xff 0xff 0x48 0x81 0xe7 0x0 0x0 0xe0 0xff 0x48
0x89 0xf8 0x48 0xc1 0xe8 0x1e 0x48 0x25 0xff 0x1 0x0 0x0 0x74 0x33 0x48
0x8d 0x95 0x63 0x60 0x20 0x0 0x48 ]

the one in red color is what i printed using in_msg.LineAddress in L1
cache.sm

the one in green was in L2cache.sm but its address (not specified as line
address).

So am confused now whether it "2097216" is line address or not. Can some
one clarify this? Also 0x1,ox2d  refers to datablocks. Can someone help me
with this?

I tried to change the L1cache size and associativity.But still the same
address is printing.So this means its not line address ? Then why
in_msg.LineAddress ?

THanks in advance
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2015-10-29 Thread Cron Daemon

* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing 
passed.* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple
 passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level
 passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
 * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.
 * 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed.
 * 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
 * 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic 
passed.* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing 
passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple
 passed.* 
build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. 
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed.* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level
 passed.
*

Re: [gem5-dev] Adding new options to commandline & Using it

2015-10-29 Thread P Pinky

Thank you !!

Actually I am using Ruby, so I tried whatever u said with RubyCache.py and
CacheMemory.cc and its working.

When I debugged it,there was no issues ,but the trace file is not getting
generated. Do you know what could be the reason?



On Wed, Oct 28, 2015 at 4:25 PM, VAUMOURIN Grégory  wrote:

> If you want to add new parameters to the cache : (I supposed you don't use
> Ruby to simulate the caches)
>   --> In src/mem/cache/BaseCache.py, you can add a parameter to
> the BaseCache class like
> my_new_parameter = Param.int( DEFAULT_VALUE, "Description of my new
> parameter")
> For example , if your new parameter is a int
>
>   ---> In the src/mem/cache/BaseCache.cc , in the constructor of
> the BaseCache, you can get the value of your parameter with
> p->my_new_parameter and copy into some custom members variables .
>
> After that, you can this custom variable into all your python files . Hope
> this helped =)
>
> --
> Grégory Vaumourin
> Doctorant - Phd Student
> Laboratoire Adéquation Algorithme Architecture -- Algorithm and
> Architecture Codesign Laboratory
> Phone: +33 (1) 69080069
>
> 
> De : gem5-dev [gem5-dev-boun...@gem5.org] de la part de P Pinky [
> pinkieponkie2...@gmail.com]
> Envoyé : mercredi 28 octobre 2015 11:42
> À : gem5-us...@gem5.org; gem5-dev@gem5.org
> Objet : [gem5-dev] Adding new options to commandline & Using it
>
> Hi all
>
> I am working on a cache memory project.I am trying to add a new option to
> cache.I am able to add the option to options.py but am facing problem when
> i try to access the value in other files.So can someone help me with,
> which and all files i should modify so that i will be able to get the
> command line value in  .cc files ?
>
> Thanks in advance !
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Fwd: Line Address in SLICC

2015-10-29 Thread P Pinky

Hi all

 I have tried to print the line address in protocol files from the
in_msg.LineAddress.

 So by tracing the file, i got the following output.

355500: system.ruby.l1_cntrl0: MOESI_CMP_directory-L1cache.sm:364: *Line
address: 2097216*

407000: system.ruby.l2_cntrl0: MOESI_CMP_directory-L2cache.sm:799: *Address:
2097216*, Data Block: [ 0x1 0x2d 0xca 0x17 0x0 0x0 0x48 0x1 0x2d 0xab 0x1f
0x0 0x0 0x48 0x1 0x2d 0xac 0x1f 0x0 0x0 0x48 0x1 0x2d 0x95 0x3f 0x0 0x0
0x48 0x8d 0x3d 0x9e 0xff 0xff 0xff 0x48 0x81 0xe7 0x0 0x0 0xe0 0xff 0x48
0x89 0xf8 0x48 0xc1 0xe8 0x1e 0x48 0x25 0xff 0x1 0x0 0x0 0x74 0x33 0x48
0x8d 0x95 0x63 0x60 0x20 0x0 0x48 ]

the one in red color is what i printed using in_msg.LineAddress in L1
cache.sm

the one in green was in L2cache.sm but its address (not specified as line
address).

So am confused now whether it "2097216" is line address or not. Can some
one clarify this? Also 0x1,ox2d  refers to datablocks. Can someone help me
with this?

I tried to change the L1cache size and associativity.But still the same
address is printing.So this means its not line address ? Then why
in_msg.LineAddress ?

THanks in advance
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: kvm, arm: Fix compilation errors due to API c...

[gem5-dev] changeset in gem5: dev: Fix segfault in flash device

[gem5-dev] changeset in gem5: arm: Add secure flag to TableWalker request w...

[gem5-dev] changeset in gem5: dev: Fix draining for UFSHostDevice and Flash...

[gem5-dev] changeset in gem5: mem: Clarify cache MSHR handling on fill

Re: [gem5-dev] Fwd: Line Address in SLICC

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

Re: [gem5-dev] Adding new options to commandline & Using it

[gem5-dev] Fwd: Line Address in SLICC

9 matches

Site Navigation

Mail list logo

Footer information