For events that are scheduled in the same cycle, we can use the event priorities to control relative ordering. Our initial assumption when we saw that the cache ack was occurring after the CPU's check of the store_in_flight flag was that it would just be a matter of changing the priorities, but then we found that the ack was coming a full tick later, so obviously it was not so simple.
If there's a more general problem and/or a more general solution here, we'd be glad to hear about it. Steve On Thu, Feb 14, 2013 at 3:39 AM, Andreas Hansson <[email protected]>wrote: > 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]> > Reply-To: gem5 users mailing list <[email protected]> > Date: Wednesday, 13 February 2013 18:16 > > To: gem5 users mailing list <[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 > -- > > -- 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
