Brandon Potter got review request #3113!

Information
Submitter:	Brandon Potter
Repository:	gem5
Branch:	default
Bugs:
Depends On:	~~2965~~
Reviewers
Groups:	Default
People:

Description

Changeset 11093:3c32e2cb1c87
---------------------------
ruby: allows multiple instances of ruby to be invoked

This patch removes the restriction that there can only be a single ruby
system object in a given simulation. With the configuration supplied, it is
possible to run an instance of ruby with any of the supplied topologies.

The problem centers around the use of globals and static class members in the
ruby source. Conceptually, this prohibits multi-instance simulations
since the ruby systems end up sharing values which should be distinct. (The
earliest manifestation of this problem occurs when important runtime
components use shared variables for MachineType sanity checks which will
trigger failures.)

The idea behind the patch is to move as many as the statics/globals as
necessary into the ruby system object. The ruby system object acts as the
single point of reference for the child objects which needed the
globals/statics. With multi-instance runs, each ruby system object will
contain distinct values for the previous globals/statics. Unfortunately, this
requires passing the ruby system pointer throughout the object hierarchy and
may incur some minor performance overhead due to extra indirect references
through the ruby system object.

Testing Done

gem5/util/regress (to check builds) and custom tests (which use the new configuration)

Issue Summary

Description	From	Last Updated	Status
In general, it doesn't make sense for transient state, like a SenderState, to carry a pointer to a persistent simulation ...	Joel Hestness	Oct. 29, 2015, 1:23 p.m.	Resolved
This patch uses getRubySystem() functions more common than it should. Based on the number of uses like this, Nilay is ...	Joel Hestness	Oct. 22, 2015, 5:59 p.m.	Resolved
Per above, a SenderState shouldn't have a RubySystem pointer.	Joel Hestness	Oct. 29, 2015, 1:20 p.m.	Resolved
These constructor tags on MessageBuffer declarations are unnecessary, since the constructor is called from SWIG code. These should all be ...	Joel Hestness	Oct. 16, 2015, 1 p.m.	Resolved
I don't recall where we ended on the mapping function discussion. However, mapping functions will be specific to each RubySystem ...	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
This doesn't make sense. Cache entries should not need a pointer to the RubySystem. Certainly the caches have RubySystem pointers, ...	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
Almost all of these functions are going to need to be RubySystem instance specific...	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
Not sure what this means...? Why is this declaration necessary?	Joel Hestness	Oct. 16, 2015, 1:45 p.m.	Resolved
Transient state shouldn't have pointers to persistent objects.	Joel Hestness	Oct. 29, 2015, 1:14 p.m.	Resolved
Transient state shouldn't have pointers to persistent objects.	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
These are RubySystem instance specific functions, since calculating the return values depends on a RubySystem's cache block size. These functions ...	Joel Hestness	Oct. 29, 2015, 1:14 p.m.	Resolved
Is this correct? Nothing about the files is changed by this patch...	Joel Hestness	Oct. 16, 2015, 1:11 p.m.	Resolved
See prior comment.	Joel Hestness	Oct. 29, 2015, 1:15 p.m.	Resolved
Pass around the cache line size? Sure, it makes sense to do so, since it is a property of the ...	Joel Hestness	Oct. 29, 2015, 1:15 p.m.	Resolved
I don't even know why we have these functions around: DataBlk has functions to do reads/writes, and these largely replicate ...	Joel Hestness	Oct. 22, 2015, 3:29 p.m.	Resolved
Needs to be set in a different way with more appropriate abstraction (i.e. m_numa_high_bit should be private in RubySystem, and ...	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
If there were appropriate inheritance unifying PerfectCacheMemory with the CacheMemory and DirectoryMemory, the assumptions would be the same about addresses ...	Joel Hestness	Oct. 29, 2015, 4:23 p.m.	Resolved
ENTRY should not require a RubySystem pointer.	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
Is m_num_directories not the same as something like MachineType_base_count(Directory)? If possible, I'd recommend trying to eliminate redundant variables here.	Joel Hestness	Nov. 2, 2015, 9:34 a.m.	Resolved
Make these private, and add accessor functions. These should not be directly accessible from other components. Where possible, initialize in ...	Joel Hestness	Nov. 2, 2015, 10:36 a.m.	Resolved
Transient state shouldn't have access to a RubySystem pointer.	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
Most of these changes shouldn't happen, since cache entries shouldn't have a RubySystem pointer.	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
These functions need to be moved into the RubySystem, since they are properties of each system instance. As evidence, in ...	Joel Hestness	Sept. 15, 2015, 7:37 a.m.	Open
Is this necessary? If not, please remove.	Joel Hestness	Oct. 16, 2015, 1:41 p.m.	Resolved
Why add this option here? Why not in multi-system-se.py since that is the only file that uses this option?	Jason Lowe-Power	Oct. 19, 2015, 11:04 a.m.	Resolved
Does it make sense to leave these empty constructors around? Or are there times when a NetDest will be created ...	Jason Lowe-Power	Sept. 15, 2015, 9:19 a.m.	Open
Another high-level question that applies to more than just this line: Why not have MachineType_base_count(machineType) as a method in RubySystem, ...	Jason Lowe-Power	Sept. 15, 2015, 9:19 a.m.	Open
This needs to be reverted to writeAddr.	Brandon Potter	Oct. 16, 2015, 9:41 a.m.	Resolved

Hi Brandon,

Does this mean we can compile Ruby once (for all protocols), and then dynamically instantiate it? If so, that's great!

The next step would be to build the entire src/mem tree once for all ISAs.

Brandon Potter Sept. 15, 2015, 11:21 a.m. (Sept. 15, 2015, 11:21 a.m.)

Sorry, that's not what this patch is meant to do; honestly, I haven't even put any thought into what you mentioned. The build is per-protocol still.

The goal here is to have multiple ruby systems that can invoke the same protocol. Currently, that's not possible, which means that it's not possible to simulate multiple "systems" within a single gem5 invocation.

This patch really needs to be broken into smaller chunks. It contains numerous changes without sufficient description, which will make it very difficult to merge with. In general, these changes need better object-oriented design. Also, Reviewboard won't load/display changes to RubySystem.cc, which is pretty important for reviewing this patch.
I recommend splitting out the following as separate patches:

1) Move controller, directory, etc. variables into RubySystem, add accessors as appropriate, remove static designators as appropriate, add const designators as appropriate and initialize.

