Hi Binh,
Thanks for your question.
The reason for the +1 is that gem5 does not have a "proper" delta cycle.
Ultimately, everything that happens between curTick and the next "cycle" is the
same time, but gem5 is a bit unclear on this point in that the execution and
evaluation order actually matters. If a clock edge is at 500 and 1000, then
everything from [500, 1000) is in the same cycle. There was a discussion a few
weeks back about how this is solved in the O3 cpu.
Even if we remove the +1, there is no guarantee that the packet queue's notion
of time T comes before (or after) someone else's notion of time T. Thus, we
could remove the +1, and it might solve this specific case, but in general it
is not solving the more general problem of concurrent events. The CPU might
first see the 500, conclude there is nothing to do, and then get the response
from the cache.
I'm open for suggestions and keen to know what people think is the best way
forward.
Andreas
From: "Binh Q. Pham" <[email protected]<mailto:[email protected]>>
Reply-To: gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 13 February 2013 18:16
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
Subject: [gem5-users] Question about PacketQueue::scheduleSend
Hi everyone,
I see in mem/packet_queue.cc, function PacketQueue::scheduleSend(Tick time), we
have:
// the next ready time is either determined by the next deferred packet,
// or in the cache through the MSHR ready time
Tick nextReady = std::min(deferredPacketReadyTime(), time);
if (nextReady != MaxTick) {
// if the sendTiming caused someone else to call our
// recvTiming we could already have an event scheduled, check
if (!sendEvent.scheduled()) {
em.schedule(&sendEvent, std::max(nextReady, curTick() + 1));
}
}
Why do we do curTick() + 1? If a clock cycle is a multiple of ticks, e.g. 500
ticks, and curTick() is 500 or cycle #1, then curTick() + 1 effectively
schedules the event to be sent NOT at cycle 1 (Tick 500) or cycle 2 (Tick 1000)?
I noticed this while debugging a problem related to back to back stores sent to
the cache. Basically, I have 2 stores: store #1 is sent to the cache in cycle
1, and ideally should get the cache ACK in cycle 2 (Cache hit latency is 1
cycle). In cycle 2, the CPU checks if there is any store in flight before it
can send out store #2, but it cannot because store #1's ACK is back at Tick 501!
Right now, I have changed the code to em.schedule(&sendEvent,
std::max(nextReady, curTick())); but it would be best if someone could give me
some insight about this code.
I believe Andreas Hansson has written this code. So if you see this thread, I
would really appreciate if you can give some comments.
Thanks!
Binh
--
[cid:[email protected]]
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you._______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
