| Age | Commit message (Collapse) | Author |
|---|
|
This class is supposed to be a more efficient way to manage small bits
of memory. At least for now, new and delete will do the same job
functionally. Also, the heap manager may be just as efficient as
whatever custom mechanism sc_mempool would use.
Change-Id: I6fdc01a69ca017d94b14a15a196ad29b66ef9858
Reviewed-on: https://gem5-review.googlesource.com/c/13292
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>
|
|
These match error checks which are already in, for instance, the
sc_port constructor.
Change-Id: I8dfb4ce37bf0e59c6fa879f0afda5112af78b40b
Reviewed-on: https://gem5-review.googlesource.com/c/13290
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>
|
|
This destructor just removes the port from the list of all ports.
Change-Id: I809b529540c2946d20aeb8d64467d77dc94a7a96
Reviewed-on: https://gem5-review.googlesource.com/c/13288
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>
|
|
This function checks the top level collection of events and objects
to find if one with a particular name exists.
Change-Id: Icf539b502fa9c7401be907ee975eb24a47e79a87
Reviewed-on: https://gem5-review.googlesource.com/c/13206
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Iec4e0bd504e70d0096a4c90d5fbba9565dd0deed
Reviewed-on: https://gem5-review.googlesource.com/c/13205
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This typo was added purposefully to match Accellera's output, but then
it was discovered that some test's golden output had the typo, and some
didn't. That must mean that not all tests have up to date output, and
that Accellera couldn't possibly pass all of their own tests.
To resolve this conflict, this change fixes the typo and manually
updates all the golden output.
Change-Id: I3d80f74ff21e844609e7bde5dfcd99fc56c085b0
Reviewed-on: https://gem5-review.googlesource.com/c/13204
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This includes the nonstandard SC_NO_WRITE_CHECK #define which the
Accellera tests use and depend on.
Change-Id: I106c4c16160325725a00d5c337047251817dca32
Reviewed-on: https://gem5-review.googlesource.com/c/13203
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The two different processes we have to use to match Accellera behavior
would trip the checks in write.
Change-Id: Iee729b239bccd8f7b854894000c9ef2c47600563
Reviewed-on: https://gem5-review.googlesource.com/c/13202
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>
|
|
Something the Accellera implementation does which would be good to do
in the gem5 implementation is to create a base class for sc_signal
which isn't templated, and which holds the common/non-type specific
versions of the various sc_signal methods. This will reduce code
redundancy and binary size, and also let us hide more code in .cc
files so that it's less likely we'd need to recompile model code to
fix a bug.
Also, since this all uses of sc_channel_warn_unimple have now been
eliminated, remove that function.
Change-Id: Ia574647c034e7136093c2047b69de725ac34f52f
Reviewed-on: https://gem5-review.googlesource.com/c/13200
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>
|
|
The calls to sc_channel_warn_unimpl have been removed, so the includes
aren't needed.
Change-Id: I58a916a7c4ef9a266be591789696457799b6b8dd
Reviewed-on: https://gem5-review.googlesource.com/c/13198
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I3cf096c4432fdf310fa1279da32620d5c9f57b5d
Reviewed-on: https://gem5-review.googlesource.com/c/13197
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>
|
|
The assumption was that a port wouldn't have any interfaces until
after elaboration, and that if it would be traced, it would have
interfaces. Checking if the simulation has started (and hence
elaboration has finished) is a more accurate and direct way to check
the same thing.
Change-Id: I7fe9ecea469997d1a257dd3e4a0db31889aff722
Reviewed-on: https://gem5-review.googlesource.com/c/13195
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>
|
|
Change-Id: Ifbc27a3134730a95ecdb79c588c4d7fe6e889046
Reviewed-on: https://gem5-review.googlesource.com/c/13192
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>
|
|
Change-Id: Ie0c29bb6cf918aea1c0bc719b9d37628b5b19339
Reviewed-on: https://gem5-review.googlesource.com/c/13185
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I58fd72b8c64ee82eb478d810f7114bab7a31cbfa
Reviewed-on: https://gem5-review.googlesource.com/c/13184
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>
|
|
The spec says that the default timescale should be 1 PS, but the
Accellera implementation uses the time resolution.
Change-Id: I7b307a33ef0856e9c19d81e401b15691275d4978
Reviewed-on: https://gem5-review.googlesource.com/c/12975
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 implementation is fairly trivial, but the pieces it relies on
weren't always available.
Change-Id: Ie77168ff336febd3ebe22c400f2b1f133e43aca7
Reviewed-on: https://gem5-review.googlesource.com/c/12973
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This matches Accellera's output for the tests.
Change-Id: Ie67fd673a980b8ca2fdcd8f357ff7993a9091221
Reviewed-on: https://gem5-review.googlesource.com/c/12972
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ic88c6834dfe980022e58a3d859ea53193a55bbb1
Reviewed-on: https://gem5-review.googlesource.com/c/12971
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>
|
|
In the Accellera implementation, every time a delta cycle is traced a
check is done to see if the user has been told what the pseudo timestep
is. To avoid doing that check over and over, we'll leave that out and
tell the verify.py to ignore that message in the reference output.
Change-Id: I825f05394dccf03e951d29561a11c3cc6d4bcda7
Reviewed-on: https://gem5-review.googlesource.com/c/12969
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Method processes aren't allowed in an sc_join.
Change-Id: I5c8421a396dbe261645a074df514f69fc652c9c8
Reviewed-on: https://gem5-review.googlesource.com/c/12968
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That function is only allowed when running a thread or cthread.
Change-Id: Idf98b70018169d4f724aa8168f3c4e8161f0b83d
Reviewed-on: https://gem5-review.googlesource.com/c/12967
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie525a1624a6496a51277fb984cbfeec21eb79749
Reviewed-on: https://gem5-review.googlesource.com/c/12966
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ib0c14a5c7dad37b33d61c9b406f6b84121d94e46
Reviewed-on: https://gem5-review.googlesource.com/c/12965
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This doesn't include WIF trace support, but does make allowances for
adding it in the future.
Change-Id: Ifb62f40a7d8a13e94463930a44ac4b1cf41e3009
Reviewed-on: https://gem5-review.googlesource.com/c/12826
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If we're already going to process the thing we'd be scheduling it to
process, just let the existing invocation get to it.
Change-Id: Ifeebc80903065567fc0eed02beefec6156b22ff7
Reviewed-on: https://gem5-review.googlesource.com/c/12964
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>
|
|
The reference output skips the first 7 lines which have volatile info
like the current time.
Change-Id: I9c173ff3903982a07349ca6957ab25e07bdf8e54
Reviewed-on: https://gem5-review.googlesource.com/c/12824
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These were all set to 8 * sizeof(char) instead of using the size of the
actual data type being traced.
Also add a very simple implementation to the generic sc_signal_in_if<T>
sc_trace which just delegates to the sc_trace of the underlying type T.
Change-Id: I129df46ef9d49705dc3dac76e30c0a3652c981eb
Reviewed-on: https://gem5-review.googlesource.com/c/12818
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In the generic (non-console output) output checker, a variable should
have been called self.test, but was called self.text.
Change-Id: I2518d6ff01c51fc195eef2b61e987d1b3104c89b
Reviewed-on: https://gem5-review.googlesource.com/c/12817
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I06e3484176c0c06daa28f7be0ed8437b3b15ddb2
Reviewed-on: https://gem5-review.googlesource.com/c/12816
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I19c5e6f1795c2777dbe7d210cfa01f6ced2020f3
Reviewed-on: https://gem5-review.googlesource.com/c/12815
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is different from the message the Accellera implementation would
print, so it looks like it wouldn't pass this test as is.
Change-Id: I0286fd3e3df7bc3e87f38c35086a32d8dec0bcc9
Reviewed-on: https://gem5-review.googlesource.com/c/12814
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
