Yes, the token protocol is definitely one of those protocols that prevents us
from tightly coupling the functional access support to the protocols. However,
I don't this issue will result in silently corrupted behavior. Instead, it
seems the result would be an error generated in the
Hi Korey,
We are in the process of moving all the Orion code out of Ruby and into McPAT.
When that is complete, I suspect that router.cfg file will be removed. Tushar,
please correct me if I'm wrong.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
On Fri, 6 May 2011, Korey Sewell wrote:
Nilay,
can you explain the impact of that bug in terms of simulation
performance?
Are benchmarks running slower because of this change? Will
regressions need
to be updated?
On Fri, May 6, 2011 at 8:13 PM, Beckmann, Brad
brad.beckm
Hi Nilay,
Yeah, pulling the State into the Machine makes sense to me. If I recall, my
previous patch made it necessary that each machine included a state_declaration
(previously the state enum). More tightly integrating the state to the machine
seems to be a natural progression on that path.
I can't reproduce these scons errors and they don't seem to happen from a clean
build. Can we blow away the current build directory on zizzer and re-run the
regression tester? I would do it myself, but I don't have access to zizzer.
Thanks,
Brad
-Original Message-
From:
I suspect that my recent review posts motivated this thread.
Overall, I think that the policy that you suggested Nate has been our informal
policy. The reason why I posted my somewhat trivial changes to reviewboard
this morning, is to give Tushar a chance to comment on my changes before I
Maybe I'm doing something stupid here, but on a clean checkout, the following
short patch encounters the subsequent compiler error:
diff --git a/src/mem/SConscript b/src/mem/SConscript
--- a/src/mem/SConscript
+++ b/src/mem/SConscript
@@ -57,6 +57,7 @@
TraceFlag('BusAddrRanges')
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of nathan binkert
Sent: Thursday, April 21, 2011 5:53 PM
To: M5 Developer List
Subject: Re: [m5-dev] what scons can do
Maybe so... I think there's a subconscious impression that it
Hi Korey,
I'm confused. The miss_latency calculated by the sequencer is the miss latency
of the particular request, not just L1 cache hits.
If you're seeing a bunch of minimum latency requests, I suspect something else
is wrong. For instance, is issued_time a cycle value or a tick value?
Sure, it is recording all miss latencies, including L1 cache hits. And yes,
those L1 hits will show up in the first bucket. However, I don't see how that
is a bug. If you don't want to include L1 hits in the histogram, then look how
the MOESI_hammer protocol tracks separate miss latencies
Brad, can you elaborate on implementing functional accesses for the
PioPort?
--
Nilay
On Wed, 13 Apr 2011, Beckmann, Brad wrote:
I just reviewed it. Please let me know if you have any questions.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev
I just reviewed it. Please let me know if you have any questions.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Tuesday, April 12, 2011 4:39 PM
To: Default
Subject: Re: [m5-dev] Review Request: Ruby: Add
Hi Nilay,
Yes, that is a good point. We really just need the interface to the permission
to be available from AbstractEntry. The variable itself doesn't really need to
be there. However, to make that change, you'll need to modify how CacheMemory
supports atomics.
Could you elaborate on
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Monday, April 11, 2011 2:38 PM
To: M5 Developer List
Subject: Re: [m5-dev] AccessPermission in AbstractEntry
Could you elaborate on your directory controller
I realize the documentation is still under way for gem5, but I was
wondering if there are any plans to document how users should be
interpreting the Ruby stats file? (Particularly, the miss latency
histograms)
Not all protocols support the miss latency histograms. Specifically, I
] On Behalf Of Korey
Sewell
Sent: Tuesday, April 05, 2011 7:14 AM
To: Beckmann, Brad
Subject: Re: [m5-dev] Running Ruby w/32 Cores
Hi again Brad,
I looked this over again and although my 32-bit patch fixes things, now that
I look at it again, I'm not convinced that I actually fixed the symptom
Thanks for pointing this out. The hammer protocol included a optimization for
uniprocessor DMA that was probably was just too aggressive to be worth the
complexity. The optimization broke when I fixed another DMA bug in the
protocol last week, but I failed realize that since I offend don't
Hi Nilay,
Thanks for posting a new patch. I will review it as soon as I can...hopefully
tonight.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Wednesday, March 30, 2011 4:32 PM
To: Default
Subject: Re:
. In the interim, I'll try to locate
the exact address that's breaking trace 2 and then hopefully repost that.
Thanks!
-Korey
On Tue, Mar 29, 2011 at 12:02 PM, Beckmann, Brad
brad.beckm...@amd.com wrote:
Hi Korey,
I believe both of these issues should be easy to solve once we have
Hi Korey,
I believe both of these issues should be easy to solve once we have a protocol
trace leading up to the error. If you could create such a trace and send it to
the list, that would be great. Just zero in on the offending address.
Thanks,
Brad
-Original Message-
From:
wanted to make sure it was expected and not an
actual bug.
On Sat, Mar 26, 2011 at 1:46 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Hi Steve,
Oops. It was such a small change in configuration, I didn't think
about rerunning the regression tester, but now thinking about it, yes
Hi Korey,
A few comments:
- The difference in time is because the sequencer prints out the RubyCycle
count for the issue time while the tick count is the global curTick value. Now
that Ruby uses DPRINTFs, I think it makes sense to move all those ruby print
outs to ticks. I actually have
I sent Tushar an email this morning regarding this, hoping to catch him before
he went to bed (he's currently in Singapore). Unfortunately he hasn't
responded.
Hopefully he'll get to this when he wakes up in a few hours. If he doesn't,
I'll take a look at it tomorrow morning. I don't have
Hi Nilay,
Why do you want to change the name? Both names seem equivalent to me.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Nilay Vaish
Sent: Friday, March 18, 2011 9:55 PM
To: Nilay Vaish; Default
Subject: [m5-dev]
Nevermind, I understand the reason now. This looks good to me.
Thanks,
Brad
-Original Message-
From: Beckmann, Brad
Sent: Saturday, March 19, 2011 1:50 PM
To: 'M5 Developer List'
Subject: RE: [m5-dev] Review Request: Ruby: Convert AccessModeType to
RubyAccessMode
Hi Nilay
Korey, if you're deadlock is with running the MOESI_CMP_directory protocol, I'm
not surprised. DMA support is pretty much broken in that protocol. I have
that fixed and I also fixed the underlining DMA problem. I'll be pushing the
fixes momentarily.
Korey and Malek, please pull these
List
Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
On Sat, March 19, 2011 6:01 pm, Beckmann, Brad wrote:
Korey, if you're deadlock is with running the MOESI_CMP_directory
protocol, I'm not surprised. DMA support is pretty much broken in
that
protocol. I have that fixed and I
(bad DMA
access)
in about 20 mins.
I able to get to that same problem point in the M5-atomic mode in
about
10
mins so as to see what to compare against and what values are being
set/unset incorrectly.
On Tue, Mar 15, 2011 at 6:22 PM, Beckmann, Brad
brad.beckm
How is that you are able to run the memtester in FS Mode?
I see the ruby_mem_tester.py in /configs/example/ but it seems that it is
only configured for SE Mode as far as Ruby is concerned?
I don't run it in FS mode. Since the DMA bug manifests only after hours of
execution, I wanted to first
if that helps or not...
On Tue, Mar 15, 2011 at 3:03 PM, Beckmann, Brad
brad.beckm...@amd.comwrote:
How is that you are able to run the memtester in FS Mode?
I see the ruby_mem_tester.py in /configs/example/ but it seems that
it is only configured for SE Mode as far as Ruby
,
but commenting out those lines of code allowed it to work.
Maybe Korey could confirm?
Malek
On Wed, Mar 9, 2011 at 8:24 PM, Beckmann, Brad
brad.beckm...@amd.com wrote:
I still have not been able to reproduce the problem, but I haven't tried
in a
few weeks. So does this happen when
Developer List
Cc: Beckmann, Brad
Subject: Re: [m5-dev] Ruby FS - DMA Controller problem?
Hi Korey/Brad,
I commented out the following lines:
In RubyPort.hh
unsigned deviceBlockSize() const;
In RubyPort.cc
unsigned
RubyPort::M5Port::deviceBlockSize() const {
return
You probably already realize this, but I want to point out that the topology
needs pointers to all the controllers. I don't have the code in front of me,
but if I recall correctly, topology is then a member of the network. If you
move the controllers underneath RubySystem and if RubySystem
In the short run, I think the easiest way to break the cycle is to have the
network take the RubySystem object as a parameter instead of the other
way around, then add a registerNetwork() callback on RubySystem to let the
network give the system its pointer.
...
Finally, it occurs to me
Gabe, thanks for putting this patch out for review. I had forgotten that this
directory still exists. I moved the code that I'm most familiar with out of
this directory last year, but I didn't touch the Racey tester code because I
wasn't sure what to do with it. I believe that code was
I still have not been able to reproduce the problem, but I haven't tried in a
few weeks. So does this happen when booting up the system, independent of what
benchmark you are running? If so, could you send me your command line? I'm
sure the disk image and kernel binaries between us are
I believe the L1DcacheMemory is created right after system because inside each
protocol file the first thing attached to the system is the l1 controllers.
That way the controllers get a more descriptive name than what they are as
related to the topology.
I'm still a little confused by the
: Tuesday, March 08, 2011 3:22 AM
To: Beckmann, Brad
Cc: m5-dev@m5sim.org
Subject: RE: Functional Interface in Ruby
It seems that this will work out. We can make AbstractController call a static
function of RubyPort class that will add the calling object to some list which
will be accessed
addresses and just direct our responses
to m5-dev.
Brad
From: Steve Reinhardt [mailto:ste...@gmail.com]
Sent: Tuesday, March 08, 2011 7:18 AM
To: M5 Developer List
Cc: Nilay Vaish; Beckmann, Brad
Subject: Re: [m5-dev] Functional Interface in Ruby
Forgot to mention that this is how we handle registering
support into the Sequencer? It seems that the RubyPort would
be a more natural location.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Friday, March 04, 2011 9:49 AM
To: Beckmann, Brad
Cc: m5-dev@m5sim.org
Subject: Functional Interface in Ruby
I have
Hi Nilay,
I would suggest a few different tests. The first one would be to run a simple
binary under Alpha SE mode using Ruby. You should first observe a bunch of
functional accesses that initialize memory and then (if I recall correctly)
dynamic accesses will load the TLB. After passing
I forgot that the memtester includes functional accesses. That is a good
suggestion, especially when it comes to testing the situations where Ruby can't
satisfy the functional access due to contention with timing accesses.
The memtester does run with Ruby (it actually runs every night in the
Hi Nilay,
In the future, feel free to directly check in these sort of minor bug fixes.
Thanks,
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Tuesday, March 01, 2011 1:32 PM
To: Nilay Vaish; Default
, then we
should
already have some knowledge about what is expected from functional
accesses.
Nilay
On Fri, 25 Feb 2011, Beckmann, Brad wrote:
Yes, that is correct. The RubyPort::M5Port::recvFunctional()
function is where we need to add the new support.
Brad
-Original
Yes, that is correct. The RubyPort::M5Port::recvFunctional() function is where
we need to add the new support.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Friday, February 25, 2011 12:20 PM
To:
the
second condition above. Which one to provide depends upon what M5 CPU models
wants to do to guarantee consistency.
Please let me know if you disagree or if I am missing something.
Thanks
Arka
On 02/24/2011 05:22 PM, Beckmann, Brad wrote:
So I think Steve and I are in agreement here. We
to the processor)
cache
controller (i.e. *-L1Cache.sm ) need to be made aware of the store
buffer
(unless it is hacked to bypass SLICC) .
Thanks
Arka
--
Nilay
On 02/23/2011 11:29 PM, Beckmann, Brad wrote:
Sorry, I should have been more clear. It fundamentally comes down
to how
: Beckmann, Brad
Subject: Re: [m5-dev] Store Buffer
On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
So we probably don't want to pass speculative store data to the RubyPort, but
what about speculative load and store requests? I suspect we do
List
Subject: Re: [m5-dev] Store Buffer
On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish
ni...@cs.wisc.edumailto:ni...@cs.wisc.edu wrote:
On Thu, 24 Feb 2011, Beckmann, Brad wrote:
Steve, I think we are in agreement here and we may just be disagreeing with the
definition of speculative. From the Ruby
Since I haven't heard any objections, I'm going to go ahead and remove it.
Brad
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Beckmann, Brad
Sent: Tuesday, February 22, 2011 2:37 PM
To: Default (m5-dev@m5sim.org)
Subject: [m5-dev] MOESI_CMP_directory
That's a good question. Before we get rid of it, we should decide what is the
interface between Ruby and the o3 LSQ. I don't know how the current o3 LSQ
works, but I image that we need to pass probe requests through the RubyPort to
make it work correctly.
Does anyone with knowledge of the o3
Hi All,
I just posted a patch that removes all of the protocol files that are not
supported in gem5. However, I'm not sure if anyone has used/is using the file
MOESI_CMP_directory-perfectDir.sm. I've never used it before and I have no
idea if it even works or what exactly it is supposed to
Hi Nilay,
I'm not quite sure what you mean by appended to while you drain, but I think
you are asking whether the input ports will receive messages that are scheduled
for the same cycle as the current cycle. Is that right? If so, then you are
correct, that should not happen.
As long as the
Hi Nilay,
Thanks for the heads up. I looked into it and there is a simple fix.
I'm pushing the fix momentarily.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Thursday, February 10, 2011 5:40 AM
To:
think the panic messaged appeared now and not before because I let the
simulation terminate itself when running overnight as opposed to me killing it
once I saw the dma_expiry message on the M5 Terminal).
Malek
On Wed, Feb 9, 2011 at 7:00 PM, Beckmann, Brad
brad.beckm...@amd.com wrote:
Hi
PM, Beckmann, Brad
brad.beckm...@amd.com wrote:
H Malek,
Hmm...I have never seen that type of error before. As you mentioned, I
don't think any of my recent patches changed how DMA is executed for
ALPHA_FS.
How long does it take for you to encounter the error? It would be great
Hi Malek,
Yes, thanks for letting us know. I'm pretty sure I know what the problem is.
Previously, if a SC operation failed, the RubyPort would convert the request
packet to a response packet, bypassed writing the functional view of memory,
and pass it back up to the CPU. In my most recent
Hi Gabe,
Since you successfully updated the tests I can't run (ARM_FS), I can take of
the remaining errors (i.e. ruby protocol tests). I have a few minor fixes I
want to check in that I need to run the regression tester against anyways.
Brad
-Original Message-
From:
Ah, yes I did. This actually reminds me that I need to fix how dma devices are
connected within Ruby for x86_FS. I'll push a batch that fixes these issues
soon.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
(?) grow to such an high number..
On Mon, Feb 7, 2011 at 1:27 PM, Beckmann, Brad
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
Yep, if I increase the deadlock threshold to 5 million cycles, the deadlock
warning is not encountered. However, I don't think that we should increase the
default
Ugh...sorry about that. I had to update most of the stats because one of
Joel's patches added several new stats. The problem was that I don't have the
Linux kernel to run the ARM FS regression tests. Therefore those tests didn't
run correctly and thus I incorrectly updated those regression
I agree Nilay. Do you want to push that patch, or would you like me to take
care of it? Ideally Tushar should do it, but since he's in Singapore it is
probably best that you or I do it.
Thanks for pointing that out.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
] changeset in m5: ruby: add stdio header in SRAM.hh
I can do it. I have replaced all of the printf()s with fatal()s.
Is this correct, or should I use panic() instead?
--
Nilay
On Mon, 7 Feb 2011, Beckmann, Brad wrote:
I agree Nilay. Do you want to push that patch, or would you like me
, Beckmann, Brad wrote:
FYI...If my local regression tests are correct. This patch does not
fix all the problems with the MESI_CMP_directory protocol. One of the
patches I just checked in fixes a subtle bug in the ruby_mem_test.
Fixing this bug, exposes more deadlock problems
the tests I pointed out
and verify the changes are what they expected.
Once one of the Ruby folks (Brad maybe?) lets me know everything is on
track and nobody has asked otherwise, I'll go ahead and commit this.
Gabe
On 02/07/11 09:15, Beckmann, Brad wrote:
Ugh...sorry about that. I had
Do people mind if I change the source and target color from Yellow to Green? I
typically use a lighter background and the yellow text is very difficult to
read. I figure green is more conducive for both lighter and darker backgrounds
and it keeps the Green Bay Packer theme. :)
Brad
FYI...If my local regression tests are correct. This patch does not fix all
the problems with the MESI_CMP_directory protocol. One of the patches I just
checked in fixes a subtle bug in the ruby_mem_test. Fixing this bug, exposes
more deadlock problems in the MESI_CMP_directory protocol.
To
Hi Nilay,
Yes, you could make such an optimization, but you want to be careful not to
introduce starvation. You want to make sure that newly arriving messages are
not always prioritized over previously stalled messages.
Could you avoid looping through all message buffers by creating a list of
Thanks Arka for that response. You summed it up well.
There are just a couple additional things I want to point out:
1. One thing that makes this mechanism work is that one must rank each
input port. In other words, the programmer must understand and communicate
the dependencies
patches.
Gabe
Beckmann, Brad wrote:
Hi Nilay,
Yes, I am aware of this problem and one of the patches
(http://reviews.m5sim.org/r/381/) I'm planning to check in does fix this.
Unfortunately, those patches are being hung up because I need to do some
more work on another one of them and right
Hi Nilay,
Yes, I am aware of this problem and one of the patches
(http://reviews.m5sim.org/r/381/) I'm planning to check in does fix this.
Unfortunately, those patches are being hung up because I need to do some more
work on another one of them and right now I don't have any time to do so.
is not a multiple
of the number of routers. If you know of a better way to handle this, please
let me know.
Brad
-Original Message-
From: Nilay [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, January 18, 2011 9:28 PM
To: Beckmann, Brad
Cc: m5-dev@m5sim.org
Subject: RE:
Brad,
I got
destinations are encoded and/or the interface between
MessageBuffer dequeues and the PerfectSwitch wakeup, will lead to a b
etter solution.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, January 18, 2011 6:59 AM
To: Beckmann, Brad
Cc: m5-dev@m5sim.org
Nilay,
Are you trying to replace CacheMsg with RubyRequest? I agree that we can
probably get rid of one of them. If I recall, right now RubyRequest is defined
in libruby.hh. Is the Ruby library interface still important to you all at
Wisconsin? If not, I would like to get rid of the
Hi Nilay,
I understand your confusion. This is an example of where the wiki needs to be
updated. I believe the wiki only mentions the encumbered tar ball and doesn't
mention the encumbered hg repo on repo.m5sim.org. As far as the anagram test
program goes, I remember Lisa and I encountered
.
Instead of replacing our existing benchmarks which are useful as
actual benchmarks and are good to keep working, we could build up this
second set of tests in parallel.
Gabe
Quoting Beckmann, Brad brad.beckm...@amd.com:
Hi Nilay,
I understand your confusion. This is an example of where
Hi Nilay,
There is often a tradeoff between doing operations in actions versus the input
port. Overall, I agree with you that we should concentrate on doing most/all
operations in actions, not the input ports. The input port logic is often a
confusing nested conditional mess and performing
change, right?
If so, the RequestorMachine lines are related to the rest of the patch.
Brad
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Thursday, January 13, 2011 8:57 AM
To: Nilay Vaish; Default; Beckmann, Brad
Subject: Re: Review Request: Updating MOESI CMP Directory protocol as per
, but it's probably the
most appropriate place. I'm not familiar with the checkpoint tester. How
does it work (link to the wiki would be fine), and what were the differences?
Gabe
Beckmann, Brad wrote:
Hi All,
While using the checkpoint tester script, I noticed that at least
Are you sure you would call the above piece of code as __implicit__ setting
of cache and tbe entry variables? In this case, the local variable has been
__explicitly__ passed in the call to the trigger function.
To me 'X is implicit' means that the programmer does not need to write 'X'
in
Hi All,
While using the checkpoint tester script, I noticed that at least X86_FS with
the atomic + classic memory system encounters differences in the checkpoint
state. The good news is that none of the patches I have out for review add any
more checkpoint differences, but we still should
, cache_entry, and tbe_entry variables
are dealt with consistently and it avoids adding the separate calls to
set_cache_entry() and set_tbe () in the inports.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Friday, January 07, 2011 11:40 AM
To: Beckmann, Brad
Cc
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the trigger function. That way
the address,
Hi Nilay,
Overall, I believe we are in more agreement with each other than maybe you
think. I'm glad you included pseudo code in your latest email. That is a
great idea. I think part of our problem is we are comprehending our textual
descriptions in different ways.
Below are my responses:
Oops...I forgot to include the -o option when updating it. I just uploaded a
new patch...try it again.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay
Sent: Monday, January 10, 2011 9:01 AM
To: M5 Developer List
Subject: Re:
Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Thursday, January 06, 2011 6:32 AM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: Changing how CacheMemory interfaces with SLICC
Can you give me an example of a protocol where getCacheEntry() behaves in a
different
of assert, or is it something more fundamental?
Thanks,
Brad
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, January 04, 2011 7:24 PM
To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert
Cc: Nilay Vaish; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: get rid of ruby's
AM
To: M5 Developer List
Cc: Beckmann, Brad
Subject: Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Looks like we should just remove the first, second, and third columns that are
spit out since they're covered almost exactly by the implicit columns added by
DPRINTF. Right
(or some
other file in src/base).
Thanks,
Brad
From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert
Sent: Wednesday, January 05, 2011 10:40 AM
To: Beckmann, Brad
Cc: Nilay Vaish; Steve Reinhardt; Ali Saidi; Gabe Black; Default
Subject: Re: Review Request: ruby: get rid
Sent: Wednesday, January 05, 2011 12:30 PM
To: Beckmann, Brad
Cc: M5 Developer List
Subject: Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Is it possible to fix the width of the information prepended by DPRINTF? I
would be great if we could maintain the current fixed width
; Default; Beckmann, Brad
Subject: Re: Review Request: Changing how CacheMemory interfaces with SLICC
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
On January 3rd, 2011, 3:31 p.m., Brad Beckmann wrote:
Hi Nilay,
First, I must say
Hi Nilay,
My responses are below:
The main thing I would like to see improved is not having to differentiate
between “entry†and “entry_ptr†in the .sm files. Am I correct
that the only functions in the .sm files that are passed an
“entry_ptr†are “is_valid_ptrâ€,
...@cs.wisc.edu]
Sent: Tuesday, January 04, 2011 12:03 PM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: Changing how CacheMemory interfaces with SLICC
Brad
Is there a reason why each action name follows the pattern combination of
several letters_action performed by the action? The letters used
] On Behalf Of
Nilay Vaish
Sent: Tuesday, December 21, 2010 6:24 PM
To: M5 Developer List
Subject: Re: [m5-dev] Deadlock while running ruby_random_test.py
Brad, which protocols work correctly with ruby random tester?
On Tue, 21 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
If I'm correctly reproducing
:
Brad, which protocols work correctly with ruby random tester?
On Tue, 21 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
If I'm correctly reproducing your problem, I believe I know what the
issue is. However, before I try to fix it, I want to propose simply
getting rid
Hi Nilay,
If I'm correctly reproducing your problem, I believe I know what the issue is.
However, before I try to fix it, I want to propose simply getting rid of the
MESI_CMP_directory. The more and more I look at that protocol, the more
problems I see. There are several design and logic
Hi Nilay,
I apologize for the delay, but I was mostly travelling / in meetings last week
and I didn't have a chance to review your patches and emails until this morning.
Overall, your patches are definitely solid steps in the right direction and
your profiling data sounds very promising. If
Hi Ali,
I just synced with this changeset 7733, as well as changeset 7730, and I now
notice that the modifications to physical.cc break all previous checkpoints.
Can we put the lal_addr and lal_cid serialization and unserialization in a
conditional that tests for the ARM ISA? I welcome other
Hi Ali,
This is changset 7730 which also breaks all previous checkpoints because it
requires phsymem to serialize and unserialize the variable _size.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Ali Saidi
Sent: Monday,
. But can the
machine itself be accessed? I need one of the variables in the
StateMachine object to know whether or not TBETable exists in this
machine.
Nilay
On Wed, 8 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
I think we can avoid handling pointers in the getState and setState
1 - 100 of 219 matches
Mail list logo
