This is to avoid having to expose the scheduler (which tracks the
current process) to header files which should be independent of gem5
and the underlying implementation.
Change-Id: I1b0810ab66c3ce52b5b94236d7df86da66a62472
Reviewed-on: https://gem5-review.googlesource.com/c/13335
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
STL containers may need to be constructed before they're used. Don't
count on being able to insert into them during a static initializer.
Change-Id: Icb05d5084a470e1ebd976ae6e1954b1a78aabd6a
Reviewed-on: https://gem5-review.googlesource.com/c/13329
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
There's a deprecated reporting mechanism based on integer message ids,
and the reporting mechanism needs to be refactored a bit to make it
easier to support.
Some bookkeeping data structures were moved out to somewhere they
can be accessed by other code, obviating the non-standard get_handler
function.
Change-Id: Id427cd79be9ef0f3275fbac39ff047ab672fb3e0
Reviewed-on: https://gem5-review.googlesource.com/c/13318
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When resetting a process which is ready pending coming out of suspend,
clear that state since the process is about to run in service of the
reset.
Change-Id: Iade3ec4b2f3eadd372cce456dca66850d37ed5fd
Reviewed-on: https://gem5-review.googlesource.com/c/13316
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
For some reason lost to the sands of time, the throw_it function was
virtual for the Thread class, and that class would call the base
class's throw_it, and then also injectException itself. That would
result in the exception being injected into the thread twice which is
incorrect.
Since it's not clear what the original intention of this code was, the
throw_it function is now no longer virtual, and the one useful aspect
of it, a check if the process is already terminated, was moved into the
base class function.
Change-Id: I7fb14baa7728bd1e9206011870b6ccaa9c4e8c64
Reviewed-on: https://gem5-review.googlesource.com/c/13312
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If an exception escapes sc_main, Accellera catches it and feeds it
into the report handler, telling it to run the catch actions. This
seems like it sets up lots of dangerous scenarios, and also makes a
vital error detecting path more complex and error prone.
On the other hand, it makes one of the tests pass.
Change-Id: I7f9d07e01e63c7abeee903febe2e434041ec49a4
Reviewed-on: https://gem5-review.googlesource.com/c/13307
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These are used in one of the tests, specifically the comma operator. It
didn't cause compilation to fail because of the default meaning of the
comma.
Change-Id: I7ce7fe74f02d4ad6a4ab896a2f0d6bd1ce635c2f
Reviewed-on: https://gem5-review.googlesource.com/c/13298
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Positionally binding more than once (like with the deprecated comma or
<< operators) should pick up where it left off the last time instead
of starting again from the beginning.
Change-Id: Ifc33520d6ce40544bd0ad80a5657b1a38a7914e4
Reviewed-on: https://gem5-review.googlesource.com/c/13297
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The previous implementation used the value changed event to track when
signals changed value, but there were a couple problems with this
approach. First, this piggybacked on the sensitivity mechanism in some
ways, but diverged in others. The sensitivity didn't notify a process
when it was satisfied like other sensitivity types would, and it also
ignored whether the process was disabled.
Second, the value_changed_event is notified by a signal instance as a
delta notification, but reset signals are supposed to act immediately.
That means they should happen before all delta notifications, or in
other words all delta notifications should see the reset status of a
given process. That's particularly important in the case of wait(int n)
where setting the reset clears the reset count, and the count is
checked when determining whether or not to wake up a process when its
sensitivity is satisfied, potentially by a delta notification.
Third, by removing the middle man and not trying to repurpose the
sensitivity mechanism, the code gets simpler and easier to understand.
Change-Id: I0d05d11437291d368b060f6a45a207813615f113
Reviewed-on: https://gem5-review.googlesource.com/c/13294
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It appears that events which are triggered during the timing phase
are considered triggered in the following evaluation phase. The
"triggered()" function on events is non-standard and not really
explained anywhere, but this appears to work in practice.
Change-Id: I2574dc4569bf148c55fbe2a4873d458fc507f2a5
Reviewed-on: https://gem5-review.googlesource.com/c/13293
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The standard says that there are namespaces for each module, and
one global namespace. Accellera also has namespaces for each process,
which shows up in the test output.
Change-Id: I4c8c5cecd5fb685d7bab521d9ae131aef23a6ab4
Reviewed-on: https://gem5-review.googlesource.com/c/13291
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Because SC_REPORT_ERROR usually causes an exception to be thrown, it's
easy to assume it will be the last thing executed in a function. It
might, however, be set up to do nothing, in which case the function
will continue to execute.
This change makes sure sc_prim will be set up properly even if errors
about the time a channel can be set up are ignored.
Also, if an exception is thrown while sc_port is being set up, the
corresponding Port object needs to be cleaned up. Rather than try to
intercept exceptions in the constructor and clean up properly, we'll
just make the allocation of the Port object be the last thing it does.
If the function exits early, then the Port pointer will still be
nullptr and nothing will need to be done.
Change-Id: If8f6f6b7e6830235fee3cd75625240b99e87dfbe
Reviewed-on: https://gem5-review.googlesource.com/c/13289
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make it the end of "before_end_of_elaboration" rather than the end
of "end_of_elaboration". This interpretation fits the behavior expected
by some of the tests.
Change-Id: I3f589147834ab5d5dc8c0e9b4849dd00491c5848
Reviewed-on: https://gem5-review.googlesource.com/c/13287
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The current process will still be set sometimes when exiting from the
yield loop in the top of runReady in the scheduler. Clear it to ensure
that we don't think a process is running when it isn't.
Change-Id: Idd44689e10fadf4a3e3ec07c60d107c80a44d39f
Reviewed-on: https://gem5-review.googlesource.com/c/13201
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This function is standard and supposed to be on sc_interface, but it
was somehow left out. This change adds it, and makes sure it's called
by the port binding code. The default implementation does nothing, as
it's supposed to according to the spec.
Also note that only the ports farthest from the interfaces are suppose
to call register_port. As the port bindings are completed, we keep
track of whether a port has been bound to another port. If it has, the
source port is farther from the interfaces than the target port (since
it has to go "through" the target port to get to them, and so the
target port should not call register_port.
Change-Id: Ia98f9ff364385fd1699d88a1d99787d205816a08
Reviewed-on: https://gem5-review.googlesource.com/c/13199
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
In the Accellera implementation, interfaces are bound to ports
immediately if no ports have been bound, and otherwise saves them for
later along with the ports. The existing implementation would save
all interface and port bindings to finalize at the end of elaboration.
This seems like pointless complexity, but it's necessary to get the
output to match in the tests.
Change-Id: Ib82d324ee2be9e56e6a41561611c7fca4f4f4e72
Reviewed-on: https://gem5-review.googlesource.com/c/13196
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
There's a lot of repeated code for this. Also, the sc_vector type
needs to be able to artificially inject a parent for the objects it
creates.
Change-Id: I76f9b551632cd2cd70e26741b215290b35c382e9
Reviewed-on: https://gem5-review.googlesource.com/c/13194
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This creates a depenendency on c++11 which the headers otherwise avoid,
but gem5 itself already has a c++11 dependency and not a boost
dependency, and outside of having a local copy of boost (which
Accellera does) there isn't a good way to put the placeholder values
_1, _2, etc., into the custom sc_unnammed namespace.
Change-Id: I52ca4c1bc52bef6ff2c62e9f3c32af46f95244dc
Reviewed-on: https://gem5-review.googlesource.com/c/13193
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_time constructor was being called, but because of implicit type
conversions, a const char * was being treated as a bool and totally
unrelated constructor was being called.
This change adds and implements the missing but non-standard
constructor. It also implements the from_string function which uses
that constructor.
Change-Id: I21e7e40fd1a8d1c579b1abdc2036d016501f510c
Reviewed-on: https://gem5-review.googlesource.com/c/13191
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
reportifyException was sometimes indirectly creating temporary
sc_report objects which would go out of scope when they were
returned. The later code which tried to print them would then read
garbage.
Change-Id: I0a744eb029c62bf2ffee83db0a0e6dcbe3e60f7d
Reviewed-on: https://gem5-review.googlesource.com/c/13190
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This class is non-standard and is an implementation detail in
Accellera's implementation, but is referred to directly by the tests.
It does the same thing as the time printing function, so rather than
having duplicate code the printing function now uses the sc_time_tuple
class even though it was doing fine on its own already.
Change-Id: I69594ed0651f212ded6d979d60523bb3b0a789b1
Reviewed-on: https://gem5-review.googlesource.com/c/13189
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Always notify a process if a reset signal changed, even if it's
disabled. Also, because notify was what checked disabled and only
notifyWork was virtual, this change merges the two so both can be
overridden without any extra virtual functions.
Change-Id: I1e3563fa587aab65a5e95cd8a382ed48e093de3b
Reviewed-on: https://gem5-review.googlesource.com/c/13188
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The target may be the process which is currently running. In that case,
the reset method will end and never get to notifying the reset event.
To fix that, we need to notify the reset event first.
Change-Id: If3a9d87edc0999293a68d86d35989ae49eab3c07
Reviewed-on: https://gem5-review.googlesource.com/c/13187
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The implementation is based on sc_event sensitivities.
Also of note is that the way reset works in the Accellera
implementation isn't consistent with the spec. That says that
wait(int n) is supposed to be equivalent to calling wait() n times,
assuming n is greater than 0.
Instead, Accellera stores that count and then doesn't wake up the
process until the count is 0, decrementing it otherwise.
That means that when the process is in reset, it won't actually reset
for those intermediate wait()s which it would if wait() was called
repeatedly. Also, oddly, when a reset becomes asserted, it will clear
the count to 0 explicitly. That may have been an attempt to make the
behavior of wait(int n) match the spec, but it doesn't handle cases
where the reset is already set when wait(int n) is called.
Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b
Reviewed-on: https://gem5-review.googlesource.com/c/13186
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
sc_time is now represented in whatever the underlying time resolution
is which isn't necessarily ps. Stop trying to scale it (incorrectly).
Change-Id: I18975e0ab01386b24196666e0ba02d1b36e11735
Reviewed-on: https://gem5-review.googlesource.com/c/12976
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
sc_time is now inherently based on properly scaled Ticks, so there's no
reason to try to scale it to be in picoseconds, especially since the
scaling factor may be unreliable if the timescale hasn't been fixed
yet.
Change-Id: I28baeb9792e81e1d00f6f37672df435766311864
Reviewed-on: https://gem5-review.googlesource.com/c/12974
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
