Re: [gem5-dev] Configuration GUI for gem5
Hi Marcus, I’d also say this would be a great topic for the User Workshop at ISCA: http://www.gem5.org/User_workshop_2015 Andreas On 03/03/2015 15:14, Ali Saidi via gem5-dev gem5-dev@gem5.org wrote: Hi Marcus, Option 1 is probably the most preferred route as the code is much more likely to say in-sync and compatible if it¹s in the same repository and tested along side gem5. The best way to proceed with that option is to post your patches to the gem5 review board http://reviews.gem5.org. If you¹re using mercurial this can be done with the post-review plugin to gem5. Take a look at: http://www.gem5.org/Commit_Access Thanks for doing this, I think it would be a great help to new users! Ali On 3/3/15, 9:07 AM, Marcus Johnson via gem5-dev gem5-dev@gem5.org wrote: Hi, I am a senior at Colorado State University working with two other students under Dr. Sudeep Pasricha on a senior design project. We have created a GUI to aid in configuring gem5 simulations. It currently supports a variety of command line options which are supplied to the se.py and fs.py scripts. We are beginning to implement some exploration functionality, so that on any particular parameter, a user could specify multiple options for which a simulation would run for each. One of the most important advantages this GUI brings is a reduction to the learning curve to using gem5, as well as a huge aid in debugging configuration options. It has many simple error checks to prevent simple mistakes. We would like to contribute this project open-source to the gem5 community, and wanted to see what your thoughts are on integrating it with gem5. We believe there are two different routes we can take: Option 1 would be to push our code to the gem5 repository. If this is an acceptable option, what is a good way to proceed with this? Option 2 would be to have our code run completely independent of gem5 (the user would specify as an option where they have downloaded gem5 code, or we release it as a patch for gem5). If this were the case, is there a good way for us to market this to the gem5 community? What are your thoughts on the above two options? Thanks, Marcus Johnson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Configuration GUI for gem5
Hi Marcus, Option 1 is probably the most preferred route as the code is much more likely to say in-sync and compatible if it¹s in the same repository and tested along side gem5. The best way to proceed with that option is to post your patches to the gem5 review board http://reviews.gem5.org. If you¹re using mercurial this can be done with the post-review plugin to gem5. Take a look at: http://www.gem5.org/Commit_Access Thanks for doing this, I think it would be a great help to new users! Ali On 3/3/15, 9:07 AM, Marcus Johnson via gem5-dev gem5-dev@gem5.org wrote: Hi, I am a senior at Colorado State University working with two other students under Dr. Sudeep Pasricha on a senior design project. We have created a GUI to aid in configuring gem5 simulations. It currently supports a variety of command line options which are supplied to the se.py and fs.py scripts. We are beginning to implement some exploration functionality, so that on any particular parameter, a user could specify multiple options for which a simulation would run for each. One of the most important advantages this GUI brings is a reduction to the learning curve to using gem5, as well as a huge aid in debugging configuration options. It has many simple error checks to prevent simple mistakes. We would like to contribute this project open-source to the gem5 community, and wanted to see what your thoughts are on integrating it with gem5. We believe there are two different routes we can take: Option 1 would be to push our code to the gem5 repository. If this is an acceptable option, what is a good way to proceed with this? Option 2 would be to have our code run completely independent of gem5 (the user would specify as an option where they have downloaded gem5 code, or we release it as a patch for gem5). If this were the case, is there a good way for us to market this to the gem5 community? What are your thoughts on the above two options? Thanks, Marcus Johnson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Configuration GUI for gem5
Hi, I am a senior at Colorado State University working with two other students under Dr. Sudeep Pasricha on a senior design project. We have created a GUI to aid in configuring gem5 simulations. It currently supports a variety of command line options which are supplied to the se.py and fs.py scripts. We are beginning to implement some exploration functionality, so that on any particular parameter, a user could specify multiple options for which a simulation would run for each. One of the most important advantages this GUI brings is a reduction to the learning curve to using gem5, as well as a huge aid in debugging configuration options. It has many simple error checks to prevent simple mistakes. We would like to contribute this project open-source to the gem5 community, and wanted to see what your thoughts are on integrating it with gem5. We believe there are two different routes we can take: Option 1 would be to push our code to the gem5 repository. If this is an acceptable option, what is a good way to proceed with this? Option 2 would be to have our code run completely independent of gem5 (the user would specify as an option where they have downloaded gem5 code, or we release it as a patch for gem5). If this were the case, is there a good way for us to market this to the gem5 community? What are your thoughts on the above two options? Thanks, Marcus Johnson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Configuration GUI for gem5
So what does the GUI do? Can you drag and drop different components and then connect as required? Or is it that you can just set values for different variables? Can you provide some screen shots? -- Nilay On Tue, 3 Mar 2015, Marcus Johnson via gem5-dev wrote: Hi, I am a senior at Colorado State University working with two other students under Dr. Sudeep Pasricha on a senior design project. We have created a GUI to aid in configuring gem5 simulations. It currently supports a variety of command line options which are supplied to the se.py and fs.py scripts. We are beginning to implement some exploration functionality, so that on any particular parameter, a user could specify multiple options for which a simulation would run for each. One of the most important advantages this GUI brings is a reduction to the learning curve to using gem5, as well as a huge aid in debugging configuration options. It has many simple error checks to prevent simple mistakes. We would like to contribute this project open-source to the gem5 community, and wanted to see what your thoughts are on integrating it with gem5. We believe there are two different routes we can take: Option 1 would be to push our code to the gem5 repository. If this is an acceptable option, what is a good way to proceed with this? Option 2 would be to have our code run completely independent of gem5 (the user would specify as an option where they have downloaded gem5 code, or we release it as a patch for gem5). If this were the case, is there a good way for us to market this to the gem5 community? What are your thoughts on the above two options? Thanks, Marcus Johnson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron m5test@zizzer2 /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp CHANGED! * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing CHANGED! scons: *** Error 1 scons: *** Error 1 * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 24, 2015, 8:26 p.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On Feb. 24, 2015, 5:22 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 24, 2015, 5:22 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 24, 2015, 8:26 p.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). Steve Reinhardt wrote: I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? Curtis Dunham wrote: I understand the confusion - the scheduling interfaces across the family of Event* classes isn't entirely consistent. You bring up a good point about the destruction, as the last tweak made it heap allocated rather than an initialized-on-demand static. I will check on this and update as such if it works! Thanks for the careful feedback. Yes, in thinking about the right way to deal with this, most of my solutions involved tweaking the event functions themselves to be more consistent, which let to questions about whether that would actually work (e.g., taking the scheduled() check out of BaseGlobalEvent::deschedule()). I didn't want to burden you with that, but at the same time I wasn't happy with putting in a workaround either. If we can sidestep the issue entirely, then we can just move on until someone else messes with this code :). - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On Feb. 24, 2015, 5:22 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 24, 2015, 5:22 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 25, 2015, 4:26 a.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). Steve Reinhardt wrote: I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? I understand the confusion - the scheduling interfaces across the family of Event* classes isn't entirely consistent. You bring up a good point about the destruction, as the last tweak made it heap allocated rather than an initialized-on-demand static. I will check on this and update as such if it works! Thanks for the careful feedback. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On Feb. 25, 2015, 1:22 a.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 25, 2015, 1:22 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5933 --- Ship it! Thanks for the changes! - Steve Reinhardt On March 3, 2015, 3:43 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated March 3, 2015, 3:43 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/simulate.hh 8a20e2a1562debfc20b92be4581457c4147b3733 src/sim/simulate.cc 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 12:56 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 src/mem/ExternalSlave.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:04 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated March 3, 2015, 11:43 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs (updated) - src/sim/simulate.hh 8a20e2a1562debfc20b92be4581457c4147b3733 src/sim/simulate.cc 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 12:47 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 src/mem/ExternalSlave.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:07 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote: Took me longer to review this just because I'm not sure what to think of it. It's not pretty, but I don't have better ideas, so it's hard to object. One thing that bothers me is that, while it's noble to try and generalize things, despite the generic-sounding --external-memory-system switch, many of the low-level details seem very sst-specific (like 'port_type=sst' as an obvious one). Would it be more appropriate just to call the option --sst-memory? Also, the ExternalCache thing looks like it should be a subclass, even though it's just a function. I can see how the function is more convenient, but making it a subclass would allow some better encapsulation of the cpu_side __getattr__/__setattr__ hack. These are just general thoughts though... I'm very interested in others' input. Curtis Dunham wrote: There is some truth to this complaint. I think there is a little room for improvement, though. It's ready for another look at diff r5. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/#review5914 --- On March 4, 2015, 1:07 a.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:07 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 25, 2015, 4:26 a.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). Steve Reinhardt wrote: I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? Curtis Dunham wrote: I understand the confusion - the scheduling interfaces across the family of Event* classes isn't entirely consistent. You bring up a good point about the destruction, as the last tweak made it heap allocated rather than an initialized-on-demand static. I will check on this and update as such if it works! Thanks for the careful feedback. Steve Reinhardt wrote: Yes, in thinking about the right way to deal with this, most of my solutions involved tweaking the event functions themselves to be more consistent, which let to questions about whether that would actually work (e.g., taking the scheduled() check out of BaseGlobalEvent::deschedule()). I didn't want to burden you with that, but at the same time I wasn't happy with putting in a workaround either. If we can sidestep the issue entirely, then we can just move on until someone else messes with this code :). Testing went well, so I dropped this tweak. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On March 3, 2015, 11:43 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated March 3, 2015, 11:43 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/simulate.hh 8a20e2a1562debfc20b92be4581457c4147b3733 src/sim/simulate.cc 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2667: ext: Add SST connector
On Feb. 25, 2015, 1:55 a.m., Nathan Binkert wrote:
Not to be difficult, but is it possible for Sandia to just use the standard
gem5 license (which is basically the same thing you've already got)? And
if yes, can we just include it in the main tree instead of ext?
I've reached out to them in case they want to comment on this.
I don't understand the benefit of putting it in the main tree - where would it
ideally live? The connector doesn't link into the primary gem5 targets anyway
- it builds its own .so that, when loaded by SST, then loads
libgem5_{opt,debug,fast}.so.
- Curtis
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2667/#review5912
---
On Feb. 25, 2015, 1:16 a.m., Curtis Dunham wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2667/
---
(Updated Feb. 25, 2015, 1:16 a.m.)
Review request for Default.
Repository: gem5
Description
---
Changeset 10708:344bc6b7203d
---
ext: Add SST connector
This patch adds a connector that allows gem5 to be used as a component
in SST (Structural Simulation Toolkit, sst-simulator.org). At a high
level, this allows memory traffic to pass between the two simulators.
SST Links are roughly analogous to gem5 Ports, although Links do not
have a notion of master and slave. This distinction is important to
gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave
must be used, and similarly when connecting the memory side of SST cache
to a gem5 port (for memory - I/O), an ExternalMaster must be used.
These connectors handle the administrative aspects of gem5
(initialization, simulation, shutdown) as well as translating SST's
MemEvents into gem5 Packets and vice-versa.
Diffs
-
ext/sst/ExtMaster.hh PRE-CREATION
ext/sst/ExtMaster.cc PRE-CREATION
ext/sst/ExtSlave.hh PRE-CREATION
ext/sst/ExtSlave.cc PRE-CREATION
ext/sst/LICENSE PRE-CREATION
ext/sst/Makefile PRE-CREATION
ext/sst/README PRE-CREATION
ext/sst/gem5.hh PRE-CREATION
ext/sst/gem5.cc PRE-CREATION
ext/sst/libgem5.cc PRE-CREATION
Diff: http://reviews.gem5.org/r/2667/diff/
Testing
---
Thanks,
Curtis Dunham
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
Took me longer to review this just because I'm not sure what to think of
it. It's not pretty, but I don't have better ideas, so it's hard to object.
One thing that bothers me is that, while it's noble to try and generalize
things, despite the generic-sounding --external-memory-system switch,
many of the low-level details seem very sst-specific (like
'port_type=sst' as an obvious one). Would it be more appropriate just to
call the option --sst-memory?
Also, the ExternalCache thing looks like it should be a subclass, even
though it's just a function. I can see how the function is more
convenient, but making it a subclass would allow some better encapsulation
of the cpu_side __getattr__/__setattr__ hack.
These are just general thoughts though... I'm very interested in others'
input.
There is some truth to this complaint. I think there is a little room for
improvement, though.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
configs/common/CacheConfig.py, line 130
http://reviews.gem5.org/r/2668/diff/1/?file=43775#file43775line130
I assume this naming is also specific to sst
Not here.
The naming just has to agree with the configuration on the other side, which
in this case is the ext/sst/tests/test6_arm_4c.py in this patchset. However as
long as any other simulator we hook up with is cool with the same naming, it
doesn't need to be changed.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
configs/common/CacheConfig.py, line 50
http://reviews.gem5.org/r/2668/diff/1/?file=43775#file43775line50
This seems obviously specific to sst here
Correct that port_type=sst is SST specific because the
ext/sst/Ext{Master,Slave} code registers a handler for handler_name sst.
Perhaps --external-memory-system could take a string argument that could be
stuck here? We'd use --external-memory-system=sst on the command line.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
src/mem/ExternalSlave.py, line 57
http://reviews.gem5.org/r/2668/diff/1/?file=43782#file43782line57
To me, this clearly straddles the line between clever and
horrifying :). If nothing else, it would be nice to put these in an
ExternalCache subclass.
Clever/Horrifying... Yes. :)
My concern here is that creating a new class doesn't seem to solve the problem.
As best I can tell, you just end up moving this unsightly hack to the new
class instead. But the value of not having to create new conditional
statements to set either port (for external memory) or cpu_side (for gem5's
internal caches) seems worth this bit of nastiness.
- Curtis
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2668/#review5914
---
On Feb. 20, 2015, 6:47 p.m., Curtis Dunham wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2668/
---
(Updated Feb. 20, 2015, 6:47 p.m.)
Review request for Default.
Repository: gem5
Description
---
Changeset 10709:a3b771cd744c
---
config: Support full-system with SST's memory system
This patch adds an example configuration in ext/sst/tests/ that allows
an SST/gem5 instance to simulate a 4-core AArch64 system with SST's
memHierarchy components providing all the caches and memories.
Diffs
-
configs/common/CacheConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/FSConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/MemConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/example/fs.py c6cb94a14fea4c59780d73d1623d7031bcede6af
ext/sst/tests/test6_arm_4c.py PRE-CREATION
src/dev/arm/RealView.py c6cb94a14fea4c59780d73d1623d7031bcede6af
src/mem/ExternalSlave.py c6cb94a14fea4c59780d73d1623d7031bcede6af
Diff: http://reviews.gem5.org/r/2668/diff/
Testing
---
Thanks,
Curtis Dunham
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2619: cpu: Add L-TAGE branch predictor
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/#review5927 --- Ship it! Some minor formatting issues, but overall it looks good. Thanks for getting this in shape. - Andreas Hansson On March 3, 2015, 2:53 a.m., Dibakar Gope wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2619/ --- (Updated March 3, 2015, 2:53 a.m.) Review request for Default. Repository: gem5 Description --- It is the L-TAGE predictor from the Branch Prediction Championship, originally coded by Vignyan Reddy, and modified by me. Changeset 10727:73315fc01762 --- [mq]: ltage_updated.patch Diffs - src/cpu/pred/2bit_local.hh 8a20e2a1562d src/cpu/pred/2bit_local.cc 8a20e2a1562d src/cpu/pred/BranchPredictor.py 8a20e2a1562d src/cpu/pred/SConscript 8a20e2a1562d src/cpu/pred/bi_mode.hh 8a20e2a1562d src/cpu/pred/bi_mode.cc 8a20e2a1562d src/cpu/pred/bpred_unit.hh 8a20e2a1562d src/cpu/pred/bpred_unit.cc 8a20e2a1562d src/cpu/pred/bpred_unit_impl.hh 8a20e2a1562d src/cpu/pred/ltage.hh PRE-CREATION src/cpu/pred/ltage.cc PRE-CREATION src/cpu/pred/tournament.hh 8a20e2a1562d src/cpu/pred/tournament.cc 8a20e2a1562d Diff: http://reviews.gem5.org/r/2619/diff/ Testing --- Thanks, Dibakar Gope ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
