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&#39;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&#39;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

Reply via email to