Hi Gabe, I totally agree with you. SytemC is a standard and the code maintained by accellera is just an „example“ of how SystemC could be implemented.
However, that is part of my argument. If I want to use e.g. another fancy SystemC kernel (e.g. https://dl.acm.org/citation.cfm?id=2987374) or a commercial one like the one in the Synopsys toolchains, I cannot use gem5 (beside the coupling that is already there, which has also several drawbacks). So I like more the separation of simulation models and the kernel. But I also understand it from your side. In Google you don’t have this specific need and you want to find quickly a solution with less effort. Anyway we should discuss if a full switch to SystemC as a kernel might be a reasonable long term goal. I think many people would benefit from that. I’m also keen to know Christian’s, Andreas’ and Jason’s opinions. It’s a pitty that gem5 and SystemC started back at the same time and evolved separately... Best, Matthias > Am 09.06.2018 um 02:34 schrieb Gabe Black <gabebl...@google.com>: > > Also, I should point out that the systemc standard defines a set of > mechanisms and an interface, not an implementation. The Accellera version > of systemc is *not* the standard, it's just an implementation (a very > common and important one) of that standard. It's dangerous to conflate > those two ideas, and it leads to a lot of problems for everybody. > > Gabe > > On Fri, Jun 8, 2018 at 12:50 PM Gabe Black <gabebl...@google.com> wrote: > >> Giacomo, if you're proposing linking in the systemc library and then >> adding wrappers to somehow plug that into gem5's underlying mechanisms, I'm >> not sure that's technically feasible since the existing implementation >> isn't intended to be built on top of something else. Also a lot of the >> mechanisms are built into base classes, and so if you change what data >> members are in the base classes, ie the internal implementation, you break >> existing binaries. There isn't much a wrapper can do in that case. >> >> If you're proposing rebuilding gem5 on top of systemc, there are a variety >> of reasons I'm not proposing that which I've gone through exhaustively (at >> least I feel exhausted from it) in other places (you didn't miss it, that >> was internally at Google). >> >> This approach addresses best addresses the problem we (Google) are trying >> to solve, which is to leverage existing models vendors may have developed >> already in systemc, or which may be developed primarily in systemc in the >> future. Rather than ask them to rewrite their models as gem5 models, >> simultaneously develop two models, one for systemc and one for gem5, or to >> architect their model as a core with two interface layers, one for each >> system, any of which may be prohibitive from an engineering effort >> perspective, this way they can write a systemc model (or take one they >> already wrote) and then just recompile it with a different systemc header >> and use it directly as a model within gem5. >> >> There will be very little modification to gem5 proper for this, and so if >> this sort of integration doesn't do what you want you can just ignore it or >> even turn it off and not suffer any overhead, and then use whatever other >> mechanism you like. >> >> Matthias, while being able to use closed source models would be nice, it >> isn't the problem we're trying to solve, and reimplementing gem5 on top of >> systemc would be a lot more work that doesn't really gain us anything. >> >> Jason, thanks. Please start with that python CL if you have a chance since >> I think it's about ready to go in, Andreas just wanted you to ack it before >> checking it in. >> >> Gabe >> >> >> On Fri, Jun 8, 2018 at 7:15 AM Jason Lowe-Power <ja...@lowepower.com> >> wrote: >> >>> I'll have some time next week to dig into this. >>> >>> Cheers, >>> Jason >>> >>> On Fri, Jun 8, 2018, 7:13 AM Dr.-Ing. Matthias Jung <jun...@eit.uni-kl.de >>>> >>> wrote: >>> >>>> Hi Giacomo, Gabe, >>>> >>>> I'm a large supporter of SystemC because its 'the' IEEE standard for >>>> simulation, therefore I support always activities towards that >>> direction. >>>> However I have a similar concern like Giacomo. >>>> >>>> I would prefer to just 'use' the SystemC kernel by accellera as kernel >>> for >>>> gem5 in order to have a proper separation between model and kernel. I >>> think >>>> its very interesting for many people to use gem5 in their SystemC >>>> environment also together with commercial IP SystemC models that have a >>>> closed source. With the current aimed approach it would be required to >>> have >>>> access to the source code of all used models in the system and >>> commercial >>>> SystemC tools like Synopsys Platform Architect etc. could not be used. >>>> >>>> >>>> Best, >>>> Matthias >>>> >>>> 8. Juni 2018 15:47, "Giacomo Travaglini" <giacomo.travagl...@arm.com> >>>> schrieb: >>>> >>>>> Hi Gabe, >>>>> >>>>> I have had a quick glance at the patches and there's one thing I don't >>>> understand: >>>>> >>>>> It seems to me that you are sort of reimplementing the SystemC runtime >>>> kernel inside >>>>> >>>>> gem5 for scratch. >>>>> >>>>> Is there a reason for doing it? Can't we just link to the external >>>> SystemC library >>>>> >>>>> and just write some wrappers? >>>>> >>>>> Thanks in advance for the clarifications >>>>> >>>>> Giacomo >>>>> >>>>> ________________________________ >>>>> From: gem5-dev <gem5-dev-boun...@gem5.org> on behalf of Gabe Black < >>>> gabebl...@google.com> >>>>> Sent: 08 June 2018 06:32:52 >>>>> To: gem5 Developer List >>>>> Subject: [gem5-dev] systemc reviews >>>>> >>>>> Hi folks. I've posted a lot of systemc reviews recently, and I expect >>> to >>>>> keep doing so for the foreseeable future. To keep the pool of pending >>> CLs >>>>> from growing from a lot to unmanageably a lot please don't let them >>> sit >>>> too >>>>> long if you feel comfortable trying to review them. Alot of these >>> earlier >>>>> ones aren't very interesting, they're just defining header files, >>> stubbed >>>>> out implementations, or importing code from the Accellera version of >>>>> SystemC. There are a few that are a little more interesting though, to >>>> keep >>>>> you from getting bored ;-) >>>>> >>>>> 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 >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ > 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
