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
