> On July 28, 2015, 9:30 p.m., Andreas Hansson wrote: > > src/mem/serial_link.cc, line 155 > > <http://reviews.gem5.org/r/2986/diff/1/?file=48388#file48388line155> > > > > Cycles as the type > > > > Should you use divCeil here? > > > > Should there not be overheads in addition to the packet size? 16 bytes > > (make it a parameter?)
I fixed Cycles. There are two latency parameters in HMC.py related to the serial link: 1) link_latency: this is modeled using the delay of the serial_link component 2) link_overhead: this is modeled using forward_latency and response_latency of the HMC controller (HMC.py) The correct solution would have been to implement both of these delays in the serial_link itself, but I chose the easier solution, and modeled link_overhead in the hmccontroller. I hope this makes sense > On July 28, 2015, 9:30 p.m., Andreas Hansson wrote: > > src/mem/serial_link.cc, line 160 > > <http://reviews.gem5.org/r/2986/diff/1/?file=48388#file48388line160> > > > > no need to do this, call schedTimingResp(pkt, t, true). > > > > Why would changing the order be a problem? There is no prototype for schedTimingResp(pkt, t, true), only schedTimingResp(pkt, t) Please correct me if I am wrong. If the processor sends two uncached requests towards HMC and the second one is smaller than the first one. It may happen that the second one crosses this link faster than the first one (because the packet waits in the link based on its size). This can reorder the received response. I think that this can cause a problem > On July 28, 2015, 9:30 p.m., Andreas Hansson wrote: > > src/mem/serial_link.cc, line 216 > > <http://reviews.gem5.org/r/2986/diff/1/?file=48388#file48388line216> > > > > Same as the other one in terms of units, divCeil, and flit overhead. > > > > We should definitely add the pkt->headerDelay before zeroing it. > > > > Should we not also add pkt->payloadDelay? Can we start serialising > > before the "link controller" has the entire packet? I fixed the cycles. Yes, the serializer can start serialization, as soon as it has received the first flit. Because, if during the serialization an error occurs, the serializer will simply inform the receiver by modifying the error detection code in the tail flit. Then, the receiver will drop the packet, and later a retransmission will occur. About pkt->headerDelay, I am still not sure yet, I will look more into it separately. - Erfan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2986/#review6844 ----------------------------------------------------------- On July 29, 2015, 10:10 a.m., Erfan Azarkhish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2986/ > ----------------------------------------------------------- > > (Updated July 29, 2015, 10:10 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10936:786020abb0e5 > --------------------------- > Simple HMC Model > This patch requires another patch to be applied: > The serial link model for HMC: > http://reviews.gem5.org/r/2993/ > > > Diffs > ----- > > src/mem/hmc_controller.cc PRE-CREATION > src/mem/xbar.hh acd48ddd725f > src/mem/HMCController.py PRE-CREATION > src/mem/SConscript acd48ddd725f > src/mem/hmc_controller.hh PRE-CREATION > configs/example/fs.py acd48ddd725f > configs/example/hmctest.py PRE-CREATION > configs/common/HMC.py PRE-CREATION > configs/common/MemConfig.py acd48ddd725f > src/mem/DRAMCtrl.py acd48ddd725f > > Diff: http://reviews.gem5.org/r/2986/diff/ > > > Testing > ------- > > gem5 compiles > fs.py executes and Linux boots correctly. > hmctest.py executes correctly, and stats correlate with cycle-accurate > simulation > > > Thanks, > > Erfan Azarkhish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
