sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

The reason is that the event is supposed to put the instructions ready to execute for next cycle. And the FUCompletion event has a lower priority than CPU tick event. It is called after the iew->tick() for current cycle has already been executed and the issueToExecuteQueue has already advanced this time. And assume the issueToExecuteLatency is 1, to catch up, the increasement should be made at access(-1) instead of access(0). Otherwise I found it could increase the actual op_latency of the instructions to execute by 1 cycle and potentially put the simulated CPU into a permanent idle state.

Browse source 
Signed-off by: Ali Saidi <saidi@eecs.umich.edu>

--HG--
extra : convert_revision : dafc16814383e8e8f8320845edf6ab2bcfed1e1d
This commit is contained in:
Ke Meng 2008-01-14 11:47:32 -05:00
parent c08b7802a9
commit 0b6876a0c0
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
src/cpu/o3/inst_queue_impl.hh
View file

@ -667,7 +667,7 @@ InstructionQueue<Impl>::processFUCompletion(DynInstPtr &inst, int fu_idx)
// @todo: Ensure that these FU Completions happen at the beginning
// of a cycle, otherwise they could add too many instructions to
// the queue.
issueToExecuteQueue->access(0)->size++;
issueToExecuteQueue->access(-1)->size++;
instsToExecute.push_back(inst);
}
@ -752,7 +752,7 @@ InstructionQueue<Impl>::scheduleReadyInsts()
FUCompletion *execution = new FUCompletion(issuing_inst,
idx, this);
execution->schedule(curTick + cpu->ticks(issue_latency - 1));
execution->schedule(curTick + cpu->ticks(op_latency - 1));
// @todo: Enforce that issue_latency == 1 or op_latency
if (issue_latency > 1) {