Thanks for the explanation! I appreciate it!
I agree that this approximation works fine for buses which usually have small
latency and don't get connected to a large number of nodes. Just want to note
that because pkt->firstWordTime and pkt->finishTime are only handled in
Cache::handleResponse, the round-trip bus latency for a read request from L1 to
L2 is counted as one-way. This is because L2 doesn't handle the bus latency
when receiving the request from L1. Please correct me if I'm wrong.
Thanks again!
Jiayuan
> The basic idea is that Bus::recvTiming() is called only when the
> packet is actually sent across the bus; if a sender tries to send a
> packet earlier when the bus is busy, it will not be able to (it will
> get a 'false' return value from sendTiming()), and then will have to
> wait on a retry() callback. So the timing of the successful
> recvTiming() invocation reflects all of the contention delays due to
> other packets (i.e., waiting for the bus to become idle).
>
> It's true that since there's no additional delay on the sendTiming()
> there's no bus latency being modeled; once the packet gets onto the
> bus, it's transferred instantaneously from the sender to the
> receiver(s). The firstWordTime and finishTime are provided to allow
> the receiver to properly deal with that latency, including situations
> where critical-word-first transfers are being modeled. As you note,
> only the cache actually uses those values though, which is arguably a
> bug.
>
> The reason it's done this way is that we don't want to schedule more
> events than we need to. For simple devices with a fixed latency,
> you'll be scheduling a response packet anyway, and you should simply
> schedule that response at (finishTime + deviceLatency) instead of just
> deviceLatency. For more complex devices like the cache where you care
> about timing within the transfer, you can't just notify the cache at
> finishTime, since it needs to know when the first word arrives for
> critical-word-first bypassing.
>
> Steve
>
> On Dec 2, 2007 8:44 PM, Jiayuan Meng <[EMAIL PROTECTED]> wrote:
>>
>>
>> I noticed that occupyBus() sets pkt->firstWordTime and pkt->finishTime.
>> However, these variables are only utilized
>> by Cache::handleResponse(). What if the packet is a request? I'm just
>> wondering how firstWordTime and finishTime is handled in all cases.
>>
>> Thanks!
>>
>> Jiayuan
>>
>>
>>
>> ----- Original Message -----
>> From: Jiayuan Meng
>> To: M5 users mailing list
>> Sent: 2007年12月3日 12:36 PM
>> Subject: [m5-users] bus latency modeling
>>
>>
>> I have a question regarding Bus::recvTiming
>>
>> In this function, occupyBus() calculates when the packet is received
>> completely by dest_port (tickNextIdle). However, "sendTiming" is executed
>> instantly afterwards without delay (both to dest_port and snoop ports). I
>> understand the "adding instead of dividing" trick, but for this latency
>> model to be effective, shouldn't the dest_port and snoop ports see the
>> packet at tickNextIdle? Am I missing something?
>>
>> Thanks!
>>
>> Jiayuan
>>
>>
>> ________________________________
>>
>>
>> _______________________________________________
>> m5-users mailing list
>> m5-users@m5sim.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> _______________________________________________
>> m5-users mailing list
>> m5-users@m5sim.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
> _______________________________________________
> m5-users mailing list
> m5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
