> On July 4, 2012, 4:25 p.m., Steve Reinhardt wrote: > > Looks nice. Does it make sense to keep the old single-layer buses as an > > option? I agree they're not very realistic for modern designs, but they do > > model something that people have built in the past. I'm not sure if it's > > worth the hassle or not, but I thought I'd raise the question. > > Andreas Hansson wrote: > I think there is little point. I'd prefer to have the split > request/response as the base, as that also avoids any protocol deadlock > issues, both involving the interaction of two caches, and the bridges between > buses. Makes sense? > > From there it is easy to support everything from split req/resp all the > way to a single layer per converging port, i.e. req layer per connected slave > and resp layer per connected master.
Good point, I'd forgotten about the deadlock issues with the existing bus. That's a sufficient reason to get rid of it IMO. > On July 4, 2012, 4:25 p.m., Steve Reinhardt wrote: > > src/mem/bus.hh, line 90 > > <http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line90> > > > > Would you document this template parameter more? Obviously every bus > > connects MasterPorts to SlavePorts, so it's not immediately obvious what > > goes here. > > > > Also, I don't know if we have an official style rule for template > > parameter naming, but I know that all-caps is not common usage. I tend to > > make them camel case but with a suffix that indicates that it's not just a > > class name; e.g., in this case I would probably use PortClass. I'm happy > > to open a discussion on this if desired. > > Andreas Hansson wrote: > I'm happy to change it. I was not aware of the convention, and if > PortClass is desired then that's fine with me. It is a bit long though, > that's my only concern. For the port it is fine, but I am about to post a > patch which uses templates for the port interfaces, and that ends up being > BaseMasterPortInterfaceClass. As I said, there isn't an official convention (at least not documented on the wiki), but we should have one. Looking through the existing code base, we are not consistent. Most uses are either one or two capital letters (e.g., T) or follow our standard class naming convention (e.g., Stat, Derived, Impl). There are a few exceptions; mem/ruby/system/PerfectCacheMemory.hh uses ENTRY, arch/arm/insts/vfp.hh uses fpType. I guess tacking on "Class" is something that only I do. So I guess if we use existing code as a guide, "Port" would be the appropriate capitalization, but in this case that would be pretty confusing though, so I would still lean toward "PortClass". It would be nice to establish some standard and I'd be happy to have a discussion about it. We should probably start a new thread instead of burying it in these comments though. For longer parameter names, you can always use typedefs if they get awkward. Plus I'd argue that BaseMasterPortInterface is pretty long by itself anyway (so tacking on "Class" doesn't make it that much worse), and BASEMASTERPORTINTERFACE or whatever you were planning on doing otherwise is pretty ugly ;-). > On July 4, 2012, 4:25 p.m., Steve Reinhardt wrote: > > src/mem/bus.hh, line 133 > > <http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line133> > > > > I feel like we discussed "Port* port" vs "Port *port" before as well... > > do you recall what we ended up deciding? We should probably record that > > decision on the wiki. > > Andreas Hansson wrote: > The decision was: > > 1) Port* port is ok > 2) Port *port is ok > 3) Port * port is _not_ ok > > For 1) and 2), the use should be guided by the context, i.e. if changing > an existing file that predominantly uses 1), then stick with it (or change > the whole file to be consistent). If creating a major chunk of code from > scratch, we did not decide whether to favour 1) or 2)...so I go with 1). OK, I'm glad you remembered. I updated the wiki to make it official. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1266/#review3028 ----------------------------------------------------------- On July 5, 2012, 1:53 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1266/ > ----------------------------------------------------------- > > (Updated July 5, 2012, 1:53 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9095:d34f7edb5762 > --------------------------- > Bus: Split the bus into separate request/response layers > > This patch splits the existing buses into multiple layers. The > non-coherent bus is split into a request and a response layer, and the > coherent bus adds an additional layer for the snoop responses. The > layer is modified to be templatised on the port type, such that the > different layers can have retryLists with either master or slave > ports. This patch also removes the dynamic cast from the retry, as > previously promised when moving the recvRetry from the port base class > to the master/slave port respectively. > > Overall, the split bus more closely reflects any modern on-chip bus > and should be at step in the right direction. From this point, it > would be reasonable straight forward to add separate layers (and thus > contention points and arbitration) for each port and thus create a > true crossbar. > > The regressions all produce the correct output, but have varying > degrees of changes to their statistics. A separate patch will be > pushed with the updates to the reference statistics. > > > Diffs > ----- > > src/mem/bus.hh 5f0321c03a26 > src/mem/bus.cc 5f0321c03a26 > src/mem/coherent_bus.hh 5f0321c03a26 > src/mem/coherent_bus.cc 5f0321c03a26 > src/mem/noncoherent_bus.hh 5f0321c03a26 > src/mem/noncoherent_bus.cc 5f0321c03a26 > > Diff: http://reviews.gem5.org/r/1266/diff/ > > > Testing > ------- > > util/regress all running and producing the right output (disregarding t1000 > and eio) but with essentially all timing tests exhibiting stat differences > reflecting less bus contention > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
