> On Aug. 10, 2015, 7:09 a.m., Andreas Hansson wrote: > > To me this seems like a step in the wrong direction, but perhaps I am > > missing something. > > > > We spent a considerable effort ensuring DVFS works throughout gem5, and > > moving to latencies in absolute time goes against the whole philosophy. Do > > people not see any use-case for Ruby + DVFS? > > Nilay Vaish wrote: > I think my patch description is misleading. > > The unit change is required for communication of time between different > components. > My understanding is that Cycles as a unit of time should be used > internally with in > a component, where a component implies any unit whose each part is going > to operate > at the same frequency. Across components we do not have any guarantees on > the > frequency, so the unit of time has to be a unit that has the same meaning > for > everyone. Before this patch, some of the components in the on-chip > network were > using Cycles as unit for inter-component communication. This unit is > being changed > to Tick. > > Andreas Hansson wrote: > I somehow do not see the logic. It seems that the router subcomponents > are now being given delays in ticks instead of cycles. I am not sure I > understand the "between" part of your description. The only item that is > truly between things would be the link, and that should _never_ be allowed to > be an implicit clock-domain crossing imho. > > Nilay Vaish wrote: > What units would you use to express the latency of a link? Tick or Cycles > or something else? > I think it should be either Tick or something else that every component > agrees on. > > Andreas Hansson wrote: > For a NoC link (which is essentially guaranteed to be synchronous) I > would argue to keep it in Cycles, since it will be in the same clock domain > as the two neighbouring routers.
Andreas, I have read at least two papers where the on-chip network had different routers operating at different frequencies. My own understanding is that nothing prevents us from having such designs, whether they have any advantages over synchronous designs (all routers at same frequency) or not is a different question. Secondly, gem5 is a research simulator, so I would want to keep things flexible enough. We will keep the default to be all routers at same frequency (which is currently the case), but it should be possible for users to modify things so as to have designs with different routers at different frequencies. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3009/#review6913 ----------------------------------------------------------- On Aug. 9, 2015, 6:25 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3009/ > ----------------------------------------------------------- > > (Updated Aug. 9, 2015, 6:25 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11044:328fb5a6911e > --------------------------- > ruby: network: changes unit of latency from Cycles to Tick > > Since each router and network interface has a clock of its own, it is hard to > keep track of time in terms of Cycles. This patch moves to the unit of time > being Tick. This is ultimately required for improving finer granularity event > scheduling for on-chip networks, which in turn improves the speed of > simulation. > > All the three on-chip network implementations are updated by this patch. > > > Diffs > ----- > > src/mem/ruby/network/BasicLink.hh 863d314f6356 > src/mem/ruby/network/BasicLink.py 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh > 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc > 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/OutputUnit_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/OutputUnit_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/RoutingUnit_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/Switch_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/flitBuffer_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/flitBuffer_d.cc 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 863d314f6356 > src/mem/ruby/network/garnet/fixed-pipeline/flit_d.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh > 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh > 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc > 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/flitBuffer.hh 863d314f6356 > src/mem/ruby/network/garnet/flexible-pipeline/flitBuffer.cc 863d314f6356 > src/mem/ruby/network/simple/SimpleNetwork.cc 863d314f6356 > src/mem/ruby/network/simple/Throttle.cc 863d314f6356 > > Diff: http://reviews.gem5.org/r/3009/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
