Re: [gem5-dev] running system C models as gem5 SimObjects

[Gabe Black]

I was wondering, are there any good system C models which can be used as
test cases to develop a system C kernel against? Ideally it would be
something simple that just exercised the various facilities models expect
without the added complexity of actually modeling anything. That might be a
good way to start making some progress with this without having to get
really deep into the spec, etc.

Gabe

On Wed, Aug 2, 2017 at 2:21 PM, Matthias Jung  wrote:

> Hey,
>
> > Am 27.07.2017 um 09:14 schrieb Andreas Hansson  >:
> >
> > 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.
>
> I see it the same way, SystemC/TLM is an IEEE standard which is widely
> used in
> industry. And therefore there would be a much larger interoperability and
> also the chance to integrate much more available models to gem5 or vice
> versa.
> I also have a large interest in pushing this further!
>
> From a TLM view, most of the components could just use the standard TLM
> methods
> like b_transport, nb_transport and debug_transport because its indeed very
> related to Atomic, Timing and Functional methods of gem5, respectively.
>
> Some modules would require paylod extensions or even additional protocol
> phases.
> But beside this the transition to TLM standard interfaces would be maybe
> easier
> than the job of switching to the SystemC kernel ;) But this would be
> required
> in order to get the PEQs working for TLM...
>
>
> Just a shameless plug for the SystemC work that we have done so far:
> http://samos-conference.com/Resources_Samos_Websites/
> Proceedings_Repository_SAMOS/2017/49_Final_Paper.pdf
>
> Regards
> Matthias
>
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] running system C models as gem5 SimObjects

[Matthias Jung]

Hey,

> Am 27.07.2017 um 09:14 schrieb Andreas Hansson :
> 
> 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.

I see it the same way, SystemC/TLM is an IEEE standard which is widely used in
industry. And therefore there would be a much larger interoperability and
also the chance to integrate much more available models to gem5 or vice versa.
I also have a large interest in pushing this further!

From a TLM view, most of the components could just use the standard TLM methods
like b_transport, nb_transport and debug_transport because its indeed very
related to Atomic, Timing and Functional methods of gem5, respectively.

Some modules would require paylod extensions or even additional protocol phases.
But beside this the transition to TLM standard interfaces would be maybe easier
than the job of switching to the SystemC kernel ;) But this would be required
in order to get the PEQs working for TLM...


Just a shameless plug for the SystemC work that we have done so far:
http://samos-conference.com/Resources_Samos_Websites/Proceedings_Repository_SAMOS/2017/49_Final_Paper.pdf

Regards
Matthias


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] running system C models as gem5 SimObjects

[Gabe Black]

I worked on a project with gem5 a while ago where I added context switching
to create something pretty similar to what I understand SC_THREADs to be
using a standard library call (I think) that I forget the name of, so that
part isn't that scary and hopefully wouldn't be too heavy weight. The book
I'm reading makes it sound like the system C scheduler is single threaded
and just switches contexts in and out on the same thread, but the code I
poked at in the gem5 tree seemed to be using pthreads, etc., which would
suggest multiple simultaneous threads. But gem5 can run multithreaded now
too, right? I think I saw some support for that in the code.

If there really is a significant performance penalty using TLM, I wonder if
their simulation kernel has similar issues? I'd be more inclined to adapt
the system C APIs to be a client of the gem5 event queue, but I'm probably
biased since I'm much more familiar with the gem5 one. I'd think either
absorbing an external system C implementation into gem5 or vice versa would
be pretty hairy from a code management perspective.

In any case, I'm glad to hear that there would be some interest if we were
to push in that direction.

Gabe

On Thu, Jul 27, 2017 at 12:14 AM, Andreas Hansson 
wrote:

> 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"
>  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
> >gem5-dev@gem5.org
> >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
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] running system C models as gem5 SimObjects

[Andreas Hansson]

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"
 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
>gem5-dev@gem5.org
>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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev