Thank you!  It has always bothered me that we never really used this timing information properly.

You probably figured this out already, but the idea here is that we don't want to always schedule multiple events for every data transfer, yet we need to enable devices like caches to properly model critical-word-first forwarding.

Basically naive devices should use curTick()+pkt->busLastWordDelay as the effective packet arrival time, and only devices doing critical-word-first optimizations should care about doing anything based on curTick()+pkt->busFirstWordDelay.

One alternative that might simplify other devices at the cost of making the bus a little more complicated would be for slaves to indicate whether they care about critical word first optimizations, and have the bus schedule transmission events either at pkt->busFirstWordDelay or at pkt->busLastWordDelay depending on the slave's indication.  Then at least the average dumb slave will be more likely to get the timing right, though at the cost of making the port semantics even more confusing.  If you have any other ideas on better ways to achieve this, I'm open to suggestions.

src/mem/bus.cc (Diff revision 1)

Does it make sense to include this offset in the relative time between the header and the data words?  If so, I don't understand why...

Show all issues

1. Andreas Hansson Feb. 17, 2013, 10:13 p.m. (Feb. 17, 2013, 10:13 p.m.)

   I'm not sure I follow.
   
   The offset is part of both first and last word delay calculations. Effectively it is there to:
   1) don't change the stats :-)
   2) round the "arrival" to the bus clock edge
   
   Are you suggesting to get rid of it?

2. Steve Reinhardt Feb. 18, 2013, 2:09 a.m. (Feb. 18, 2013, 2:09 a.m.)

   I assumed #1 was the case... just trying to figure out if, independent of that reasoning, this code still makes sense.
   
   Probably I'm just confused because I was looking at the comments and not the code.  If these two fields are delays relative to the header, it seems like the header would always be delivered on a bus clock edge, so why would the relative delays to other words not be multiples of the bus clock?
   
   I think what you're saying is that the offsets are really relative to the time when the packet is forwarded to the other bus clients, not to the header.  Looking at it more closely, I see that the comments on the packet fields themselves in packet.hh are accurate, it's really the comment on calcPacketTiming() in bus.hh that confused me a little bit (and had undue influence on my thinking solely because it showed up first in the diff).

Ship It!