Searched hist:9983 (Results 1 - 25 of 28) sorted by relevance
| /gem5/src/base/ | ||
| H A D | barrier.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| /gem5/src/sim/ | ||
| H A D | global_event.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | global_event.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | simulate.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | eventq_impl.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | Root.py | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | debug.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | core.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | core.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | stat_control.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | simulate.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | sim_exit.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | root.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | sim_events.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | sim_events.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | eventq.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | sim_object.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | serialize.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | eventq.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | serialize.hh | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | SConscript | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| /gem5/src/python/m5/ | ||
| H A D | event.py | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| H A D | simulate.py | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| /gem5/src/dev/x86/ | ||
| H A D | Pc.py | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
| /gem5/src/cpu/kvm/ | ||
| H A D | base.cc | 9983:2cce74fe359e Mon Nov 25 12:21:00 EST 2013 Steve Reinhardt <stever@gmail.com>, Nilay Vaish <nilay@cs.wisc.edu>, Ali Saidi <Ali.Saidi@ARM.com> sim: simulate with multiple threads and event queues This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish |
Completed in 183 milliseconds