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>
The default implementation returns a dummy event, but in the Accellera
implementation it also prints a warning. Print a warning as well, so
that the output matches for the tests.
Change-Id: I1ae2755685515c3fe538f4075af396e963cf155d
Reviewed-on: https://gem5-review.googlesource.com/c/12970
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This function just returned false. The new implementation uses the
scheduler's changeStamp function to keep track of how recently the
event was triggered so it can return return the right value.
Change-Id: Idf61cd459e53e224a33d3e53c16210f5e0a99a3a
Reviewed-on: https://gem5-review.googlesource.com/c/12825
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Accellera allows some non-standard values in the second position of the
SC_CTHREAD macro. Do that as well, with the same special handling which
automatically selects the positive edge of boolean ports/interfaces.
Change-Id: I79594980898a17afc30fea6f77384589cbc3c250
Reviewed-on: https://gem5-review.googlesource.com/c/12809
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The Accellera implementation looks like it does all the methods, then
all the threads, and then loops back and tries again, and there are
even comments in the code that suggests that. What it actually does,
however, is runs all the methods, then runs a single thread if one is
waiting, and then starts over. The effect is that the scheduler will
run any methods first, then run threads until a method might have
become ready, and then repeat.
This will actually result in more mixing of threads and methods, more
context switches, and worse performance, but it makes the regressions
pass more.
Change-Id: I7cb0485e26eed79204ff2a3c3ded27b973e0b7b0
Reviewed-on: https://gem5-review.googlesource.com/c/12808
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make BindInfo into a more general purpose Port class which mirrors
sc_module and Module, sc_object and Object, etc. This tracks multiple
bindings internally, and also pending sensitivities. Keep a global
list of ports which are added in reverse order to match Accellera, and
which is iterated over to finalize binding and for phase callbacks.
This is as opposed to doing it one module at a time, and is to better
match Accellera's ordering for the regressions.
Also the sensitivity classes are now built with factory functions,
which gets around problems calling virtual functions from their
constructors or forgetting to having to have extra boilerplate each
place they're constructed.
The port class also now finalizes port or event finder sensitivities
when its binding is completed, unless it's already complete in which
case it does so immediately.
Change-Id: I1b01689715c425b94e0f68cf0271f5c1565d8c61
Reviewed-on: https://gem5-review.googlesource.com/c/12806
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Dynamic and Static sensitivities used to be represented by the same
classes, even though they're (almost) disjoint in how they worked. Also
timeouts, which can be used alongside dynamic sensitivities, were
handled by the sensitivities themselves. That meant that the
sensitivity mechanism had to mix in more types of behaviors,
increasing complexity. Also, the non-standard timed_out function
Accellera includes is harder to implement if the path for timeouts and
regular sensitivities are mixed together.
This change splits up dynamic and static sensitivities and splits out
timeouts. It also immitates the ordering Accellera uses when going
through sensitivities for an event. Static sensitivities are triggered
first in reverse order (why?), and then dynamic sensitivities are
triggered in what amounts to reverse order. To delete a sensitivity
which has been handled, it's swapped with the one in the last position,
and then the vector is truncated to drop it at the end. This has the
net effect of stirring the dynamic sensitivities, and isn't easily
immitated using a different approach, even if other approaches would
be more straightforward.
Double check addSensitivity for event.hh
Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d
Reviewed-on: https://gem5-review.googlesource.com/c/12805
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
