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