2) Move testAndRead and testAndWrite into DataBlk.

3) Distribute RubySystem pointers. To do this, introduce a heritable class (let's call it 'RubySystemComponent' for the purpose of discussion), which contains a RubySystem pointer and some miscellaneous functions (Feel free to ping me if you need more detail on how to do this. I feel pretty strongly that we should do this as described here):

   A) Inherit from RubySystemComponent in all persistent simulation objects (simulated system components, but not state) that need a RubySystem pointer (e.g. CacheMemory, DirectoryMemory, PerfectCacheMemory, Network, NetworkInterface, etc.). This inherited type will at least signal how the RubySystem pointers should be distributed as compared to this patch, which just uses them wherever to get things working. Further, this will unify the naming of the RubySystem pointer, so that every component will reference it with the same variable name for consistency.

   B) Make machineCount(), makeLineAddress(), mapAddressToRange(), and map_Address_to_Directory() (etc.?) functions of both the RubySystem and RubySystemComponent. This will eliminate the need to pass a RubySystem pointer or call these functions on a RubySystem pointer by encapsulating their functionality in the inherited class functions. In RubySystemComponent, call the appropriate RubySystem function through the RubySystem pointer.

   C) Make MachineType_base* functions of RubySystem and RubySystemComponent. NOTE: This patch currently appears to make it so that multiple RubySystem instances must share a common coherence protocol. Eventually, a RubySystem instance might track the protocol it is simulating, so the MachineType_base* functions would need to be protocol-dependent. These can still be generated code but implement RubySystem/RubySystemComponent functions.

   D) Avoid getRubySystem() functions. In a few cases, the presence of these appear to signal that a component is missing a RubySystem pointer when it should have one. In other cases, child classes (e.g. ports within other components) can have direct access to the pointer in the parent class, since there is sufficient encapsulation/abstraction of who owns and can access the pointer.
I've provided lots of comments below, but I would strongly prefer that this patch be broken into smaller chunks.

Brandon Potter Sept. 15, 2015, 12:01 p.m. (Sept. 15, 2015, 12:01 p.m.)

