ext: Include SystemC 2.3.1 into gem5
Review Request #3812 - Created Feb. 14, 2017 and updated
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.
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.