I am trying to make a connection with how the buffer would have operated
when a digital circuit is designed. Suppose the sender raised the message
lines at t = 0.5. Then, the receiver's buffer would latch the message at
t = 1. The receiver should be able to process this message starting t = 1
+ delta. In our discrete simulator, we schedule the processing event at
time t = 2 and in one instant do all the work that was to be done in the
clock cycle.
I agree with Ali and I think the function is working as expected.
--
Nilay
On Tue, 7 Jan 2014, Ali Saidi wrote:
Hi Joel,
I think you're right that it's not quite as intended. I believe the
semantics are supposed to be:
clockEdge() returns the next clock edge and can be the current clock
edge
and nextCycle() returns the next clock edge and can't be the current
one.
Right now if nextCycle is called in the middle of a cycle its returns
the tick 1.5 cycles away.
However, as I'm writing this I have a feeling that was the desired
behavior of at least part of the memory system where the idea was if you
didn't have the input at the beginning of a cycle you shouldn't be able
to act on it until the next one.
Anyone else have an opinion?
Ali
On 07.01.2014 12:58, Joel Hestness wrote:
Hey Nilay,
This is in my own code. Below is the pseudo-code for the way the buffer
operates. It's in the receiver's clock domain, and a request can arrive at
any point during a cycle, because the sender's clock may be
different/out-of-phase. When a packet arrives off a receiver's clock edge,
nextCycle() returns the clock edge that would be 2 cycles hence, even
though the buffer could be operated on at the next clock edge.
bool recvTimingReq(packet) {
if buffer not occupied:
// push packet into buffer (size 1)
// schedule event to handle buffered packet in next cycle (using
nextCycle())
return true;
else:
return false;
}
Thanks,
Joel
On Tue, Jan 7, 2014 at 12:17 PM, Nilay Vaish <[email protected]> wrote:
On Mon, 6 Jan 2014, Joel Hestness wrote: Hey crew, I'm running into some
confusion about the semantics of the nextCycle() function in clocked objects.
In particular, it seems as though this function can return more than one cycle
in the future: Take as an example a buffer that is to accept input for a
receiving component. It is possible that the buffer receives an input signal
during the middle of one of the receiver's cycles (i.e. not on a receiver's
clock edge). In this case, the receiver's nextCycle() function calls
clockEdge(Cycles(1)). clockEdge(), in turn, calls update(), which will
increment the receiver's tick to be the tick of the next clock edge ahead of
curTick(). At this point, when clockEdge(Cycles(1)) continues executing, it
adds yet another full cycle to the receiver's next clock edge, and that is what
is returned from nextCycle(). Because of this, the buffer I've put together
using nextCycle() can only accept 1 input every other cycle when the sender and
r!
ec
eiver
clocks are out of phase. Is this intended functionality of nextCycle()? I need
a clarification before I start getting into a discussion here. Is this behavior
being observed in some existing code? From your description, it seems you have
made some modifications. -- Nilay
_______________________________________________ gem5-dev mailing list
[email protected] http://m5sim.org/mailman/listinfo/gem5-dev [1]
Links:
------
[1] http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