Hey Joel, thanks for the feedback! I had hoped that you would respond to this review. I'll take a look at the issues below this weekend. By breaking the patch into pieces, it's likely that they won't compile and run individually. If I break them apart, do we agree that they should be recombined before pushing as a changeset?
Regarding A, I had originally coded a version of "RubySystemComponent" that held the ruby system pointer, but not much else. So, the addition of the class didn't seem to add anything worthwhile. If I can move the functions in B into the class too, it seems like it could be feasible. The difficulty here is generating the pointer dereference in slicc through the object. As I remember, it was pretty difficult to do so. I'd appreciate a bit of help here if this is what you really want.
For C, I might be able to move the MachineType_base functions, but I din't have any intention of making the RubySystem instance generation protocol-independent. That might be something that I could try in the future, but not near-term.
On D, I noticed this was added to the code and there didn't appear to be a good reason other than encapsulation. I'm not sure that it's even necessary. I can take a crack at it.

Joel Hestness Sept. 15, 2015, 5:31 p.m. (Sept. 15, 2015, 5:31 p.m.)

Cool. I appreciate the willingness to iterate on these changes.

By breaking the patch into pieces, it's likely that they won't compile and run individually. If I break them apart, do we agree that they should be recombined before pushing as a changeset?

The numbered items above can certainly be implemented, compiled, and run as separate patches. I expect that the lettered items under (3) can even be broken into separate changes if it makes sense to do them incrementally. Splitting out the changes from this patch into separate patches/reviews will make it much easier for someone merging their code to see why things are changing the way they are, so I expect many of us would prefer they be pushed as separate changes.

Regarding A, I had originally coded a version of "RubySystemComponent" that held the ruby system pointer, but not much else. So, the addition of the class didn't seem to add anything worthwhile. If I can move the functions in B into the class too, it seems like it could be feasible. The difficulty here is generating the pointer dereference in slicc through the object. As I remember, it was pretty difficult to do so. I'd appreciate a bit of help here if this is what you really want.

I might be wrong, but I don't think any of the functions I listed in (B) will require modifying SLICC. I'd recommend trying to move these functions incrementally as long as they don't require SLICC modification. Save functions with potential SLICC mods for (C). If you get a patch ready that adds the 'RubySystemComponent', feel free to email it to me, and we can discuss more concrete ways to migrate functions.

For C, I might be able to move the MachineType_base functions, but I din't have any intention of making the RubySystem instance generation protocol-independent. That might be something that I could try in the future, but not near-term.

Sure, I was just noting that the RubySystem may eventually need to track the coherence protocol it is simulating. This is another indication that it makes sense for the RubySystem to continue to exist (in addition to various object hierarchy analogs like SimObjects/EventManagers, Serializable, etc.).

I suspect the trickier thing with functions listed in (C) will be generating necessary code with SLICC. Again, I'd be happy to help figure out how to make that work - just keep me posted.

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

Hello Joel,

