>From or1200_ctrl.v, l.rfe can spend as little as two cycles in the execute stage, verified in RTL simulation, while multicyclecnt[2:0] gets decremented from 1 to 0. It appears that SR is ready after the first cycle, so it is probably a instruction fetch decode constraint (maybe because there is no delay slot???).
---Matthew Hicks On Sun, Apr 29, 2012 at 2:37 PM, Peter Gavin <pga...@gmail.com> wrote: > On Sun, Apr 29, 2012 at 9:32 PM, Matthew Hicks <firefal...@gmail.com> wrote: >> Why do we need to make sure rfe and mfspr spend at least two clock >> cycles in the execute stage. I am working on a bug detection and >> recovery system, and I am trying to write a stateless (i.e., I can >> only read the current flip-flop values to determine if the bug is >> active) detector for the rfe bug from a year ago. I can not find a >> way to tell if rfe spent a single cycle in the execute stage, which I >> might be able to do if I understand why it requires two cycles in the >> first place. > > Well, I can think of a good reason for mfspr needing 2 cycles. It > lets you read from the GPRs using certain SPR addresses, and the > processor has to stall in order to free the read port on the register > file in that case. > > rfe is probably handled at the last stage in the pipeline (can't say > for sure, I haven't looked at the RTL). So that means it will end up > flushing the pipeline when it's executed. So there actually be more > than 2 cycles between it and the next instruction to be completed. > > -Pete _______________________________________________ OpenRISC mailing list OpenRISC@lists.openrisc.net http://lists.openrisc.net/listinfo/openrisc
