Review Board 2.0.15

ext: Include SystemC 2.3.1 into gem5

Review Request #3812 - Created Feb. 14, 2017 and updated

Matthias Jung
Changeset 11837:f68a638dd4c7
ext: Include SystemC 2.3.1 into gem5

In the past it happened several times that some changes in gem5 broke the
SystemC coupling. Recently Accelera has changed the licence for SystemC from
their own licence to Apache2.0, which is compatible with gem5. However, SystemC
usually relies on the Boost library, but I was able to exchange the boost calls
by c++11 alternatives. The recent SystemC version is placed into /ext and is
integrated into gem5's build system. The goal is to integrate some SystemC
tests for the CI in some following patches.

Posted (Feb. 26, 2017, 2:02 a.m.)

I think this is a good step in the right direction, and it has the potential of greatly enhancing the support for gem5 in SystemC environments. The only question is have is with respect to our current build process for gem5-SystemC, and how it interacts with the with/without Python build.

Could we eventually have one executable that can do both SC and non-SC, and then only leave the with/without Python as an option? What combinations actually make sense, and what is the overhead if we were to always include SC?

I think having "one executable to rule them all" would also help tremendously with testing, but perhaps there are other ways of keeping this working.

On a separate note, I think it would be really interesting if someone skilled in the arts could take a stab at moving gem5 to use the SystemC event kernel. This would enable a more elaborate set of tools and modelling paradirms, including SC_THREAD/SC_CTHREAD style concepts that work very well for state machines. Clearly this is off topic for the patch, but I am keen to know if anyone has already progress this train of thought, or would be keen to discuss the options.