I have not addressed everything in the way that you'd asked, but I feel that this iteration is a substantial improvement over the last. I am really torn on implementing the last suggestion. Would you mind reviewing the code again and we can discuss it further if you're still unhappy? (I've tried to compromise by including Nilay's work on the block addresses and in retrospect I think it's a substantial improvement.)

Joel Hestness Nov. 3, 2015, 3:05 p.m. (Nov. 3, 2015, 3:05 p.m.)

Thank you for tackling some of this. I do feel like we still have a ways to go on this. It appears that many of the issues you have left are because we have yet to introduce the RubySystemComponent abstraction. With that in place, I expect challenges with machine type functions, and removal of RubySystem pointers from transient objects will be overcome pretty smoothly.
We had an email exchange RE: NetDests, but I didn't receive a response on that thread, and it looks like you're still facing those challenges in the latest patch. Perhaps we can reconvene in that email thread or via phone? Please let me know how you'd prefer to proceed.

src/cpu/testers/rubytest/Check.cc (Diff revision 1)

In general, it doesn't make sense for transient state, like a SenderState, to carry a pointer to a persistent simulation object like the RubySystem. I'm not sure why is is necessary to add the RubySystem pointer here, but it should be reconsidered and removed if possible.

Show all issues

src/cpu/testers/rubytest/Check.cc (Diff revision 1)

This patch uses getRubySystem() functions more common than it should. Based on the number of uses like this, Nilay is right: They're going to cause simulator performance degradation, because they're not just traversing a pointer, but also calling a function to get the pointer.

Show all issues

src/cpu/testers/rubytest/RubyTester.hh (Diff revision 1)

Per above, a SenderState shouldn't have a RubySystem pointer.

Show all issues

src/mem/protocol/MESI_Three_Level-L0cache.sm (Diff revision 1)

These constructor tags on MessageBuffer declarations are unnecessary, since the constructor is called from SWIG code. These should all be removed.

Show all issues

src/mem/protocol/MOESI_CMP_directory-L2cache.sm (Diff revision 1)

I don't recall where we ended on the mapping function discussion. However, mapping functions will be specific to each RubySystem instance. I believe we had the preference that these calls end up looking like:
ruby_system.map_Address_to_Directory(address)

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

This function is a semi-wrapper for another function "map_Address_to_DirectoryNode()" which needs to be referenced with the RubySystem pointer.  The file that this is generated in is "RubySlicc_ComponentMapping.hh".  I'm arguing that this needs to be a parameter to be able to dereference in that function.  Also, the change seems somewhat superficial in that they both achieve the same thing.

src/mem/protocol/MOESI_CMP_directory-L2cache.sm (Diff revision 1)

This doesn't make sense. Cache entries should not need a pointer to the RubySystem. Certainly the caches have RubySystem pointers, right?

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

The entries do not have a pointer to the object which owns them and I am not aware of a way to back-reference up the object hierarchy for these "transient" objects. (For instance, look at PersistentTable.hh; there's not a way with the current code to reference out of the entry to obtain the RubySystem pointer.)

The main issue with these objects needing the pointer is to allow them to use the pointer from with their NetDest objects. It may be possible to circumvent NetDest needing the RubySystem pointer, but it's unclear to me how.

src/mem/protocol/RubySlicc_ComponentMapping.sm (Diff revision 1)

Almost all of these functions are going to need to be RubySystem instance specific...

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

How do I go about doing this?  These are generated by Slicc from within Types.py and are specific to each protocol.  Blindly moving these functions directly into the RubySystem class does not work (obviously).  Since this involves re-examining previous assumptions about whether these functions are globally visibile, I'd like to avoid doing this unless you have something clever up your sleeve.  To me, the cure seems worse than the disease.

src/mem/protocol/RubySlicc_Exports.sm (Diff revision 1)

Not sure what this means...? Why is this declaration necessary?

Show all issues

src/mem/protocol/RubySlicc_Exports.sm (Diff revision 1)

Transient state shouldn't have pointers to persistent objects.

Show all issues

src/mem/protocol/RubySlicc_Types.sm (Diff revision 1)

Transient state shouldn't have pointers to persistent objects.

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)
```
I am open to suggestions if the modifications are reasonable.
```

src/mem/protocol/RubySlicc_Util.sm (Diff revision 1)

These are RubySystem instance specific functions, since calculating the return values depends on a RubySystem's cache block size. These functions should be moved into RubySystem.

Show all issues

src/mem/ruby/SConscript (Diff revision 1)

Is this correct? Nothing about the files is changed by this patch...

Show all issues

src/mem/ruby/common/Address.hh (Diff revision 1)

See prior comment.

Show all issues

src/mem/ruby/common/DataBlock.cc (Diff revision 1)

Pass around the cache line size? Sure, it makes sense to do so, since it is a property of the DataBlock. In contrast, passing around a RubySystem pointer just to get line size is very cumbersome.

Show all issues

src/mem/ruby/slicc_interface/RubySlicc_Util.hh (Diff revision 1)

I don't even know why we have these functions around: DataBlk has functions to do reads/writes, and these largely replicate that functionality with a little extra for checking correct addresses.

Show all issues

src/mem/ruby/structures/DirectoryMemory.cc (Diff revision 1)

Needs to be set in a different way with more appropriate abstraction (i.e. m_numa_high_bit should be private in RubySystem, and set once not by components outside RubySystem).

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

I removed the directories and the bits field which is derived from it.  I've tried the different protocols and I don't see where more than one directory is used in the public protocols so the m_numa_high_bit doesn't seem useful.  Maybe I am missing something obvious, but it doesn't seem like this field is useful at least in the public code?

src/mem/ruby/structures/PerfectCacheMemory.hh (Diff revision 1)

If there were appropriate inheritance unifying PerfectCacheMemory with the CacheMemory and DirectoryMemory, the assumptions would be the same about addresses being line addresses.

Show all issues

src/mem/ruby/structures/PerfectCacheMemory.hh (Diff revision 1)

ENTRY should not require a RubySystem pointer.

Show all issues

src/mem/ruby/system/RubySystem.hh (Diff revision 1)

Is m_num_directories not the same as something like MachineType_base_count(Directory)? If possible, I'd recommend trying to eliminate redundant variables here.

Show all issues

src/mem/ruby/system/RubySystem.hh (Diff revision 1)

Make these private, and add accessor functions. These should not be directly accessible from other components. Where possible, initialize in constructor initializer lists and mark variables as const.

Show all issues

src/mem/ruby/system/Sequencer.cc (Diff revision 1)

Transient state shouldn't have access to a RubySystem pointer.

Show all issues

src/mem/slicc/symbols/Type.py (Diff revision 1)

Most of these changes shouldn't happen, since cache entries shouldn't have a RubySystem pointer.

Show all issues

src/mem/slicc/symbols/Type.py (Diff revision 1)

These functions need to be moved into the RubySystem, since they are properties of each system instance. As evidence, in line 736, you're just calling a function of the RubySystem anyway.

Show all issues

Brandon Potter Nov. 2, 2015, 10:51 a.m. (Nov. 2, 2015, 10:51 a.m.)

I am willing to make this change if you explicitly explain how you'd like this done. I've spent a bit of time hammering on this code and I haven't come up with anything cleaner than what I have.

src/python/swig/pyobject.cc (Diff revision 1)

Is this necessary? If not, please remove.

Show all issues

Pretty cool that you have Ruby / gem5 working with multiple systems! Kudos for getting everything to actually work.

However, at a high-level, this patch makes the software engineer in me sad about the current state of Ruby. There are so many inter-dependencies on objects (mostly the RubySystem). Can you imagine the UML diagram of Ruby?! I'm not sure what to do about it, but it seems to me that we need a serious effort in the community to solve some of the inherent problems with Ruby's current codebase. This patch, and many of Nilay's patches as well, seem to just "patch" the underlying issues. I don't have any specific solutions, and I'm sorry to bring this rant up again...

Brandon Potter Sept. 15, 2015, 12:24 p.m. (Sept. 15, 2015, 12:24 p.m.)

Yeah, I was mortified when I started trying to solve this problem and frankly I am a little mortified at the solution. However, I do feel that this patch will go a long way towards solving (albeit with a fair amount of cleanup) at least the software-engineering issue of relying on globals/statics in an OOP design. In my opinion, that was a major mistake. From looking at the code, I can see some reason why it was done in that it avoids what I have done here, but it's a conceptual design flaw.

It seems that Joel agrees that these variables should be moved into RubySystem which was my main motivation to post this patch. I wanted to illustrate the need to centralize the misplaced variables on a per-instance object binding so that we can create multiple copies. (As I said in the patch description, the MachineType* variants were the first clue that it would need to be done.)

configs/common/Options.py (Diff revision 1)

Why add this option here? Why not in multi-system-se.py since that is the only file that uses this option?

Show all issues

Brandon Potter Sept. 15, 2015, 11:44 a.m. (Sept. 15, 2015, 11:44 a.m.)

That's a good point. We have multiple internal configurations and this was common to all of them. However, it really should be in the configuration that I'm supplying.

src/mem/ruby/common/NetDest.hh (Diff revision 1)

Does it make sense to leave these empty constructors around? Or are there times when a NetDest will be created without a RubySystem pointer?

I'm just commenting here, but there are other places too.

Show all issues

Brandon Potter Sept. 15, 2015, 11:44 a.m. (Sept. 15, 2015, 11:44 a.m.)

I noticed that after I posted the review. I'll look into it.

I rebased this patch through a few hundred changesets of which at least a third of them were related to Ruby. I suspect that some of the problems were due to the volume of conflicts that I had to solve. (The merge conflicts were innumerable; most of them were related to the changes to uint64, Addr, and general code refactoring.)

Brandon Potter Nov. 2, 2015, 10:52 a.m. (Nov. 2, 2015, 10:52 a.m.)

It seems that the default constructor is needed for a couple of cases where the object is created and then assigned (initialized) later. The compiler issues complaints from other constructors which appear to be unrelated. Upon closer inspection, there are NetDest fields which are not assigned upon the parent objects creation. These fields are initialized later before they're used.

src/mem/ruby/common/NetDest.cc (Diff revision 1)

Another high-level question that applies to more than just this line:

Why not have MachineType_base_count(machineType) as a method in RubySystem, instead of passing the RubySystem pointer around? It wouldn't really change much, but seems like it would be more readable.

Show all issues

Brandon Potter Nov. 2, 2015, 10:52 a.m. (Nov. 2, 2015, 10:52 a.m.)
```
See my response to Joel's comment.
```

Is there any way to make m_ruby_system implicit in SLICC? I really don't like having to change all of the protocols.

Brandon Potter Sept. 15, 2015, 11:44 a.m. (Sept. 15, 2015, 11:44 a.m.)

I don't really have satisfactory answer to the last question.

There was so much complexity involved when we were trying to tease out the statics and globals that we're pretty sure that the solution is sub-optimal. As far as slicc, the changes just seemed like the easiest thing to do at the time. We had an intern, David Hashe, who made the modifications to slicc; he was the one who figured out how to add the new pointer type and dereference it in the code. (So, the blame/kudos should go to him on that front. He contributed the majority of the patch in its current state so it's kudos in my opinion.) Anyways, we knew what we wanted slicc to generate so we beat on it until we were able to achieve that. I'm open to suggestions on how to clean it up.

