Hi Gabe, The similarity between TLM2 and gem5 is not accidental. We did a lot of work in 2011 and 2012 to make it that way. In fact, we even created a version of the gem5 ports that use the 4-phase TLM2 non-blocking protocol, but ended up never pushing it as it has a fairly sizeable negative performance impact (15% or so if I remember correctly). We also separated the actual protocol from the physical port, as in TLM2 (http://reviews.gem5.org/r/1301/), but ended up never pushing it, again for performance reasons. I still think it would make sense to try and align the two, but there are undoubtedly challenges.
When it comes to the simulation kernel, the problem you will run into is that SystemC supports both blocking and non-blocking modelling semantics. gem5 should be able to wrap SC_METHODS without problems, but will not be able to deal with SC_THREAD and SC_CTHREAD without the addition of some form of threading/fibres/contexts. There has been work done in the bast to add boost fibres to gem5 (we never posted this), and it is definitely doable, but the devil is in the details. Overall I strongly support aligning gem5 and SystemC further. The best outcome, in my view, would be if gem5 was transitioned to work on the SystemC kernel, allowing interoperability and more elaborate event semantics, and then also transitioned to use the TLM ports. That would be quite a work package though. Andreas On 26/07/2017, 01:53, "gem5-dev on behalf of Gabe Black" <[email protected] on behalf of [email protected]> wrote: >Hi folks. As a part of some work I'm doing, I've been considering what it >would take to run system C models inside gem5 as SimObjects. I'm working >through some reading material I have about system C, but I haven't >actually >tried writing any of it yet. This seems similar to the work that was done >to allow running gem5 as a system C model, but sort of in reverse and at a >finer granularity, ie each object as its own thing and not system C as a >large black box. > >One thing I was wondering is what sort of complications might make that >not >work out. So far, I can imagine how to adapt the system C model into gem5 >without too much fuss, but there's still a lot of pages left in the book >I'm reading and I haven't touched the actual spec yet. What was the >thinking behind putting gem5 into system C and not doing something like >what I'm thinking of? > >Another thing I'm wondering about is whether it would make sense to try to >replace gem5's port protocol with the one in system C. Obviously that >would >involve touching a lot of code, but I was surprised at how similar the >system C port setup and the gem5 one are. It might be nice generally to >use >a standardized mechanism that people might already be familiar with and >have an implementation against. That might also obviate the >bridging/adapter ports that are in the current system C/gem5 integration >mechanism. Thoughts? > >Gabe >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
