----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3172/#review7471 -----------------------------------------------------------
src/dev/io_device.cc (line 59) <http://reviews.gem5.org/r/3172/#comment6319> minor, but 'additional_latency' is rather nondescript. maybe 'transmission_delay' or 'receive_delay' or 'receive_latency' or something like thet? src/dev/io_device.cc (line 60) <http://reviews.gem5.org/r/3172/#comment6320> out of scope for now, but just a thought: arguably this zeroing of the delay fields should probably take place in Packet::makeResponse() src/mem/bridge.cc (line 145) <http://reviews.gem5.org/r/3172/#comment6321> why ticksToCycles()? aren't you adding a cycle value to a tick value? src/mem/bridge.cc (line 205) <http://reviews.gem5.org/r/3172/#comment6322> likewise src/mem/simple_mem.cc (line 164) <http://reviews.gem5.org/r/3172/#comment6323> this code looks awfully familiar :). is there a way to use PacketQueue here to avoid the redundancy? - Steve Reinhardt On Oct. 30, 2015, 3:35 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3172/ > ----------------------------------------------------------- > > (Updated Oct. 30, 2015, 3:35 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11188:353cf88682b9 > --------------------------- > mem: Use the packet delays and do not just zero them out > > This patch updates the I/O devices, bridge and simple memory to take > the packet header and payload delay into account in their latency > calculations. In all cases we add the header delay, i.e. the > accumulated pipeline delay of any crossbars, and the payload delay > needed for deserialisation of any payload. > > Due to the additional unknown latency contribution, the packet queue > of the simple memory is changed to use insertion sorting based on the > time stamp. Moreover, since the memory hands out exclusive (non > shared) responses, we also need to ensure ordering for reads to the > same address. > > > Diffs > ----- > > src/dev/io_device.cc 4daf60db14d7 > src/dev/pcidev.cc 4daf60db14d7 > src/mem/bridge.cc 4daf60db14d7 > src/mem/simple_mem.hh 4daf60db14d7 > src/mem/simple_mem.cc 4daf60db14d7 > > Diff: http://reviews.gem5.org/r/3172/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