Joel Hestness Sept. 15, 2015, 11:51 a.m. (Sept. 15, 2015, 11:51 a.m.)

Instead of making m_ruby_system implicit in SLICC, it can be inherited (along with all the existing functions) with my recommendation for a heritable class, RubySystemComponent. Following that path would eliminate the need for most of the changes in this patch. Please see my recommendations.

src/cpu/testers/rubytest/Check.cc (Diff revision 1)

This needs to be reverted to writeAddr.

Show all issues

Diff:

Revision 2 (+952 -443)

Show changes

	configs/example/multi-system-se.py
	configs/ruby/Ruby.py
	src/cpu/testers/rubytest/Check.cc
	src/cpu/testers/rubytest/RubyTester.py
	src/cpu/testers/rubytest/RubyTester.hh
	src/cpu/testers/rubytest/RubyTester.cc
	src/mem/protocol/MESI_Three_Level-L0cache.sm
	src/mem/protocol/MESI_Three_Level-L1cache.sm
	92 more

Diff:

Revision 3 (+978 -469)

Show changes

	configs/example/multi-system-se.py
	configs/ruby/Ruby.py
	src/cpu/testers/rubytest/Check.cc
	src/cpu/testers/rubytest/RubyTester.py
	src/cpu/testers/rubytest/RubyTester.hh
	src/cpu/testers/rubytest/RubyTester.cc
	src/mem/protocol/MESI_Three_Level-L0cache.sm
	src/mem/protocol/MESI_Three_Level-L1cache.sm
	92 more

