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. > > > > > > > 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. > > > > > > > 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
