# How to evaluate the clock cycle for MIPS single cycle CPU

The Situation

I'm trying to read the book 'Digital Design Computer Architecture'.
In the part of Performance Analysis(7.3.4 in the book), Author refers to clock cycle for MIPS single cycle processor. But I think there's something wrong with author's evaluating clock cycle.

Author says,

T(Clock cycle) = T(pcq_pc) + T(mem) + Max[tRfread, t(sext)] + t(Mux)
+ T(ALU) + T(mem) + t(mux) + T(RFsetup)


But I think clock cycle 'T' would be ( if T(RFread) > T(mux) + T(sext) )

T(Clock cycle) = T(pcq_pc) + T(mem) + T(RFread) + T(ALU) + T(mem) + T(mux) + T(Rfsetup)


Since I think the MUX followed by ALU already selects known sign-extend immediate before register value(the pin RD1 in below diagram) is known.

and if T(RFread) is less than T(mux) plus T(sext).

T(Clock cycle) = T(pcq_pc) + T(mem) + T(sext) + T(Mux)
+ T(ALU) + T(mem) + T(mux) + T(RFsetup)


Some referenced information by the book.

• T(pcq_pc) is propagation delay for PC.
• T(mem) is read-propagation delay for instruction memory and data memory.
• T(sext) is propagation delay for Sign Extend logic.
• T(mux) is propagation delay for MUX.
• T(ALU) is propagation delay for ALU.
• T(RFsetup) is setup time for Register file.(Register value is written on positive clock edge)

Here is Diagram for MIPS single cycle CPU. Is my thought correct? If you think author is right, Could you tell my why?
Any help would be awesome!

• Please include the picture in the post properly, and credit the source. – Raphael Apr 15 '13 at 19:51
• I can't post the picture, since I have no reputation – inherithandle Apr 15 '13 at 23:23
• But please give the author for the book, and the year published. – Wandering Logic Apr 16 '13 at 13:32
• authors are David Harris and Sarah Harris. Published date March 16, 2007 – inherithandle Apr 17 '13 at 2:09

Now that you have (dramatically) modified your question:

The author of the book is correct. RD1 can not be on the critical path because the time to read RD1 is the same as the time to read RD2, but then RD2 needs to go through the mux in front of the ALU. If the time to read RD2 > T(Sext) then RD2 is on the critical path, if T(Sext) > T(RFread) then Sext is on the critical path. That's what the Max() operator does. Either way T(mux) needs to be in the expression.

Your last expression with T(Sext) +T(mux) is the same as what the author's expression gives in the case that T(Sext) > T(RFread). But your middle expression is wrong: if T(RFread (the read of RD1)) > T(Sext) + T(mux) then T(RFread (the read of RD2)) + T(mux) > T(Sext) + T(mux) + T(mux) > T(Sext) + T(mux). So you need to have T(mux) in the expression no matter which T(RFread) or T(Sext) is larger.

The basic rule (which you are mostly correctly following) is: use Max() for things that proceed in parallel, + for things that follow in sequence. The mux comes after both the Sign extend and after the read of RD2.

• Very sorry. It was errata. I have corrected expression. Could you check my question more? – inherithandle Apr 16 '13 at 15:21
• Why MUX have to wait RD2 value? the module control sets the MUX select ALUsrc to 1. MUX could select sign extended value BEFORE RD2 value is known, right? That's all I'm doubt about. – inherithandle Apr 16 '13 at 17:59
• You can't set the clock differently for different instructions, so the useful thing to do is to estimate the best clock speed you could achieve. You seem to be assuming that you are doing the analysis just for the special case where the control for the SrcB mux is set to 1. Presumably the author was not making that assumption, but was doing the more general analysis. – Wandering Logic Apr 16 '13 at 19:06
• I don't understand why author make such assumption. You said we need to use Max() for things that proceed in parallel + for things that follow in sequence. the module Control is also connected in parallel with the module Register file. Is it obvious that the module Control has ALUsrc set to 1 before operation of register-read? – inherithandle Apr 16 '13 at 23:46
• A reasonable first step is to try to understand the data path completely independently of the control. You are absolutely correct, though, that it is a common problem with this style of pipeline that the ALUSrc control bit is often on the critical path. You haven't told me what the question is (or even who the author is) so I can't comment on why he or she made the assumptions they made. – Wandering Logic Apr 17 '13 at 1:49