> 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.
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. > 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. 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). > 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. 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. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1266/#review3028 ----------------------------------------------------------- On June 21, 2012, 8:18 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1266/ > ----------------------------------------------------------- > > (Updated June 21, 2012, 8:18 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9079:5fb6386c07b4 > --------------------------- > 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 d8e5ca139d7c > src/mem/bus.cc d8e5ca139d7c > src/mem/coherent_bus.hh d8e5ca139d7c > src/mem/coherent_bus.cc d8e5ca139d7c > src/mem/noncoherent_bus.hh d8e5ca139d7c > src/mem/noncoherent_bus.cc d8e5ca139d7c > > 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
