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]>: > 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
