Hi to all in this discussion,

I wanted to add some points to the discussion above regarding ARM+ RUBY. I
have been working with ARM +RUBY and I have simulated 2x2/ 4x4 Mesh_XY NoC
with MESI_Two_Level protocol. This protocol works fine with ARM in full
system mode. But originally MESI_Two_Level lacked the multiple DMA
controllers support. I added this support to make it working. Also ARM
works fine with DerivO3CPU model but size of L2 has to be at least 2MB to
get it working otherwise there is deadlock problem. Hope this helps.

regards,
Muhammad



On 26 February 2018 at 22:36, Jason Lowe-Power <ja...@lowepower.com> wrote:

> Hi Paul,
>
> It's in my brain, why don't other know this automatically ;).
>
> ARM works well with all of the CPU models and the classic caches. There
> are limited cases where ARM works with Ruby. To find out what ARM+Ruby is
> supported I would look back through the commit log to see which protocols
> have been updated. I think MESI_Two_level is the one that's tested (see
> build_opts/ARM).
>
> x86 works well with O3, and can sometimes work with the in order (minor).
> Minor was originally written with only ARM in mind, but I think x86 mostly
> works. x86 works well with all Ruby protocols and with the classic caches.
>
> If you apply the right patches (see gem5-review.googlesource.com) x86+KVM
> works well with the classic caches. There were recent patches to get
> x86+KVM+Ruby to work. I haven't tested them, but I have no reason to think
> it won't work.
>
> My opinion is that it doesn't make sense to do architecture research with
> the other ISAs (just my personal opinion!). I think this is shared by
> others because only x86 and ARM have consistent contributions. Take that as
> you will.
>
> Also, I have been using full-system mode exclusively for that past 4 years
> or so. I'm not sure what the state of SE mode is. I know x86+SE mode is
> pretty well supported, especially if you're on a Linux host (well, except
> Ubuntu 17.10+). My opinion is that SE mode is good for testing little
> things, but serious research simulations should use FS mode (again, just my
> opinion).
>
> Hopefully this provides some guidance.
>
> Cheers,
> Jason
>
>
> On Sat, Feb 24, 2018 at 1:33 AM Paul V. Gratz <pgr...@gratz1.com> wrote:
>
>> Hi Jason,
>> Hmm, do you have a sense for which (just a small subset is fine)
>> combinations are a good idea to run and/or which aren't :-).
>> Paul
>>
>> On Fri, Feb 23, 2018 at 5:09 PM, Jason Lowe-Power <ja...@lowepower.com>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Yeah, the status matrix is very out of date. I would like to see it
>>> automatically updated by our regression tests / continuous integration
>>> tests. However, those are also wildly out of date.
>>>
>>> It would be *fabulous* if someone had time / money / energy to revamp
>>> our testing infrastructure and get some of these things up to date. There
>>> was some work last summer in re-writing the regression tester that was
>>> never finished, Gabe has done some great work getting the unittests working
>>> again, and I know that internally AMD and ARM have tests that run. It's
>>> unfortunate that it's not a priority for me :/. This is what I feel most
>>> guilty about ;).
>>>
>>> @EVERYONE:
>>> If you know of anyone (junior grad students, masters students, motivated
>>> undergrads, anyone who wants to contribute to an open source project, etc.)
>>> who would be up for working on this, I'm happy to help advise! This isn't a
>>> *hard* project. It will just take some time and effort. This would have
>>> very significant impact on this project. I can't think of anything that
>>> would have a broader impact!
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Fri, Feb 23, 2018 at 4:15 AM Paul V. Gratz <pgr...@gratz1.com> wrote:
>>>
>>>> Hey Jason,
>>>> Sure no problem, my guess is that the uninitialized warning/error is
>>>> ARM specific (its in some neon memory file)  so maybe that's why it fell
>>>> through?  BTW, on a similar note, I see that the gem5 status matrix (
>>>> http://gem5.org/Status_Matrix) hasn't been updated in a number of
>>>> years, is that matrix still valid?  If not is there a good source for that
>>>> kind of info (or have the various combos become generally more supported?).
>>>>
>>>> How is your first year at UCD going!  Are you going to be at HPCA this
>>>> year?  Incidentally, I ran across your learning gem5 site and have been
>>>> working through it, thanks for that site, its great!
>>>> Paul
>>>>
>>>>
>>>> On Thu, Feb 22, 2018 at 4:16 PM, Jason Lowe-Power <ja...@lowepower.com>
>>>> wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> Thanks for letting us know. There's currently a patch on our review
>>>>> site that solves the implicit fallthrough problem (
>>>>> https://gem5-review.googlesource.com/c/public/gem5/+/8541). I haven't
>>>>> seen the uninitialized warning, though.
>>>>>
>>>>> Cheers,
>>>>> Jason
>>>>>
>>>>> -----------
>>>>> Jason Lowe-Power
>>>>> Assistant Professor, Computer Science Department
>>>>> University of California, Davis
>>>>> 3049 Kemper Hall
>>>>> https://faculty.engineering.ucdavis.edu/lowepower/
>>>>>
>>>>>
>>>>> On Thu, Feb 22, 2018 at 5:56 AM Paul V. Gratz <pgr...@gratz1.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>> I just did a clean clone of the latest github on my Ubuntu 17.10
>>>>>> system (gcc 7.2.0).  In this setup builds fail due to two warnings 
>>>>>> (because
>>>>>> -Werror is on in the build scripts).
>>>>>>
>>>>>> First in decode-method.cc.inc there are some case statements that
>>>>>> have fallthrough conditions.  To get around this I added:
>>>>>>
>>>>>> main.Append(CXXFLAGS=['-Wno-implicit-fallthrough'])
>>>>>>
>>>>>> to the SConstruct file (is this the right way to do this?).
>>>>>>
>>>>>> Second, in neon64_mem.hh there are some potentially uninitialized
>>>>>> variables.  To get around this I added maybe-uninitialized to the 
>>>>>> CCFLAGS:
>>>>>>    main.Append(CCFLAGS=['-Werror',
>>>>>>                         '-Wno-error=deprecated-declarations',
>>>>>>                         '-Wno-error=deprecated',
>>>>>>                         '-Wno-error=maybe-uninitialized',
>>>>>>                        ])
>>>>>>
>>>>>> After this the build completes cleanly.  Probably those warnings
>>>>>> should be fixed in the source code directly but I am not yet well versed
>>>>>> enough in how gem5 works to do that yet.  I'm guessing that these 
>>>>>> warnings
>>>>>> are new with my gcc version is why I don't see anyone posting on here 
>>>>>> about
>>>>>> them yet..
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----------------------------------------
>>>>>> Paul V. Gratz
>>>>>> Associate Professor
>>>>>> ECE Dept, Texas A&M University
>>>>>> Office: 333M WERC
>>>>>> Phone: 979-488-4551 <(979)%20488-4551>
>>>>>> http://cesg.tamu.edu/faculty/paul-gratz/
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-users@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-users@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------
>>>> Paul V. Gratz
>>>> Associate Professor
>>>> ECE Dept, Texas A&M University
>>>> Office: 333M WERC
>>>> Phone: 979-488-4551 <(979)%20488-4551>
>>>> http://cesg.tamu.edu/faculty/paul-gratz/
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-users@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>>
>> --
>> -----------------------------------------
>> Paul V. Gratz
>> Associate Professor
>> ECE Dept, Texas A&M University
>> Office: 333M WERC
>> Phone: 979-488-4551 <(979)%20488-4551>
>> http://cesg.tamu.edu/faculty/paul-gratz/
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to