Re: [gem5-dev] systemc reviews
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 on behalf of Gabe Black 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
Re: [gem5-dev] systemc reviews
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" 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 on behalf of Gabe Black > > 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
Re: [gem5-dev] systemc reviews
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 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" > 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 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
Re: [gem5-dev] systemc reviews
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 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 > 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" > > 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 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. > > >
Re: [gem5-dev] systemc reviews
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 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 > 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 > > >> 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" >> > 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 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
Re: [gem5-dev] systemc reviews
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 : > > 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 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 >> 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 >>> >>> 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" 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 Sy
Re: [gem5-dev] systemc reviews
Hi, I am following the discussion for a while now and finally found the time to look at Gabe's proposal. As I see it, there are three approaches for combining gem5 and SystemC as outlined below. (Sorry for repeating stuff that was mentioned before, I just find it helpful to summarize some points) 1. Bridging gem5 ans Systemc. This is the approach I and Matthias implemented and presented last year. It provides bridges between the gem5 and SystemC communication interfaces, as well as a wrapper SystemC module that hosts a complete gem5 simulation on top of the SystemC kernel. While this approach certainly has limitations, it allows to combine gem5 and SystemC models. 2. Implementing the SystemC standard using gem5 This is the approach proposed by Gabe which, as I understand it, provides a wrapper around gem5 implementing the SystemC standard. With this approach, gem5 becomes a fully fledged SystemC kernel which arbitrary standard compliant SystemC models can run on. Compared to approach 1, this allows for more interaction between both domains, as everything can be compiled in a single pass and there is not just one single point of interaction. However, this approach prevents certain use cases, e.g. where SystemC models are closed source or where a specific SystemC implementation is required. 3. Replacing the gem5 simulation kernel by SystemC. This is the most radical approach but also gives most flexibility. It replaces the entire gem5 simulation kernel by SystemC. In this approach, gem5 could be seen as a system modeling framework and as an abstraction layer on top of SystemC. This would give maximum flexibility as arbitrary SystemC and gem5 models can be combined and even the SystemC kernel can be exchanged arbitrarily. However, it is not clear (at least to me) how exactly gem5 and SystemC modules could be connected and interact with each other. I think for this approach to work, aspects of approach 1 or/and 2 are still required. So as I see it: 3 covers more use cases than 2 but both are in a way superior to the existing approach (1). However, in order to implement 3 a lot of changes to the code base are required. Implementing these changes will take some time, so there will probably be two versions of gem5: a legacy one and the SystemC one. This again produces more work in maintaining the code base. Now I wonder: who is willing to do all this work? While I favour approach 3 for its benefits and the points Matthias made, I still like Gabe's idea very much. It minimizes the changes required to the existing code base while providing many benefits to a broader community. As Gabe mentioned before, his approach neither breaks with the existing bridges implemented by me and Matthias, nor does it prevent implementation of approach 3 in the future. To sum it up: there are no objections from my side. Unfortunately, I am not very active in hardware modeling anymore, but I am very interested in this development and I hope to find the time to have a look on the patches soon. Best, Christian Matthias Jung writes: > 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 : >> >> 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 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 clas
Re: [gem5-dev] systemc reviews
Hi Christian, I think you summarised the 3 approaches very well. I mean, we have approach 1 already. It makes sense if Gabe drives approach 2 because it has many advantages compared to approach 1. I think we could see approach 3 as a longterm goal and we should go for approach 2 for now. Thanks for all the opinions so far, Best, Matthias > Am 11.06.2018 um 18:02 schrieb Christian Menard > : > > Hi, > > I am following the discussion for a while now and finally found the time > to look at Gabe's proposal. > > As I see it, there are three approaches for combining gem5 and SystemC > as outlined below. (Sorry for repeating stuff that was mentioned before, > I just find it helpful to summarize some points) > > 1. Bridging gem5 ans Systemc. > This is the approach I and Matthias implemented and presented last > year. It provides bridges between the gem5 and SystemC communication > interfaces, as well as a wrapper SystemC module that hosts a complete > gem5 simulation on top of the SystemC kernel. While this approach > certainly has limitations, it allows to combine gem5 and SystemC models. > > 2. Implementing the SystemC standard using gem5 > This is the approach proposed by Gabe which, as I understand it, > provides a wrapper around gem5 implementing the SystemC standard. With > this approach, gem5 becomes a fully fledged SystemC kernel which > arbitrary standard compliant SystemC models can run on. Compared to > approach 1, this allows for more interaction between both domains, as > everything can be compiled in a single pass and there is not just one > single point of interaction. However, this approach prevents certain use > cases, e.g. where SystemC models are closed source or where a specific > SystemC implementation is required. > > 3. Replacing the gem5 simulation kernel by SystemC. > This is the most radical approach but also gives most flexibility. It > replaces the entire gem5 simulation kernel by SystemC. In this approach, > gem5 could be seen as a system modeling framework and as an abstraction > layer on top of SystemC. This would give maximum flexibility as > arbitrary SystemC and gem5 models can be combined and even the SystemC > kernel can be exchanged arbitrarily. However, it is not clear (at least > to me) how exactly gem5 and SystemC modules could be connected and > interact with each other. I think for this approach to work, aspects of > approach 1 or/and 2 are still required. > > So as I see it: 3 covers more use cases than 2 but both are in a way > superior to the existing approach (1). However, in order to implement 3 > a lot of changes to the code base are required. Implementing these > changes will take some time, so there will probably be two versions of > gem5: a legacy one and the SystemC one. This again produces more work in > maintaining the code base. Now I wonder: who is willing to do all this > work? > > While I favour approach 3 for its benefits and the points Matthias made, > I still like Gabe's idea very much. It minimizes the changes required to > the existing code base while providing many benefits to a broader > community. As Gabe mentioned before, his approach neither breaks with > the existing bridges implemented by me and Matthias, nor does it prevent > implementation of approach 3 in the future. To sum it up: there are no > objections from my side. > > Unfortunately, I am not very active in hardware modeling anymore, but I > am very interested in this development and I hope to find the time to > have a look on the patches soon. > > Best, > > Christian > > Matthias Jung writes: > >> 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 : >>> >>> 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 dangero
Re: [gem5-dev] systemc reviews
Ok great, glad to hear it. Gabe On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung wrote: > Hi Christian, > > I think you summarised the 3 approaches very well. I mean, we have > approach 1 already. It makes sense if Gabe drives approach 2 because > it has many advantages compared to approach 1. I think we could see > approach 3 as a longterm goal and we should go for approach 2 for now. > > Thanks for all the opinions so far, > Best, > Matthias > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < > christian.men...@tu-dresden.de>: > > > > Hi, > > > > I am following the discussion for a while now and finally found the time > > to look at Gabe's proposal. > > > > As I see it, there are three approaches for combining gem5 and SystemC > > as outlined below. (Sorry for repeating stuff that was mentioned before, > > I just find it helpful to summarize some points) > > > > 1. Bridging gem5 ans Systemc. > > This is the approach I and Matthias implemented and presented last > > year. It provides bridges between the gem5 and SystemC communication > > interfaces, as well as a wrapper SystemC module that hosts a complete > > gem5 simulation on top of the SystemC kernel. While this approach > > certainly has limitations, it allows to combine gem5 and SystemC models. > > > > 2. Implementing the SystemC standard using gem5 > > This is the approach proposed by Gabe which, as I understand it, > > provides a wrapper around gem5 implementing the SystemC standard. With > > this approach, gem5 becomes a fully fledged SystemC kernel which > > arbitrary standard compliant SystemC models can run on. Compared to > > approach 1, this allows for more interaction between both domains, as > > everything can be compiled in a single pass and there is not just one > > single point of interaction. However, this approach prevents certain use > > cases, e.g. where SystemC models are closed source or where a specific > > SystemC implementation is required. > > > > 3. Replacing the gem5 simulation kernel by SystemC. > > This is the most radical approach but also gives most flexibility. It > > replaces the entire gem5 simulation kernel by SystemC. In this approach, > > gem5 could be seen as a system modeling framework and as an abstraction > > layer on top of SystemC. This would give maximum flexibility as > > arbitrary SystemC and gem5 models can be combined and even the SystemC > > kernel can be exchanged arbitrarily. However, it is not clear (at least > > to me) how exactly gem5 and SystemC modules could be connected and > > interact with each other. I think for this approach to work, aspects of > > approach 1 or/and 2 are still required. > > > > So as I see it: 3 covers more use cases than 2 but both are in a way > > superior to the existing approach (1). However, in order to implement 3 > > a lot of changes to the code base are required. Implementing these > > changes will take some time, so there will probably be two versions of > > gem5: a legacy one and the SystemC one. This again produces more work in > > maintaining the code base. Now I wonder: who is willing to do all this > > work? > > > > While I favour approach 3 for its benefits and the points Matthias made, > > I still like Gabe's idea very much. It minimizes the changes required to > > the existing code base while providing many benefits to a broader > > community. As Gabe mentioned before, his approach neither breaks with > > the existing bridges implemented by me and Matthias, nor does it prevent > > implementation of approach 3 in the future. To sum it up: there are no > > objections from my side. > > > > Unfortunately, I am not very active in hardware modeling anymore, but I > > am very interested in this development and I hope to find the time to > > have a look on the patches soon. > > > > Best, > > > > Christian > > > > Matthias Jung writes: > > > >> 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 schri
Re: [gem5-dev] systemc reviews
Hey Gabe, So, I've finally starting going through all of the patches (as you could see). One thing that I don't want to write on every single patch is "add comments", but I really think that the header files should have doxygen comments on everything. Is it possible to copy them over from the Accellera implementation? Another general documentation thing is that at some point it would be good to put at least a short README in the systemc directory. I'm sure you're planning to write extensive documentation on the wiki ;), but it would also be a good idea to have something brief the code for those people who don't want to leave the command line. Finally, for everyone else that's reviewing: I find it hard to review big changes like this on gerrit since you only see one change at a time and you can't see what the "end result" is. However, if you go to the last commit ( https://gem5-review.googlesource.com/c/public/gem5/+/10975/1) and click on the sha hash of the commit it lead you to this page ( https://gem5.googlesource.com/public/gem5/+/ebd453d32fe1abcf1fb1a047dbcd6151558a117e) which will show you the "final" code after all of the patches are applied. Hopefully this can save someone some time! Cheers, Jason PS: I don't know much about SystemC. I've been learning a little trying to review Gabe's changes... I have a general question: what are the tradeoffs compared to gem5? Specifically, is there *anything* that's better about gem5? This is a much larger conversation, but the suggestion of replacing gem5's simulation engine with SystemC is intriguing (and scary...). On Mon, Jun 11, 2018 at 7:19 PM Gabe Black wrote: > Ok great, glad to hear it. > > Gabe > > On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung > wrote: > > > Hi Christian, > > > > I think you summarised the 3 approaches very well. I mean, we have > > approach 1 already. It makes sense if Gabe drives approach 2 because > > it has many advantages compared to approach 1. I think we could see > > approach 3 as a longterm goal and we should go for approach 2 for now. > > > > Thanks for all the opinions so far, > > Best, > > Matthias > > > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < > > christian.men...@tu-dresden.de>: > > > > > > Hi, > > > > > > I am following the discussion for a while now and finally found the > time > > > to look at Gabe's proposal. > > > > > > As I see it, there are three approaches for combining gem5 and SystemC > > > as outlined below. (Sorry for repeating stuff that was mentioned > before, > > > I just find it helpful to summarize some points) > > > > > > 1. Bridging gem5 ans Systemc. > > > This is the approach I and Matthias implemented and presented last > > > year. It provides bridges between the gem5 and SystemC communication > > > interfaces, as well as a wrapper SystemC module that hosts a complete > > > gem5 simulation on top of the SystemC kernel. While this approach > > > certainly has limitations, it allows to combine gem5 and SystemC > models. > > > > > > 2. Implementing the SystemC standard using gem5 > > > This is the approach proposed by Gabe which, as I understand it, > > > provides a wrapper around gem5 implementing the SystemC standard. With > > > this approach, gem5 becomes a fully fledged SystemC kernel which > > > arbitrary standard compliant SystemC models can run on. Compared to > > > approach 1, this allows for more interaction between both domains, as > > > everything can be compiled in a single pass and there is not just one > > > single point of interaction. However, this approach prevents certain > use > > > cases, e.g. where SystemC models are closed source or where a specific > > > SystemC implementation is required. > > > > > > 3. Replacing the gem5 simulation kernel by SystemC. > > > This is the most radical approach but also gives most flexibility. It > > > replaces the entire gem5 simulation kernel by SystemC. In this > approach, > > > gem5 could be seen as a system modeling framework and as an abstraction > > > layer on top of SystemC. This would give maximum flexibility as > > > arbitrary SystemC and gem5 models can be combined and even the SystemC > > > kernel can be exchanged arbitrarily. However, it is not clear (at least > > > to me) how exactly gem5 and SystemC modules could be connected and > > > interact with each other. I think for this approach to work, aspects of > > > approach 1 or/and 2 are still required. > > > > > > So as I see it: 3 covers more use cases than 2 but both are in a way > > > superior to the existing approach (1). However, in order to implement 3 > > > a lot of changes to the code base are required. Implementing these > > > changes will take some time, so there will probably be two versions of > > > gem5: a legacy one and the SystemC one. This again produces more work > in > > > maintaining the code base. Now I wonder: who is willing to do all this > > > work? > > > > > > While I favour approach 3 for its benefits and the points Matthias > made, > > > I s
Re: [gem5-dev] systemc reviews
Hey Jason, thanks for taking a look. As far as comments go, there aren't really that many comments in the Accellera implementation either, at least not doxygen style, per function args, ret style comments. I think for things which are defined in the spec and/or in systemc books, tutorials, etc., those comments are really that necessary since the APIs are already fairly extensively documented elsewhere, and in a better more usable form than comments in the headers. When it comes to the stuff that isn't in the spec, like the guts of the implementation that make all those parts work, then comments make a lot of sense since there isn't an already existing and superior form of documentation out there. So in short, I don't intend to document systemc itself since that's already been extensively done elsewhere, but I do intend to document the difference in the gem5 flavor, and the internals. Gabe On Thu, Jun 14, 2018 at 6:19 PM Jason Lowe-Power wrote: > Hey Gabe, > > So, I've finally starting going through all of the patches (as you could > see). One thing that I don't want to write on every single patch is "add > comments", but I really think that the header files should have doxygen > comments on everything. Is it possible to copy them over from the Accellera > implementation? > > Another general documentation thing is that at some point it would be good > to put at least a short README in the systemc directory. I'm sure you're > planning to write extensive documentation on the wiki ;), but it would also > be a good idea to have something brief the code for those people who don't > want to leave the command line. > > Finally, for everyone else that's reviewing: I find it hard to review big > changes like this on gerrit since you only see one change at a time and you > can't see what the "end result" is. However, if you go to the last commit ( > https://gem5-review.googlesource.com/c/public/gem5/+/10975/1) and click on > the sha hash of the commit it lead you to this page ( > > https://gem5.googlesource.com/public/gem5/+/ebd453d32fe1abcf1fb1a047dbcd6151558a117e > ) > which will show you the "final" code after all of the patches are applied. > Hopefully this can save someone some time! > > Cheers, > Jason > > PS: I don't know much about SystemC. I've been learning a little trying to > review Gabe's changes... I have a general question: what are the tradeoffs > compared to gem5? Specifically, is there *anything* that's better about > gem5? This is a much larger conversation, but the suggestion of replacing > gem5's simulation engine with SystemC is intriguing (and scary...). > > On Mon, Jun 11, 2018 at 7:19 PM Gabe Black wrote: > > > Ok great, glad to hear it. > > > > Gabe > > > > On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung > > wrote: > > > > > Hi Christian, > > > > > > I think you summarised the 3 approaches very well. I mean, we have > > > approach 1 already. It makes sense if Gabe drives approach 2 because > > > it has many advantages compared to approach 1. I think we could see > > > approach 3 as a longterm goal and we should go for approach 2 for now. > > > > > > Thanks for all the opinions so far, > > > Best, > > > Matthias > > > > > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < > > > christian.men...@tu-dresden.de>: > > > > > > > > Hi, > > > > > > > > I am following the discussion for a while now and finally found the > > time > > > > to look at Gabe's proposal. > > > > > > > > As I see it, there are three approaches for combining gem5 and > SystemC > > > > as outlined below. (Sorry for repeating stuff that was mentioned > > before, > > > > I just find it helpful to summarize some points) > > > > > > > > 1. Bridging gem5 ans Systemc. > > > > This is the approach I and Matthias implemented and presented last > > > > year. It provides bridges between the gem5 and SystemC communication > > > > interfaces, as well as a wrapper SystemC module that hosts a complete > > > > gem5 simulation on top of the SystemC kernel. While this approach > > > > certainly has limitations, it allows to combine gem5 and SystemC > > models. > > > > > > > > 2. Implementing the SystemC standard using gem5 > > > > This is the approach proposed by Gabe which, as I understand it, > > > > provides a wrapper around gem5 implementing the SystemC standard. > With > > > > this approach, gem5 becomes a fully fledged SystemC kernel which > > > > arbitrary standard compliant SystemC models can run on. Compared to > > > > approach 1, this allows for more interaction between both domains, as > > > > everything can be compiled in a single pass and there is not just one > > > > single point of interaction. However, this approach prevents certain > > use > > > > cases, e.g. where SystemC models are closed source or where a > specific > > > > SystemC implementation is required. > > > > > > > > 3. Replacing the gem5 simulation kernel by SystemC. > > > > This is the most radical approach but also gives most flexibility. It > > > > repla
Re: [gem5-dev] systemc reviews
Oh, by the way, I've been adding Andreas, Jason and Matthias Jung to all the systemc reviews I've been posting. I think those folks should definitely be in the loop, but I don't want to exclude anybody else. If you also want to be on all the reviews, please let me know. I don't want to unilaterally bomb people's inboxes if they're not interested. Gabe On Fri, Jun 15, 2018 at 1:35 AM Gabe Black wrote: > Hey Jason, thanks for taking a look. As far as comments go, there aren't > really that many comments in the Accellera implementation either, at least > not doxygen style, per function args, ret style comments. I think for > things which are defined in the spec and/or in systemc books, tutorials, > etc., those comments are really that necessary since the APIs are already > fairly extensively documented elsewhere, and in a better more usable form > than comments in the headers. When it comes to the stuff that isn't in the > spec, like the guts of the implementation that make all those parts work, > then comments make a lot of sense since there isn't an already existing and > superior form of documentation out there. > > So in short, I don't intend to document systemc itself since that's > already been extensively done elsewhere, but I do intend to document the > difference in the gem5 flavor, and the internals. > > Gabe > > On Thu, Jun 14, 2018 at 6:19 PM Jason Lowe-Power > wrote: > >> Hey Gabe, >> >> So, I've finally starting going through all of the patches (as you could >> see). One thing that I don't want to write on every single patch is "add >> comments", but I really think that the header files should have doxygen >> comments on everything. Is it possible to copy them over from the >> Accellera >> implementation? >> >> Another general documentation thing is that at some point it would be good >> to put at least a short README in the systemc directory. I'm sure you're >> planning to write extensive documentation on the wiki ;), but it would >> also >> be a good idea to have something brief the code for those people who don't >> want to leave the command line. >> >> Finally, for everyone else that's reviewing: I find it hard to review big >> changes like this on gerrit since you only see one change at a time and >> you >> can't see what the "end result" is. However, if you go to the last commit >> ( >> https://gem5-review.googlesource.com/c/public/gem5/+/10975/1) and click >> on >> the sha hash of the commit it lead you to this page ( >> >> https://gem5.googlesource.com/public/gem5/+/ebd453d32fe1abcf1fb1a047dbcd6151558a117e >> ) >> which will show you the "final" code after all of the patches are applied. >> Hopefully this can save someone some time! >> >> Cheers, >> Jason >> >> PS: I don't know much about SystemC. I've been learning a little trying to >> review Gabe's changes... I have a general question: what are the tradeoffs >> compared to gem5? Specifically, is there *anything* that's better about >> gem5? This is a much larger conversation, but the suggestion of replacing >> gem5's simulation engine with SystemC is intriguing (and scary...). >> >> On Mon, Jun 11, 2018 at 7:19 PM Gabe Black wrote: >> >> > Ok great, glad to hear it. >> > >> > Gabe >> > >> > On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung >> > wrote: >> > >> > > Hi Christian, >> > > >> > > I think you summarised the 3 approaches very well. I mean, we have >> > > approach 1 already. It makes sense if Gabe drives approach 2 because >> > > it has many advantages compared to approach 1. I think we could see >> > > approach 3 as a longterm goal and we should go for approach 2 for now. >> > > >> > > Thanks for all the opinions so far, >> > > Best, >> > > Matthias >> > > >> > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < >> > > christian.men...@tu-dresden.de>: >> > > > >> > > > Hi, >> > > > >> > > > I am following the discussion for a while now and finally found the >> > time >> > > > to look at Gabe's proposal. >> > > > >> > > > As I see it, there are three approaches for combining gem5 and >> SystemC >> > > > as outlined below. (Sorry for repeating stuff that was mentioned >> > before, >> > > > I just find it helpful to summarize some points) >> > > > >> > > > 1. Bridging gem5 ans Systemc. >> > > > This is the approach I and Matthias implemented and presented last >> > > > year. It provides bridges between the gem5 and SystemC communication >> > > > interfaces, as well as a wrapper SystemC module that hosts a >> complete >> > > > gem5 simulation on top of the SystemC kernel. While this approach >> > > > certainly has limitations, it allows to combine gem5 and SystemC >> > models. >> > > > >> > > > 2. Implementing the SystemC standard using gem5 >> > > > This is the approach proposed by Gabe which, as I understand it, >> > > > provides a wrapper around gem5 implementing the SystemC standard. >> With >> > > > this approach, gem5 becomes a fully fledged SystemC kernel which >> > > > arbitrary standard compliant SystemC models can
Re: [gem5-dev] systemc reviews
Hi Gabe, please consider myself interested on reviewing SystemC patches ?? From: gem5-dev on behalf of Gabe Black Sent: 15 June 2018 09:55:30 To: gem5 Developer List Subject: Re: [gem5-dev] systemc reviews Oh, by the way, I've been adding Andreas, Jason and Matthias Jung to all the systemc reviews I've been posting. I think those folks should definitely be in the loop, but I don't want to exclude anybody else. If you also want to be on all the reviews, please let me know. I don't want to unilaterally bomb people's inboxes if they're not interested. Gabe On Fri, Jun 15, 2018 at 1:35 AM Gabe Black wrote: > Hey Jason, thanks for taking a look. As far as comments go, there aren't > really that many comments in the Accellera implementation either, at least > not doxygen style, per function args, ret style comments. I think for > things which are defined in the spec and/or in systemc books, tutorials, > etc., those comments are really that necessary since the APIs are already > fairly extensively documented elsewhere, and in a better more usable form > than comments in the headers. When it comes to the stuff that isn't in the > spec, like the guts of the implementation that make all those parts work, > then comments make a lot of sense since there isn't an already existing and > superior form of documentation out there. > > So in short, I don't intend to document systemc itself since that's > already been extensively done elsewhere, but I do intend to document the > difference in the gem5 flavor, and the internals. > > Gabe > > On Thu, Jun 14, 2018 at 6:19 PM Jason Lowe-Power > wrote: > >> Hey Gabe, >> >> So, I've finally starting going through all of the patches (as you could >> see). One thing that I don't want to write on every single patch is "add >> comments", but I really think that the header files should have doxygen >> comments on everything. Is it possible to copy them over from the >> Accellera >> implementation? >> >> Another general documentation thing is that at some point it would be good >> to put at least a short README in the systemc directory. I'm sure you're >> planning to write extensive documentation on the wiki ;), but it would >> also >> be a good idea to have something brief the code for those people who don't >> want to leave the command line. >> >> Finally, for everyone else that's reviewing: I find it hard to review big >> changes like this on gerrit since you only see one change at a time and >> you >> can't see what the "end result" is. However, if you go to the last commit >> ( >> https://gem5-review.googlesource.com/c/public/gem5/+/10975/1) and click >> on >> the sha hash of the commit it lead you to this page ( >> >> https://gem5.googlesource.com/public/gem5/+/ebd453d32fe1abcf1fb1a047dbcd6151558a117e >> ) >> which will show you the "final" code after all of the patches are applied. >> Hopefully this can save someone some time! >> >> Cheers, >> Jason >> >> PS: I don't know much about SystemC. I've been learning a little trying to >> review Gabe's changes... I have a general question: what are the tradeoffs >> compared to gem5? Specifically, is there *anything* that's better about >> gem5? This is a much larger conversation, but the suggestion of replacing >> gem5's simulation engine with SystemC is intriguing (and scary...). >> >> On Mon, Jun 11, 2018 at 7:19 PM Gabe Black wrote: >> >> > Ok great, glad to hear it. >> > >> > Gabe >> > >> > On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung >> > wrote: >> > >> > > Hi Christian, >> > > >> > > I think you summarised the 3 approaches very well. I mean, we have >> > > approach 1 already. It makes sense if Gabe drives approach 2 because >> > > it has many advantages compared to approach 1. I think we could see >> > > approach 3 as a longterm goal and we should go for approach 2 for now. >> > > >> > > Thanks for all the opinions so far, >> > > Best, >> > > Matthias >> > > >> > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < >> > > christian.men...@tu-dresden.de>: >> > > > >> > > > Hi, >> > > > >> > > > I am following the discussion for a while now and finally found the >> > time >> > > > to look at Gabe's proposal. >> > > >
Re: [gem5-dev] systemc reviews
Ok, I'll add you to future reviews. All the existing ones (or at least most of them) are part of the systemc topic branch on gerrit, so hopefully they should be pretty easy to find. There are about 50 of them right now I think, so to avoid lots of tedious clicking around I'll leave the existing ones as an exercise for the reader. :-) Gabe On Fri, Jun 15, 2018 at 2:34 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Hi Gabe, > > > please consider myself interested on reviewing SystemC patches ?? > > > From: gem5-dev on behalf of Gabe Black < > gabebl...@google.com> > Sent: 15 June 2018 09:55:30 > To: gem5 Developer List > Subject: Re: [gem5-dev] systemc reviews > > Oh, by the way, I've been adding Andreas, Jason and Matthias Jung to all > the systemc reviews I've been posting. I think those folks should > definitely be in the loop, but I don't want to exclude anybody else. If you > also want to be on all the reviews, please let me know. I don't want to > unilaterally bomb people's inboxes if they're not interested. > > Gabe > > On Fri, Jun 15, 2018 at 1:35 AM Gabe Black wrote: > > > Hey Jason, thanks for taking a look. As far as comments go, there aren't > > really that many comments in the Accellera implementation either, at > least > > not doxygen style, per function args, ret style comments. I think for > > things which are defined in the spec and/or in systemc books, tutorials, > > etc., those comments are really that necessary since the APIs are already > > fairly extensively documented elsewhere, and in a better more usable form > > than comments in the headers. When it comes to the stuff that isn't in > the > > spec, like the guts of the implementation that make all those parts work, > > then comments make a lot of sense since there isn't an already existing > and > > superior form of documentation out there. > > > > So in short, I don't intend to document systemc itself since that's > > already been extensively done elsewhere, but I do intend to document the > > difference in the gem5 flavor, and the internals. > > > > Gabe > > > > On Thu, Jun 14, 2018 at 6:19 PM Jason Lowe-Power > > wrote: > > > >> Hey Gabe, > >> > >> So, I've finally starting going through all of the patches (as you could > >> see). One thing that I don't want to write on every single patch is "add > >> comments", but I really think that the header files should have doxygen > >> comments on everything. Is it possible to copy them over from the > >> Accellera > >> implementation? > >> > >> Another general documentation thing is that at some point it would be > good > >> to put at least a short README in the systemc directory. I'm sure you're > >> planning to write extensive documentation on the wiki ;), but it would > >> also > >> be a good idea to have something brief the code for those people who > don't > >> want to leave the command line. > >> > >> Finally, for everyone else that's reviewing: I find it hard to review > big > >> changes like this on gerrit since you only see one change at a time and > >> you > >> can't see what the "end result" is. However, if you go to the last > commit > >> ( > >> https://gem5-review.googlesource.com/c/public/gem5/+/10975/1) and click > >> on > >> the sha hash of the commit it lead you to this page ( > >> > >> > https://gem5.googlesource.com/public/gem5/+/ebd453d32fe1abcf1fb1a047dbcd6151558a117e > >> ) > >> which will show you the "final" code after all of the patches are > applied. > >> Hopefully this can save someone some time! > >> > >> Cheers, > >> Jason > >> > >> PS: I don't know much about SystemC. I've been learning a little trying > to > >> review Gabe's changes... I have a general question: what are the > tradeoffs > >> compared to gem5? Specifically, is there *anything* that's better about > >> gem5? This is a much larger conversation, but the suggestion of > replacing > >> gem5's simulation engine with SystemC is intriguing (and scary...). > >> > >> On Mon, Jun 11, 2018 at 7:19 PM Gabe Black > wrote: > >> > >> > Ok great, glad to hear it. > >> > > >> > Gabe > >> > > >> > On Mon, Jun 11, 2018 at 3:34 PM Matthias Jun
Re: [gem5-dev] systemc reviews
> If you also want to be on all the reviews, > please let me know. I don't want to unilaterally > bomb people's inboxes if they're not interested. Wait. I am not sure what you are saying here. Are you proposing to *add* so Andreas, Jason and Matthias will receive more emails over those review emails the dev list is receiving already? Or are you proposing to *subtract* so that the dev list will no longer receive the systemc reviews like we receive now? Personally, I am not *that* interested in SystemC to *act* on those reviews, but I sure-as-hell enjoy *reading* them. Are you proposing to make this "lurk mode" unavailable? ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] systemc reviews
Hey Boris, I think that gerrit always sends the first message when a patch is uploaded to the whole list. Then, when adding comments or updating patches gerrit only sends emails to people that are cc'ed in gerrit. I'm not sure what the behavior is on merges... I'm not sure what an easy way to be added to a whole set of changes is. I don't think gerrit supports it. However you can add yourself as a reviewer (or cc) to the SystemC changes on a per changeset basis here: https://gem5-review.googlesource.com/q/topic:%22systemc%22+(status:open%20OR%20status:merged) . Cheers, Jason On Fri, Jun 15, 2018 at 6:14 AM Boris Shingarov wrote: > > If you also want to be on all the reviews, > > please let me know. I don't want to unilaterally > > bomb people's inboxes if they're not interested. > > Wait. I am not sure what you are saying here. > Are you proposing to *add* so Andreas, Jason and > Matthias will receive more emails over those review > emails the dev list is receiving already? > Or are you proposing to *subtract* so that the dev > list will no longer receive the systemc reviews like > we receive now? > Personally, I am not *that* interested in SystemC > to *act* on those reviews, but I sure-as-hell enjoy > *reading* them. > Are you proposing to make this "lurk mode" unavailable? > ___ > 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] systemc reviews
Hello again folks. There are currently 90 pending systemc CLs, and more will be coming. We need to close the incoming vs outgoing gap. On Fri, Jun 15, 2018 at 12:01 PM Jason Lowe-Power wrote: > Hey Boris, > > I think that gerrit always sends the first message when a patch is uploaded > to the whole list. Then, when adding comments or updating patches gerrit > only sends emails to people that are cc'ed in gerrit. I'm not sure what the > behavior is on merges... > > I'm not sure what an easy way to be added to a whole set of changes is. I > don't think gerrit supports it. However you can add yourself as a reviewer > (or cc) to the SystemC changes on a per changeset basis here: > > https://gem5-review.googlesource.com/q/topic:%22systemc%22+(status:open%20OR%20status:merged) > . > > Cheers, > Jason > > On Fri, Jun 15, 2018 at 6:14 AM Boris Shingarov > wrote: > > > > If you also want to be on all the reviews, > > > please let me know. I don't want to unilaterally > > > bomb people's inboxes if they're not interested. > > > > Wait. I am not sure what you are saying here. > > Are you proposing to *add* so Andreas, Jason and > > Matthias will receive more emails over those review > > emails the dev list is receiving already? > > Or are you proposing to *subtract* so that the dev > > list will no longer receive the systemc reviews like > > we receive now? > > Personally, I am not *that* interested in SystemC > > to *act* on those reviews, but I sure-as-hell enjoy > > *reading* them. > > Are you proposing to make this "lurk mode" unavailable? > > ___ > > 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
Re: [gem5-dev] systemc reviews
Hi folks. Thank you for all your reviewing efforts so far. I know it's not easy considering the scope of the effort, and that the dark inner workings and far reaching expanses of systemc are not familiar to everyone. To keep the review process open to feedback while at the same time ensuring (hopefully) forward process, I'm planning to institute a sliding window of review timeouts, or in other words approximately 10, say, of the oldest pending reviews will, absent any feedback to the contrary, have a timeout of, for instance, a week. When a week passes with no additional feedback (assuming I'm not the gating factor), then I will assume there isn't any feedback and check in those changes. I think this is a good compromise between making sure everybody has a chance to voice their opinions, but also not artificially forcing potentially less useful feedback just to check the "I got it reviewed" checkbox. Also this code is in its own directory and isn't being used by anyone yet (it doesn't work and is gated behind a build option), so if I do check in something dumb and broken, nobody else should be affected. In the spirit of this approach, please let me know if you have any objections. Prolonged silence will be considered consent. Gabe On Wed, Jun 20, 2018 at 6:39 PM Gabe Black wrote: > Hello again folks. There are currently 90 pending systemc CLs, and more > will be coming. We need to close the incoming vs outgoing gap. > > On Fri, Jun 15, 2018 at 12:01 PM Jason Lowe-Power > wrote: > >> Hey Boris, >> >> I think that gerrit always sends the first message when a patch is >> uploaded >> to the whole list. Then, when adding comments or updating patches gerrit >> only sends emails to people that are cc'ed in gerrit. I'm not sure what >> the >> behavior is on merges... >> >> I'm not sure what an easy way to be added to a whole set of changes is. I >> don't think gerrit supports it. However you can add yourself as a reviewer >> (or cc) to the SystemC changes on a per changeset basis here: >> >> https://gem5-review.googlesource.com/q/topic:%22systemc%22+(status:open%20OR%20status:merged) >> . >> >> Cheers, >> Jason >> >> On Fri, Jun 15, 2018 at 6:14 AM Boris Shingarov >> wrote: >> >> > > If you also want to be on all the reviews, >> > > please let me know. I don't want to unilaterally >> > > bomb people's inboxes if they're not interested. >> > >> > Wait. I am not sure what you are saying here. >> > Are you proposing to *add* so Andreas, Jason and >> > Matthias will receive more emails over those review >> > emails the dev list is receiving already? >> > Or are you proposing to *subtract* so that the dev >> > list will no longer receive the systemc reviews like >> > we receive now? >> > Personally, I am not *that* interested in SystemC >> > to *act* on those reviews, but I sure-as-hell enjoy >> > *reading* them. >> > Are you proposing to make this "lurk mode" unavailable? >> > ___ >> > 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
Re: [gem5-dev] systemc reviews
Hey Gabe, This is fine with me. Sorry for putting off reviewing all of these. If there's anything that you think specifically needs to be looked at more closely, let us know. Otherwise, as you said, since this is fairly separate from the rest of gem5 we can be pretty laissez faire about it. Cheers, Jason On Mon, Jul 16, 2018 at 3:44 AM Gabe Black wrote: > Hi folks. Thank you for all your reviewing efforts so far. I know it's not > easy considering the scope of the effort, and that the dark inner workings > and far reaching expanses of systemc are not familiar to everyone. > > To keep the review process open to feedback while at the same time ensuring > (hopefully) forward process, I'm planning to institute a sliding window of > review timeouts, or in other words approximately 10, say, of the oldest > pending reviews will, absent any feedback to the contrary, have a timeout > of, for instance, a week. When a week passes with no additional feedback > (assuming I'm not the gating factor), then I will assume there isn't any > feedback and check in those changes. > > I think this is a good compromise between making sure everybody has a > chance to voice their opinions, but also not artificially forcing > potentially less useful feedback just to check the "I got it reviewed" > checkbox. Also this code is in its own directory and isn't being used by > anyone yet (it doesn't work and is gated behind a build option), so if I do > check in something dumb and broken, nobody else should be affected. > > In the spirit of this approach, please let me know if you have any > objections. Prolonged silence will be considered consent. > > Gabe > > On Wed, Jun 20, 2018 at 6:39 PM Gabe Black wrote: > > > Hello again folks. There are currently 90 pending systemc CLs, and more > > will be coming. We need to close the incoming vs outgoing gap. > > > > On Fri, Jun 15, 2018 at 12:01 PM Jason Lowe-Power > > wrote: > > > >> Hey Boris, > >> > >> I think that gerrit always sends the first message when a patch is > >> uploaded > >> to the whole list. Then, when adding comments or updating patches gerrit > >> only sends emails to people that are cc'ed in gerrit. I'm not sure what > >> the > >> behavior is on merges... > >> > >> I'm not sure what an easy way to be added to a whole set of changes is. > I > >> don't think gerrit supports it. However you can add yourself as a > reviewer > >> (or cc) to the SystemC changes on a per changeset basis here: > >> > >> > https://gem5-review.googlesource.com/q/topic:%22systemc%22+(status:open%20OR%20status:merged) > >> . > >> > >> Cheers, > >> Jason > >> > >> On Fri, Jun 15, 2018 at 6:14 AM Boris Shingarov > >> wrote: > >> > >> > > If you also want to be on all the reviews, > >> > > please let me know. I don't want to unilaterally > >> > > bomb people's inboxes if they're not interested. > >> > > >> > Wait. I am not sure what you are saying here. > >> > Are you proposing to *add* so Andreas, Jason and > >> > Matthias will receive more emails over those review > >> > emails the dev list is receiving already? > >> > Or are you proposing to *subtract* so that the dev > >> > list will no longer receive the systemc reviews like > >> > we receive now? > >> > Personally, I am not *that* interested in SystemC > >> > to *act* on those reviews, but I sure-as-hell enjoy > >> > *reading* them. > >> > Are you proposing to make this "lurk mode" unavailable? > >> > ___ > >> > 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
Re: [gem5-dev] systemc reviews
Ok, sounds good. There was one other comment I saw besides the ones about using = delete which I think is also because of what's in the spec. ( https://gem5-review.googlesource.com/c/public/gem5/+/10832). I wanted to point that out specifically just so it doesn't get lost in all the emails I'm sure gerrit is sending out. Gabe On Mon, Jul 23, 2018 at 11:12 AM Jason Lowe-Power wrote: > Hey Gabe, > > This is fine with me. Sorry for putting off reviewing all of these. > > If there's anything that you think specifically needs to be looked at more > closely, let us know. Otherwise, as you said, since this is fairly separate > from the rest of gem5 we can be pretty laissez faire about it. > > Cheers, > Jason > > On Mon, Jul 16, 2018 at 3:44 AM Gabe Black wrote: > > > Hi folks. Thank you for all your reviewing efforts so far. I know it's > not > > easy considering the scope of the effort, and that the dark inner > workings > > and far reaching expanses of systemc are not familiar to everyone. > > > > To keep the review process open to feedback while at the same time > ensuring > > (hopefully) forward process, I'm planning to institute a sliding window > of > > review timeouts, or in other words approximately 10, say, of the oldest > > pending reviews will, absent any feedback to the contrary, have a timeout > > of, for instance, a week. When a week passes with no additional feedback > > (assuming I'm not the gating factor), then I will assume there isn't any > > feedback and check in those changes. > > > > I think this is a good compromise between making sure everybody has a > > chance to voice their opinions, but also not artificially forcing > > potentially less useful feedback just to check the "I got it reviewed" > > checkbox. Also this code is in its own directory and isn't being used by > > anyone yet (it doesn't work and is gated behind a build option), so if I > do > > check in something dumb and broken, nobody else should be affected. > > > > In the spirit of this approach, please let me know if you have any > > objections. Prolonged silence will be considered consent. > > > > Gabe > > > > On Wed, Jun 20, 2018 at 6:39 PM Gabe Black wrote: > > > > > Hello again folks. There are currently 90 pending systemc CLs, and more > > > will be coming. We need to close the incoming vs outgoing gap. > > > > > > On Fri, Jun 15, 2018 at 12:01 PM Jason Lowe-Power > > > > wrote: > > > > > >> Hey Boris, > > >> > > >> I think that gerrit always sends the first message when a patch is > > >> uploaded > > >> to the whole list. Then, when adding comments or updating patches > gerrit > > >> only sends emails to people that are cc'ed in gerrit. I'm not sure > what > > >> the > > >> behavior is on merges... > > >> > > >> I'm not sure what an easy way to be added to a whole set of changes > is. > > I > > >> don't think gerrit supports it. However you can add yourself as a > > reviewer > > >> (or cc) to the SystemC changes on a per changeset basis here: > > >> > > >> > > > https://gem5-review.googlesource.com/q/topic:%22systemc%22+(status:open%20OR%20status:merged) > > >> . > > >> > > >> Cheers, > > >> Jason > > >> > > >> On Fri, Jun 15, 2018 at 6:14 AM Boris Shingarov < > shinga...@labware.com> > > >> wrote: > > >> > > >> > > If you also want to be on all the reviews, > > >> > > please let me know. I don't want to unilaterally > > >> > > bomb people's inboxes if they're not interested. > > >> > > > >> > Wait. I am not sure what you are saying here. > > >> > Are you proposing to *add* so Andreas, Jason and > > >> > Matthias will receive more emails over those review > > >> > emails the dev list is receiving already? > > >> > Or are you proposing to *subtract* so that the dev > > >> > list will no longer receive the systemc reviews like > > >> > we receive now? > > >> > Personally, I am not *that* interested in SystemC > > >> > to *act* on those reviews, but I sure-as-hell enjoy > > >> > *reading* them. > > >> > Are you proposing to make this "lurk mode" unavailable? > > >> > ___ > > >> > 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