Diff:

Revision 4 (+793 -362)

Show changes

	configs/example/multi-system-se.py
	configs/ruby/Ruby.py
	src/cpu/testers/rubytest/RubyTester.py
	src/cpu/testers/rubytest/RubyTester.hh
	src/cpu/testers/rubytest/RubyTester.cc
	src/mem/protocol/MESI_Three_Level-L0cache.sm
	src/mem/protocol/MESI_Three_Level-L1cache.sm
	src/mem/protocol/MESI_Two_Level-L1cache.sm
	84 more

Diff:

Revision 5 (+772 -352)

Show changes

	configs/example/multi-system-se.py
	configs/ruby/Ruby.py
	src/cpu/testers/rubytest/RubyTester.py
	src/cpu/testers/rubytest/RubyTester.hh
	src/cpu/testers/rubytest/RubyTester.cc
	src/mem/protocol/MESI_Three_Level-L0cache.sm
	src/mem/protocol/MESI_Three_Level-L1cache.sm
	src/mem/protocol/MESI_Two_Level-L1cache.sm
	81 more

You have a pending review.

Review Board 2.0.15

Brandon Potter got review request #3113!

This change has been discarded.

ruby: allows multiple instances of ruby to be invoked

Screenshots

Files

Issue Summary

Diff:

Diff:

Diff:

Diff:

Status: Discarded