Ok, I see. Could you explain what exactly the drain is used for (and the context)?
-- Fernando A. Endo, PhD student and researcher Université de Grenoble, UJF France 2014-03-03 17:36 GMT+01:00 Srinivasan Narayanamoorthy <[email protected] >: > Hi, > > > I am talking about a special case here , when the op_latency > 1 in a > pipelined FU and a drain is in progress. This way, a drain can be signalled > even when the IssueToExecute queue is not empty.Thanks > Srini > > On 03/03/14, Fernando Endo wrote: > > Btw, you can patch gem5 to change this behavior, i.e., issueCycles being > any value from 1 to opLat. It's not hard. > > > > -- > > Fernando A. Endo, PhD student and researcher > > > > Université de Grenoble, UJF > > France > > > > > > > > > > 2014-03-03 16:12 GMT+01:00 Fernando Endo <[email protected] > (javascript:main.compose()>: > > > > > Hello, > > > > > > > By default, the functional units are freed in the next cycle and > hence Drain can be signalled (this is where the problem starts) ... > > > > > > > > > > > > In the stable version of 2012/06, the opClasses in the FUs can be > pipelined (issueCycle = 1) or not (issueCycle != 1). They're freed in > the next cycle, because the issueCycle = 1 by default. For non-pipelined > opClasses, gem5 creates an event to free the unit after opLat cycles, or > something like that. > > > > > > > > > Hope it helps, > > > > > > > > > -- > > > Fernando A. Endo, PhD student and researcher > > > > > > Université de Grenoble, UJF > > > France > > > > > > > > > > > > > > > 2014-02-20 21:41 GMT+01:00 Srinivasan Narayanamoorthy < > [email protected](javascript:main.compose()>: > > > > > > > Hi, > > > > > > > > I observed the following in the drain code. > > > > > > > > > > > > if (drained && !fuPool->isDrained()) { > > > > DPRINTF(Drain, "FU pool still busy.\n"); > > > > drained = false; > > > > } > > > > > > > > > > > > > > > > Consider a pipelined computation with op_latency > cycles(1). > > > > > > > > > > > > By default, the functional units are freed in the next cycle and > hence Drain can be signalled (this is where the problem starts) , though > the operation is still in the FU pipeline ( op_latency > cycles(1) ). Thus > the cpu's status can be Drained before the computation completes. > Though this is a squashed computation, the instsToExecute queue still fills > up when the FUCompletion event gets processed and fails any consequent > drainSanityCheck(). > > > > > > > > > > > > I am currently freeing units in the FUCompletion event, but this is > not good for performance. Please suggest a correct fix for this. > > > > > > > > > > > > > > > > Thanks > > > > Srini > > > > _______________________________________________ > > > > gem5-users mailing list > > > > [email protected](javascript:main.compose() > > > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > 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
