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 rec
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
