On Wed, Oct 10, 2018 at 5:18 PM Gabe Black <[email protected]> wrote:
> On Wed, Oct 10, 2018 at 4:44 PM Jason Lowe-Power <[email protected]> > wrote: > > > Hey Gabe, > > > > TBH, I've been ignoring most of the SystemC stuff for a while now... > you've > > really been doing a lot of work! :). We should be looking into this more > > closely soon. I have a student who is going to be trying to use your > > SystemC integration this quarter. Some other comments inline below. > > > > Cheers, > > Jason > > > > On Tue, Oct 9, 2018 at 3:26 PM Gabe Black <[email protected]> wrote: > > > > > Hi folks! Since the systemc implementation seems to be nearing an > > > interesting point, I thought it would be a good idea to let everyone > know > > > what's going on. > > > > > > 1. Even though I've been checking in a batch of 40 CLs a week, the list > > of > > > pending CLs still sits at 92. Since the previous CLs haven't been > > reviewed, > > > I'm hoping it will be fine to just wait a week (without annotating all > 92 > > > CLs as such), and then checking them all in to get everything up to > date. > > > > > > > > Is there anything of particular interest to look at in these last 92? I > > assume not... but if there is, let me know and I can take a look early > next > > week. > > > > Nothing any more interesting that what preceded it. The things that might > come after it (the examples, enabling systemc in normal builds, hooking > into ports) may be more interesting. > > > > > > > > > > > > 2. I'm planning to make some examples to show how you can run a systemc > > > simulation based on sc_main, or one which has systemc objects > > instantiated > > > by gem5 and built into a gem5 hierarchy. I asked about this in an > earlier > > > email, but I'm assuming putting these in a new directory called > > "examples" > > > at the top level of the repository is ok. CLs will of course be > available > > > for review if people want to object and/or suggest alternatives. > > > > > > > I saw the other email, and I meant to respond. Maybe util/ would be a > good > > place to put this, like the current SystemC examples. I don't really like > > the idea of a new top-level directory for examples since it doesn't seem > > like anything else would go there. > > > > Sure. util seems like a strange place to look for examples, but if that's > where some already are that seems reasonable. > > Agreed, it is weird. I'd also be ok with a more thorough restructuring and adding a gem5/examples directory if there was more than just SystemC stuff there. > > > > > > > > > > > > 3. The systemc sources have been guarded by a scons variable which > means > > > that while you all likely have them (as of 92 CLs ago) in your > checkouts, > > > they aren't currently doing anything. I'm planning to flip that switch > to > > > be default on in the near future, and then after that removing the > > switch. > > > This is just a heads up. > > > > > > > Would it make sense to keep this as an option and *not* enable it by > > default? Does SystemC add significant compile time to gem5 and add size > to > > the binary? I expect SystemC will be used by a small minority of gem5 > > users. > > > > > I think it definitely should be enabled by default, since otherwise many > people won't build it and it will end up broken a lot. The impact on > compile time isn't significant, particularly if you're doing an incremental > build. The gem5.opt binary size (using the ARM arch) went from 714MB to > 741MB, which is a less than 4% increase. I would be curious to see where > that extra space is going (code, data, etc.) to see if any can be trimmed > (I used the systemc data types, essentially their STL, as is), but it's not > a high priority right now. > > I can see a case where you might want to be able to turn it off to squeeze > down gem5's size for some reason, but even then it doesn't make that much > of a difference. I think getting rid of the knob most people will ignore > would be a better tradeoff complexity wise. > > > This sounds reasonable to me. I was just a little hesitant to add so much code by default, but I completely see where you're coming from with it being broken. I ran into this often with gem5-gpu. We probably should have pushed to mainline that support earlier. > > > > > > > > > > > > 4. I have an adapted version of Accelera's (the upstream systemc folks) > > > package of tests and run script in src/systemc/tests. The script is > > pretty > > > flexible and deserves some documentaiton, but in short if you want to > run > > > it you can use a command line like this: > > > > > > src/systemc/tests/verify.py -j 48 build/ARM/ --filter-file > > > src/systemc/tests/working.filt > > > > > > > Of the 853 total tests, some are simply uncompilable, a few are for > > > features which are deprecated or highly non-standard which I chose not > to > > > implement, leaving 818. Exactly which those are and why is described in > > the > > > working.filt file mentioned in the command line above. > > > > > > Of those 818, 798 are considered passing right now. Of the 20 > remaining, > > > the majority, 18, are "failing" because my implementation chooses to > run > > > some processes in one order, while the Accellera implementation > chooses a > > > different order. Both are within the spec, but since "correctness" is > > > determined by matching the output, these tests fail. One of the others > is > > > because of a corner case in how reset signals work at the very > beginning > > of > > > simulation, and the last is because I don't free up dead processes, and > > one > > > of the tests attempts to reuse their names. That works in the Accellera > > > implementation, but mine recongizes the conflict and renames the new > > > objects per the spec. > > > > > > I've made considerable effort to match the ordering of the Accellera > > > implementation, but these last few are, in my opinion, not worth > chasing > > > down or contorting the gem5 implementation to match. My thought as of > > right > > > now is to update the reference output so that the tests pass with > gem5's > > > ordering. > > > > > > In general it's not great to use the output and arbitrary non-standard > > > ordering decisions to determine correctness. There are several places > in > > > the implementation where I've done things in ways that I know are > > > inefficient, but which match Accellera. I would like to fix those, but > > > doing so would make some of the tests fail. In a perfect world, we > would > > > have tests which checked only the required behavior and not arbitrary > > > undefined decisions the implementation is allowed to make. > > > > > > > > All of this seems reasonable to me. I like the idea of updating the > outputs > > to match gem5's ordering. > > > > Any chance you can hook this into the new testing infrastructure? (E.g., > > ext/testlib, tests/main.py, and tests/gem5.) Maybe you could add a > > tests/systemc/ that looks like tests/gem5/ or just add a directory under > > tests/gem5. If you have any questions on how to use the new testing > > infrastructure don't hesitate to ask. I really want to migrate everything > > over to that. > > > > > Yeah, I want to do that. I haven't looked into how yet, but that's where I > see this going. > > > > > > > > > > > > > 5. There is no mechanism yet for connecting models either to gem5 > through > > > TLM with a bridge, or with gem5 ports with a systemc interface on the > far > > > side. This is the next major thing to implement, probably starting with > > an > > > interface/channel for speaking the gem5 protocol. This would also be > > where > > > the existing gem5/TLM bridge would be very handy. > > > > > > > Cool! This is something we're interested in having here, so maybe we > should > > chat about it soon. > > > > > Yeah, I've been looking into the code, and I have some ideas for how that > will work. I'm hoping to do some experiments to determine whether my ideas > will work and to write up something about them in the fairly near future. > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
