Honored Contributor
Honored Contributor
Originally Posted by mshatz I don't understand this comment. The slave is my own, I know for sure that it doesn't generate wait states (i.e. every clock it can accept a new address), just one clock of pipeline latency. So all wait states come from either SOPC (unlikely) or from Nios itself. --- Quote End --- I was thinking of non-pipelined single transfers. The pipeline latency becomes a wait state on the nios (probably unless you are doing cache line reads!). --- Quote Start --- Originally Posted by dsl it is worth noting that the 'late result' is actually a 'normal result' - and happens when the resultant value has to go via the register file.
i think non 'late result' instructions use special logic to forward the output of the alu back to its inputs. Originally Posted by mshatz Of course, they had to build forwarding logic for single-cycle instructions. However, I don't think that 'late result'='normal result without forwarding'. Even without pipeline bypass results of 'combinatorial' instructions would be available one clock earlier than 'late result' --- Quote End --- I was thinking that that the instruction pipeline does 'read reqister file' - 'execute' - 'write register file' over 3 clocks for each instruction, and that a 'read' would only give the new data the clock after a 'write' of the same register. Thinking further about the M9K rules, for dual access using the same clock it is possible for concurrent read/write to return the new data on read - which might allow for only a single clock delay. Maybe the extra clock comes from the delays added by the decision code.
