1

Is my pipeline correct for the given sequence of instructions? If it is not, can you shine some light on where I went wrong? EDIT: I forgot to add the issue stage of the mul instruction. 

MUL R6, R7, R8
ADD R9, R10, R11 
ADD R11, R12, R13 
ADD R13, R14, R15 
ADD R19, R13, R10 
LW R2, R3
ADD R12, R16, R19
LW R5, R2
ADD R15, R20, R21

MUL     IF ID I  Y0 Y1 Y2 Y3 Y4 W  C
ADD        IF ID I  X0 W  r        C
ADD           IF ID I  X0 W  r         C 
ADD              IF ID I  X0 W  r          C
ADD                 IF ID I  I  X0 W   r       C
LW                     IF ID ID I  L0  L1  W   r   C
ADD                       IF IF ID I   I   X0  W   r   C
LW                              IF ID  ID  I   L0  L1  W  r  C 
ADD                                IF  IF  ID  I   I   X0 W  r  C
Corith
  • 65
  • 6
  • Are you sure you can have MUL and ADD in the W stage at the same time? Or is the register file multi-ported to avoid write-back conflicts between high `mul` and shorter latency instructions? It would be a good idea if you could link anything about IO2I; I've never heard of it. But I assume it's an in-order pipeline similar to a classic 5-stage RISC like MIPS. – Peter Cordes Mar 22 '20 at 15:42
  • @PeterCordes I actually do not know. We have discussed multi-ported registers files. But I think I will assume that it is not multi-ported and fix that. However, if we go on the assumption that it is multi-ported, how does the rest of the pipeline look? – Corith Mar 22 '20 at 15:47
  • @PeterCordes Yes, it is an in-order front end/issue, out-of-order write back, and in-order commit. [link](https://www.coursera.org/lecture/comparch/io2i-processors-qNtTe) – Corith Mar 22 '20 at 15:54
  • 1
    In that case the add after the load doesn't need to stall; or at least it can do X0 before stalling on a write-back conflict so the ALU result can be forwarded earlier in case any later instructions read it. Its inputs are coming from earlier ALU instructions that have all finished exec and can thus forward to it. (Or does your pipeline not have bypass forwarding? These details need to be in the question!) – Peter Cordes Mar 22 '20 at 16:10
  • @PeterCordes My apologies, I am new to the field and thought the r within the pipeline showed there was bypassing? Yes, there is full bypassing within the pipeline. I am not clear on why it would not need a stall, my thought on it was that then we will have two instructions in the write back stage? Would I need to stall one cycle after the X0 to prevent that? – Corith Mar 22 '20 at 16:18
  • 1
    You just said to assume that the register file was multi-ported so that wasn't a problem. And if it still is, my point was that you don't need to stall until *after* execution, when the instruction really is about to enter the W stage in the same cycle as an older instruction (so stall the younger). Re: using "r" to indicate bypass: I'm not an expert on diagram conventions for in-order pipelines; no modern x86 CPUs are in-order so I've never drawn one for a real-world optimization problem, only for SO answers (and maybe 20 years ago in an undergrad course). – Peter Cordes Mar 22 '20 at 16:25
  • But anyway, why is there an "r" *after* write-back? You don't need to forward if you've already written the result to the register file. Forwarding makes back-to-back `add` instructions 1 cycle latency, i.e. they can use the result of the previous instruction, so that means forwarding from X0 output to X0 / L0 / Y0 input. And BTW, all real-world CPUs forward so we don't need symbols. It seems normal to me to just assume forwarding; anything else would be garbage that we'd only analyze to see how bad it would suck to omit forwarding logic. – Peter Cordes Mar 22 '20 at 16:28
  • @PeterCordes I am not 100% accurate on my interpretation of the "r". It shows that it has been written to the physical register file and is waiting to be committed, in order. I miss read the lecture slides which was showing instructions being bypassed through the bypass path and one through the physical register file. Sorry for the confusion. – Corith Mar 22 '20 at 16:34
  • 1
    Ok, that makes more sense. In simple classic-RISC pipelines write-back is the last stage, and commit is part of it. (They basically decoupled the mul/div unit from the rest of the pipe, e.g. MIPS using special registers for it, instead of making alternate execution pipelines). I'm still not clear on exactly what could be rolled back / killed after an instruction goes through write-back or what the point of having an "r" and a separate commit stage is, though. – Peter Cordes Mar 22 '20 at 16:41
  • 1
    @PeterCordes My understanding, as an undergrad with only two architecture courses, is that the write back writes back to the physical register file, which allows for it to still be killed if needed before it is committed to the architectural register file since it was written out of order? If there is an exception or something, the speculative write to the PRF can be undone. On the lecture slides, it states that the r in the pipeline diagram means that it is not at the end of the re-order buffer? does any of that sound sensible? – Corith Mar 22 '20 at 16:54
  • 1
    Oh I see, your architecture allows out-of-order completion of instructions in general. MIPS made the mul/div unit separate, with it's own special hi/lo registers and rules about how soon you could read them, allowing simple MIPS pipelines to be short without duplicating the register file either, I think. I'm not sure if MIPS div exceptions were precise, if they existed at all. But your pipeline doesn't do that, instead it has Y0..4 stages for high-latency ALU operations on the same GP-integer regs as everything else. So yeah, that makes sense now, thanks for explaining. – Peter Cordes Mar 22 '20 at 17:06

0 Answers0