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] >: > 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] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
