From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Beckmann, Brad
Sent: Wednesday, August 11, 2010 10:15 AM
To: M5 Developer List
Subject: Re: [m5-dev] Ruby Patches
I've addressed Nate's comments and I have a set of patch updates to post for
review. I noti
: Gabe Black [mailto:gabe.bl...@gmail.com] On Behalf Of Gabe Black
Sent: Sunday, August 15, 2010 2:16 PM
To: M5 Developer List
Cc: Beckmann, Brad; Nathan Binkert
Subject: Re: [m5-dev] Review Request: ruby: Resurrected Ruby's deterministic
tests
How about putting the stuff currently in memtest
Yep...that is the issue.
BTW, I did use "hg mv" for this patch.
Brad
-Original Message-
From: Nathan Binkert [mailto:n...@binkert.org]
Sent: Wednesday, August 11, 2010 7:54 PM
To: Default; Beckmann, Brad; Nathan Binkert
Subject: Re: Review Request: ruby: moved python prot
Hi All,
Yesterday a few of us from AMD and Wisconsin met and discussed the next tasks
for GEM5. Specifically there are a couple (possibly more?) new graduate
students at Wisconsin that are starting to ramp up in the simulator. While we
spent some time discussing short-term projects for the ne
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Steve Reinhardt
> Sent: Thursday, August 19, 2010 3:03 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] TimingSimpleCPU, x86: sendSplitData packet sender
> states
>
> (That said, look
Thanks for heads up Gabe. Yep I missed that.
It turns out there a few things currently broken with the ruby config scripts.
I'll be pushing some changes momentarily.
Brad
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Gabe Black
Thanks for the heads up. There actually are a couple silly config
initialization errors that crept in while I was creating my final set patches a
couple weeks ago.
I'll be pushing two simple fixes momentarily.
Brad
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev
ay or another, this means fast-forwarding Ruby.
This is the area around which I'd like to invite discussion.
- Is quiescing Ruby the right way to implement functional access?
- What is the best way to go about fast-forwarding Ruby events?
Regards,
Dan
On Wed, Aug 18, 2010 at 1:18 PM, Beckmann,
Nilay, I apologize for the confusion here. It seems that Nate and I are
suggesting you go in two different directions in terms of the operator<<. I
personally wanted to get away from the operator<< overloading, so that Ruby
objects looked more similar to most M5 objects. Especially because mo
I see. When I suggested to Nilay to implement the print functions and remove
the operator<< functions, I was using M5's pkt print statements as loose
inspiration. I should have been more thorough in my investigation because I
know realize that there are a few M5 base objects that do the operat
October 26, 2010 9:48 AM
To: M5 Developer List
Cc: Nilay Vaish; Beckmann, Brad; Steve Reinhardt
Subject: Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support
> I would prefer not to have the .sm DPRINTF calls look exactly like the c++
> calls. In particular, it seems
Hi Nate,
I noticed that these changes introduced a couple bugs. I believe the
Packet constructors should set the VALID_DST flag and the logic of the
allocate function is incorrect. I believe we should make the following
changes to packet.hh. Would you like me to go ahead and update the
m5-dev r
error:
build/ALPHA_FS/mem/packet.hh:705: void Packet::allocate(): Assertion
`flags.none(STATIC_DATA|DYNAMIC_DATA)' failed.
Brad
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nathan
> binkert
> Sent: Wednesday, November 12, 2008 4:42 P
0071525e in simulate (num_cycles=9223372036854775807) at
build/ALPHA_FS/sim/simulate.cc:73
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nathan
> binkert
> Sent: Wednesday, November 12, 2008 4:54 PM
> To: Beckmann, Brad
> Cc: M5 Developer Lis
I'm glad I could help. :)
Brad
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of nathan binkert
> Sent: Thursday, November 13, 2008 10:12 AM
> To: M5 Developer List
> Subject: Re: [m5-dev] changeset in m5: style: clean up the Packet
stuff
>
> I'm r
Also, could someone explain how the idleCycle count compares to the
kernel stat "mode_ticks_idle"? Obviously, one is in cycles and the
other one is in ticks, but they seem to be capturing two different
behaviors.
Thanks,
Brad
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5s
Tushar and I see that you can run MemTest through ruby using the regression
tester interface, but we were hoping to run MemTest directly from the command
line. I see that configs/example/memtest.py allow you to configure the MemTest
cpu object from the command line, but it only seems to work wi
Hi All,
Tushar and I have noticed a few issues with GEM5 and we were wondering
if anyone had plans to fix them. If not, we'll go ahead and check in
fixes to the global repository. I just want to make sure we're not
stepping on anyone's toes.
- Fix SLICC so that protocol generated files are crea
v-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Derek Hower
Sent: Thursday, July 30, 2009 10:34 PM
To: M5 Developer List
Subject: [m5-dev] Fwd: GEM5 Issues
-- Forwarded message --
From: Derek Hower
To: M5 Developer List
Date: Thu, 30 Jul 2009 23:24:08 -0500
Sub
Thanks Derek.
I think we should be consistent with how GEMS separates sequencer requests from
network requests and thus we should split them into two different types. The
DMA network requests should be specified in the protocol message file since
they interact with that particular protocol's s
I was hoping that there was a better way to solve this...I'm glad you found it!
However I'm confused why you don't think "MachineType::L1Cache" is legal SLICC
code? SLICC can reference a particular machine type by simply removing a
colon, "MachineType:L1Cache". This will translate to "Machine
I agree. Whatever we develop long-term should allow multiple levels of
arbitrary hierarchy. In the end, it would be ideal if M5's front-end
configuration removed the .slicc files and directly glued the state machines
together. In particular, it would be great if there was a "domain" super cla
As someone who is very familiar with how SLICC currently generates code,
I'm little concerned about changing the core of GEMS but maybe I just
need to understand what you are proposing in more detail. Sometimes
SLICC generation bugs can be hard bugs to find and I would be leery of
potentially brea
Great. Being able to diff the two sets a files will certainly ease debug.
I hope you don't mind me asking, but why does the fragility of generated code
matter? One should never modify generated code and only rarely look at it.
I'm interested to hear your ideas about how moving SLICC to python
I think the folks at Wisconsin can best speak about the MIF code generator. It
was used to formally verify the correctness of protocols. I'm not sure if any
current projects plan to use that support.
The CHECK_INVALID_RESOURCE_STALLS was something I created many years ago to
ensure that all m
The parsing errors are much better. Thanks!
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Tuesday, August 04, 2009 9:38 AM
To: M5 Developer List
Subject: Re: [m5-dev] Scons cleaning
> Yes, especially with the
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I wanted
to discuss the protocol directory issue in more detail. I'm completely fine
with recompiling all files when changing protocols. I would just like the
ability to have two different M5 binaries, using different proto
Hi All,
Attached is a patch I would like to check in that allows Ruby to support
a very large memory address space and high core count. Currently ruby
uses a flat array to store the memory state of the system. This works
well when the simulated system is roughly 4 GB or less, but is not
pract
Thanks everyone for the comments. I won't be able to check in my patch(es)
today, but will work on it more next week and try to commit them in a week or
two.
First to answer Nate:
- In hindsight, one may see the items in this patch as unrelated, but I
initially created this patch with the sole
Darn...I was hoping -X would work. So by manually creating multiple patches,
you mean qnew a few almost empty patches and then cut-and-paste the one patch
into those new patch files, right?
It may be just me, but I have a hard time determining in real time when a
modification requires a new pa
Hi All,
I know a few people on this use the libm5_*.so and I was wondering if
you could describe the environment you have when building the .so. In
particular, is your $PYTHONPATH, $PYTHONHOME, and $LD_LIBRARY_PATH set,
and if so do they all point to the same place? Are any other
environment
Actually I believe the problem is with the installation of python I'm pointing
to. When I point to any other installations of libpython.so, even different
installations of the same 2.5.1 version, it seems to work. I'm not sure what
is faulty with the particular installation, but I should have
Hi All,
I'm having trouble logging into m5sim.org. In particular, as soon as I
log in, I'm automatically logged out. I don't believe my IP is
restricted because Lisa can successfully log in from the same IP. Also
Lisa check and it doesn't appear my login is on the restricted user
list. Anyo
Hi All,
I'm encountering an "event scheduled in the past" assertion error when
loading a checkpoint using ALPHA_FS. I believe the specific problem is
the MC146818 model schedules its RTC clock tick event for cycle
1, but its unserialized function doesn't reschedule it for
the futur
Hi Nilay,
I don't think we want to replace the implicit Address parameter inside the
state machines with the CacheEntry parameter, but we might want to supplement
the state machine functions to include both. I don't think we can replace the
Address parameter because certain transitions within
a local variable.
>
> Nilay
>
> On Mon, 29 Nov 2010, Beckmann, Brad wrote:
>
>> Hi Nilay,
>>
>> I don't think we want to replace the implicit Address parameter
>> inside the state machines with the CacheEntry parameter, but we might
>> want to su
isualize what change is going to have
what effect.
One question, should we use pointers to pass the cache entry around, or should
we make use of reference variables? Currently lookup functions return
references to cache entries.
Nilay
On Tue, 7 Dec 2010, Beckmann, Brad wrote:
> Hi Nila
Done.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, December 07, 2010 4:43 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: Review Request: NDEBUG for Ruby Assert statement
Brad,
Since Steve and you have reviewed the patch, I guess we can commit it
y itself. We can move that variable to
be part of the AbstractCacheEntry or we can combine it with the permission
variable which is already there in the AbstractCacheEntry class. I think lock
is only used in the implementation of LL/SC instructions.
Nilay
On Wed, 8 Dec 2010, Beckmann, Brad w
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, N
functions? I know the name of the machine can be accessed. 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 wro
; lot of times where I've wished we had that since I accidentally broke
> something :-). I remember hearing that would be hard to do for some
> reason, though.
>
> Gabe
>
> Quoting "Beckmann, Brad" :
>
> > Hi Ali,
> >
> > I just synced with this
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 yo
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 iss
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&#x
:
> 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
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â€, “getCa
to:ni...@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 _? The letters used are not
abbreviations of the action performed. Can w
preference not to use macros that overwrite the
meaning 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; Beckm
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
DPRIN
c/base/debug.hh (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 Req
an binkert
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 th
; 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 this is an
Brad
-Original 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(
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
, 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:
>
> 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'
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 trac
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 the
ray would be good. We don't use it like we should, 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:
gt;
>
> On Thu, 13 Jan 2011 11:11:37 -0600, "Beckmann, Brad"
> wrote:
> > Well I just realized that I don't have permissions to add new bug
> > reports to Flyspray. My Flyspray user id is beckmabd if anyone would
>
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 ot
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 t
freely distributable
> regressions/inputs, and augment them with shorter, targeted tests that
> exercise particular mechanisms, circumstances, instructions, etc.
> Instead of replacing our existing benchmarks which are useful as
> actual benchmarks and are good to keep working, we could build up th
t
that redesigning how 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
&
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 libruby
s 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
> Su
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. A
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 betwe
n't expect it to really depend on the intervening
> 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.
> Unfortuna
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
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
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 ou
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 [mailto:
Monday, February 07, 2011 9:35 AM
> To: M5 Developer List
> Subject: Re: [m5-dev] 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
>
fatal() and
> include
> the header file base/misc.hh.
>
> --
> Nilay
>
> On Mon, 7 Feb 2011, 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
bout 5. The patch I
> made is attached in case anybody wants to go through it. I'd suggest that at
> least a somebody that's familiar with Ruby go through the tests I pointed out
> and verify the changes are what they expected.
>
> Once one of the Ruby folks (Brad maybe?) lets
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: m5-dev-boun..
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
> S
e should consider having X many outstanding requests per CPU as a more
realistic measure that can stress the system but not make the noResponseCycles
stat (?) grow to such an high number..
On Mon, Feb 7, 2011 at 1:27 PM, Beckmann, Brad
mailto:brad.beckm...@amd.com>> wrote:
Yep, if I increas
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 p
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: m5-
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
> wrote:
> > Hi Malek,
> >
> > Yes, thanks for
gt; ./build/ALPHA_FS_MOESI_CMP_directory/m5.opt -
> >> ./configs/example/ruby_fs.py -n 4 --topology Crossbar
> >>
> >> The error comes at about 15 minutes in to boot the kernel. Note that
> >> it takes a while for the io to be scheduled.
> >>
> >> io
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
I apologize for the multiple merges, but I assure you it was not because I was
negligent. Instead, it was cause by some technical issues beyond my control.
The merges don't conflict with the same files, so I think the impact should be
minimal.
Brad
> -Original Message-
> From: m5-dev
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 do
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
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
ls
> matters here? In-order cores (CPU models) can also use (retired) store
> buffer. I believe its is an issue of memory consistency model being
> simulated rather than tied to a particular CPU model
> (in-oder/out-of-order). Please correct me if I am totally missing
> something her
it. In gem5, store buffers are not included
> in the protocol files. In fact, current libruby code does nothing
> useful
> at all.
>
> > I do think though, that the highest level (closest to the processor)
> cache
> > controller (i.e. *-L1Cache.sm ) need to be made aware o
veloper List
Cc: Beckmann, Brad
Subject: Re: [m5-dev] Store Buffer
On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad
mailto: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 suspec
List
Subject: Re: [m5-dev] Store Buffer
On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish
mailto: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 perspect
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: m5-dev
to allow 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
hat mean the
> underlying processor supports functional accesses? If yes, 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.
101 - 200 of 249 matches
Mail list logo
