derek/DRAMSys
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed bug in Fifostrict that caused deadlock

Browse Source
This commit is contained in:
gernhard2
2015-02-17 09:22:58 +01:00
parent f11adf51dc
commit beddeccb64
4 changed files with 39 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
dram/src/controller/scheduler/FifoStrict.cpp
View File

@@ -28,20 +28,9 @@ void FifoStrict::NotifyBeginRD()
if(buffer.size() > 0)
{
// If the new front element was orginally blocked, because it had to wait on the preceeding fron element, we have to unblock it.
// We only have to unblock if the new fron element is waiting for a RD/WR operation
if(commandIsIn(getNextCommand(*buffer.front()), {Command::Read, Command::Write, Command::ReadA, Command::WriteA})
&& !controllerCore.bankIsBusy(DramExtension::getBank(buffer.front())))
{
printDebugMessage("Unblocking front element.\n");
controller.scheduleNextFromScheduler(DramExtension::getBank(buffer.front()));
}
// If the new front element is on the same bank as the old one, we have let it make progress, even when the next command is not a RD/WR
// because we are not calling scheduleNextFromScheduler from the calling side
else if(oldFrontElementBank == DramExtension::getBank(*buffer.front()))
{
controller.scheduleNextFromScheduler(DramExtension::getBank(buffer.front()));
}
// If the new front element was orginally blocked, because it had to wait on the old front element, we have to call
// controller.scheduleNextFromScheduler explicitly, otherwise there will be a deadlock in the system
controller.scheduleNextFromScheduler(DramExtension::getBank(buffer.front()));
}
}