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 receiver 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
>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
