O3: Don't assert that nothing is pending in the decoder at the start of a cycle.
Review Request #777 - Created July 10, 2011 and submitted
| Information | |
|---|---|
| Gabe Black | |
| gem5 | |
| Reviewers | |
| Default | |
| ali, gblack, nate, stever | |
O3: Don't assert that nothing is pending in the decoder at the start of a cycle. The decoder clears out incoming instructions from fetch on a squash, but there may be instructions on the wire incoming from fetch which don't get cleared. Because the decoder is considered squashing, it doesn't actually process any more instructions as they come in. The instructions that were on their way would then sit in the "insts" list until the next cycle, tripping qn assert. It's ok for them to be there in that case because the decoder will just ignore them. Because "insts" is a queue and can't be scanned to verify that all instructions left on it are squashed, this change simply gets rid of the check.
Posted (July 12, 2011, 12:22 a.m.)
I'm pretty sure I wanted to get rid of this before, but it turned out it was a different issue. I think korey explained it previously, maybe he remembers.
Posted (Aug. 1, 2011, 4:22 p.m.)
-
src/cpu/o3/decode_impl.hh (Diff revision 1) -
I believe this is a good comment. It's enforcing that Decode can only receive instructions one of two ways: (1) Through the instruction lists (insts) when the Decode stage is in a "Running" state (2) Through the skidBuffer when Decode has been previously blocked in a prior cycle. It looks to me like that the "sortInsts() function should really be placed on line 578 so as to ensure that Decode always has a chance to block before assuming it can grab fresh instructions from Fetch, however it works because on line 747 Decode blocks if there isn't enough room in the next stage to pass instructions. Block entails saving the leftover instructions to the skidBuffer and setting the state to "Blocking". Fetch will see that "Blocking" state on the next cycle (in the checkSignalsAndUpdate function) and then not pass any new instructions into Decode thus not triggering that assert. If that assert is being triggered I'd assume what I described above is broken.
Posted (Feb. 29, 2012, 12:22 a.m.)
Gabe, can you mark this patch as submitted? Ali committed this change some time back.