Pipeline diagram, Can ID start if previous EX is using same register?

Question

I have recently started with computer architecture.I am confused about a diagram I am trying to sort out. Based on the dependencies and in an effort to avoid Hazards I have designed the following table. However I am not sure if, 2 stages can actually read from the same register at the same time. Here the table and the mips with highlighted confusion areas.

EDIT: Alternative added

Is it right to remove one stall, since the value is for r0 is already processed?

Answer 1

"Using" is too general, you need to split between reads and writes to a register. If you ask about "reading at the same time" - absolutely, that's the whole point in pipelining. As long as the register value isn't changed, there's no problem in reading it over and over. In reality, the ID and EX stages are not using the same resource, so there's no conflict - the value that the EX stage reads comes from latches that the ID stage wrote to in the previous cycle.

The register which you think of as a single global value, has in fact multiple copies along the pipe, each corresponds to its value at some point in the program. If you take the last 2 instructions for e.g, both read $r0 so the ID stage will read it out of the register file for the OR on cycle 7, write it to the latch, and then read it again on cycle 8 for the XOR, while the OR is at the EX stage and simultaneously takes the latched value from the previous cycle.

Now the real problem comes when you have a data hazard such as the one caused by the first instruction. Since the value of the register at any given stage must reflect the true value it has according to program order, you'll have a problem if you try executing the EX stage for the Sub instruction on cycle 2, because $r0 value was read on the previous cycle without representing the result of the Add. In fact, the value will be ready in the register file only after the Add completes the writeback at cycle 4. This is called a RAW (read after write) conflict, and must be fixed or the program will have bogus results. One way to solve this is by adding a stall once you detect this hazard (as the diagram shows with asterisks) - when the instructions reading $r0 finally continue, they'll have the updated value (post Add) already written to the latches. Another (more useful) solution is to add special logic to bypass the new value once it's ready to all pipestages that require it. This may still require a stall in this case since the instructions are back-to-back so you won't even have time to perform the operation before the next instruction needs it.

One last note - keep in mind that processors, even ones as simple as a pipelined mips, are meant to lie to you. They make you believe you're running the program you wrote, while in fact they do all sorts of things internally without telling you (a slightly more advanced example of this is out-of-order execution). In this case, they make you think the instructions are performed serially, when in fact they speculatively start each one before the previous one was finished (or even executed). This of course works most of the time and makes the processor perform much better in terms of instructions throughput (or IPC), but in some cases (data hazards such as this, control hazards, etc..) this may break your program completely, so they must hide this by doing things like adding stalls or flushing the pipe.