Some more tests were including Accellera headers specifically, even
after including systemc.h which would bring those headers in alongside
all the others.
Change-Id: Ib2db0a410e0ecea0035b636e8dd04c85045b8578
Reviewed-on: https://gem5-review.googlesource.com/11179
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The systemc spec says that sc_bind, sc_ref and sc_cref macros should
expand to boost::bind, boost::ref, and boost::cref respectively, but
that it's "use is not mandantory". Unfortunately, the regression tests
use those macros without actually including the boost headers for
themselves, and so they won't compile without dragging in these boost
headers as a dependency.
This should be mostly ok to include here since gem5 itself shouldn't
include systemc, just the sub headers that systemc brings in. systemc
code which includes systemc *will* have a dependency on boost, but that
at least contains the new dependency somewhat.
Change-Id: I1877a1b7dae2952f30a9d577d778739abbe7ac3b
Reviewed-on: https://gem5-review.googlesource.com/11178
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The iterator class needs to have some operators, etc., defined so that
tests written against it can compile correctly. The implementations
were heavily influenced by the Accellera implementation.
Also it should be noted that the systemc spec is incorrect where it
defines these classes. When implemented like they are in the
Accellera version, the versions of bind in sc_vector_assembly which
take sc_vector<T>::iterator and iterator parameters are different, and
so they can overload each other. If implemented as described by the
spec however, those types are the same and the code won't compile.
Change-Id: I62852adf7e6c0a2f3df076ba4e93d2501859c32d
Reviewed-on: https://gem5-review.googlesource.com/11177
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_vector class is available through systemc.h already, so there's
no reason to include an internal path which is only there on Accellera
by coincidence of the implementation.
Change-Id: I41cab4711c0837cd9b20c21871b79be5165bf498
Reviewed-on: https://gem5-review.googlesource.com/11176
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The only required option for the script is the path to a build
directory, for instance build/ARM. It uses that when running scons and
when referring to generated files (like the built versions of the
tests). It uses the location of the script itself to find source files,
like the "golden" version of outputs.
This script runs tests in three phases, compilation, running, and
then verification. By default, all three phases are run for all tests,
but which phases run and how they work can be customized by specifying
them explicitly on the command line with the --phase option.
Each time the --phase option shows up on the command line, it should
be followed by the name of the phase being specified. That both
declares that that phase should be run, and also that any subsequent
options apply to that phase, at least until the next --phase option.
Currently, only the "compile" and "execute" phases are implemented, and
only the "compile" phase has been tested at all or has any options
defined. The "compile" phase simply takes all the options it was given
and pass them on to scons. The "verify" phase simply prints a message
which says what it would have verified.
The script can list the available tests with the --list option, as
determined by the json systemc test manifest file which scons can
generate, and which the script can refresh if passed the --update-json
option. You can also specify what "flavor" of build you want to do, ie
opt, debug, fast, etc., with the --flavor option. Only one flavor can
be tested at a time, but that should be the desired behavior most of
the time. If multiple flavors need to be tested, the script can be
invoked multiple times.
Finally, there is a --filter option which accepts a python expression
as a string. That expression is evaluated in the namespace of the
properties of each test in the json file, and if it returns true then
that test is run. For instance, to verify only compile_only tests, you
would use:
systemc/tests/verify.py build/ARM --filter 'compile_only'
To test only compile_only tests named bob, you would run this:
systemc/tests/verify.py build/ARM --filter \
'compile_only && name ="bob"'
Also included is a simple config.py which is the beginning of a config
which will run the systemc regression tests. Right now, all it knows
how to do is run sc_main.
Change-Id: I62666be8b1622d1355153e623b4274a939507e44
Reviewed-on: https://gem5-review.googlesource.com/10975
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Otherwise, having hundreds of statically linked gem5s takes up a huge
amount of space, and all those repeated linkings brings the mightiest
workstation to its knees with sufficient parallelism, or will take
forever without it.
Change-Id: I4c358b1a50c5e2b0027ac72423f887e24c786b19
Reviewed-on: https://gem5-review.googlesource.com/10959
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The standard says there's not supposed to be a default writer policy
for the sc_buffer template class, but in the Accellera implementation
there is, and the regression tests depend on it to compile.
Change-Id: I31d17617441224e86c56c54e45364be8f4f45b00
Reviewed-on: https://gem5-review.googlesource.com/10957
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This mechanism scans the systemc test directories as described in their
original distribution. It tells scons how to build each test
executable, and also how to build a json manifest file which
lists all the tests and some properties about them.
Change-Id: I8ebc748c1aed71f0bb76e04a2040f15abd2837d9
Reviewed-on: https://gem5-review.googlesource.com/10956
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The regression tests use this function. In the Accellera implementation
it seems to just do some error checking, so our version doesn't do
anything for now.
Change-Id: Icaad45e934bad69e301bc0234f73e69791940736
Reviewed-on: https://gem5-review.googlesource.com/10854
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The fiber will run until either sc_main returns, or until sc_start is
called. If sc_start is called, then the fiber will only be paused and
waiting for simulation cycles to be run by gem5. Once sc_pause and
sc_stop are implemented, if those are called the sc_main fiber will
be re-entered and allowed to run further towards completion.
Change-Id: I4df94f4f6fed8d49471732619a203d734d9a13a6
Reviewed-on: https://gem5-review.googlesource.com/10849
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These are the headers originally written by Accellera with a few
modifications. Most significantly, I went through and mostly (but not
entirely) manually editted them to conform to gem5 style and to be
more self consistent. Second, I resolved some macros which optionally
select features. I removed support for deprecated functions, and
otherwise enabled everything.
The actual implementation behind these headers will also be ported
over, but in a subsequent change.
Change-Id: I203d3f6c8a3af9120b946001d01defbb0643a6b6
Reviewed-on: https://gem5-review.googlesource.com/10843
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These are the header files as defined by the standard, although some
predefined channel types and most of the sc_dt namespace have yet to be
stubbed out, and so those portions are excluded.
Change-Id: Ic70f887c06e591974a4265c820eb0fdfa740d19a
Reviewed-on: https://gem5-review.googlesource.com/10838
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Most (but not all) of the SystemC headers are part of the "external"
interface that an existing, standard compliant module would include
through <systemc.h> or <systemc>. Since those follow slightly different
rules (relative includes, no gem5 includes), this change separates them
out so that they're easier to identify.
Also, this change moves the other files into a "core" subdirectory,
with the intention to add a "dt", aka data type, directory some time in
the future when those standard defined types are implemented.
Change-Id: Ida63f9cc0bc0431024d4dd691cc5b22b944a99a8
Reviewed-on: https://gem5-review.googlesource.com/10835
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
sc_main is exported as a python method on the SystemC_Kernel class and
takes a series of string arguments. The internal c++ implementation
converts those arguments into the standard argc and argv and uses them
to call the standard SystemC version of that function.
A weak SystemC version of sc_main is provided so that systemc will
compile with or without a simulation provided version of that
function. The weak version just complains and dies.
Change-Id: Iad735536c37c8bc85d06cf24779f607ae4309b8b
Reviewed-on: https://gem5-review.googlesource.com/10824
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
This class is mostly implemented as defined by the spec, except that
it doesn't maintain the module name stack (which doesn't yet exist).
Change-Id: I05fdc4aa40fb0497b0165824baee87ebf01a7821
Reviewed-on: https://gem5-review.googlesource.com/10823
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
