> 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. > > Nilay Vaish wrote: > 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. > > Andreas Hansson wrote: > I do not think a couple of papers is a good reason to hide clock-domain > crossings in the link model. I'd argue the opposite. These papers most likely > have outrageous assumptions on the implications of the per-router DVFS (or > they would not do it). No sensible design would penalise the link traversal > with a costly clock-domain (and possibly also power-domain) crossing. > > I would argue that the link should be synchronous with the neighbours, > and if someone wants to insert a clock/power-domain crossing they should > simply instantiate a specific object to do the bridging and pay the latency > cost there. > > Jieming Yin wrote: > I sort of see the motivation behind this change, the network components > have to agree upon a base measurement of time. > The original agreement was cycle, but routers might not have the same > definition of cycle. However, I don't think > changing it to tick is appropriate either. > > Agree with Andreas, I think links should be in the same clock domain with > either the upstream or the downstream router. > This change potentially allows the upstream router, the link, and the > downstream router to have 3 different clock domains, > which doesn't make to much sense. > > Andreas Hansson wrote: > I firmly believe we should not be hiding an implicit clock-domain > crossing in a router link. > > Nilay Vaish wrote: > Andreas, while I am willing to believe that what you are saying is what > happens in an actual physical designs, > I would want to allow for clock-domain crossing. Unlike classic, ruby > has no notion of bridges. So either > MessageBuffer or NetworkLink would have to act as bridge. My > understanding is that MessageBuffer already do so, > I am asking for NetworkLink to do as well. We will keep the defaults so > that operations are synchronous. > > Jieming, gem5 has only two units of time: Tick and Cycles. Since Tick is > the base unit, I think it is the appropriate one. > What would you suggest we do? > > NetworkLink would be converted from a ClockedObject to a SimObject in > some patch. I am currently unsure which one > should do it.
It has to be Cycles for any DVFS to be meaningful. If a link is to become an implicit clock-domain crossing I would suggest the delay to be 1 cycle in the "sending" clock domain and 2 cycles in the "receiving" block domain. I still think this change is sending the wrong signal and that it essentially re-inforces bad assumptions. - Andreas ----------------------------------------------------------- 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
