 This time we'll walk through the critical path for a handful of instructions. If we start with an add instruction, then our add instruction begins over at the program counter. We have to wait for the program counter to complete before we can do anything else. Once we've read the address from the program counter, it's sent over to instruction memory, but it also goes off to the adder. It would get its address incremented so it can point at the next instruction, but most of that workflow is not really going to be interesting. We're going to spend much more time doing things like decoding our address, fetching registers, and doing addition to worry too much about how long it takes to update the program counter. So coming out of the program counter, the address also goes to instruction memory, we fetch our instruction, and then we begin decoding it. We need to do a couple things here now. We'd like to get the data out of our registers, and that will require knowing the RS and the RT fields. Those come directly out of our instruction so we can process them pretty quickly. Now, before we can run the ALU, we need to know what its inputs are. So I get one of my inputs directly from the registers. The other one comes through this multiplexer, but setting the multiplexer to take the result from a register requires that our control have completed first. The control unit can begin its processing right after the instruction memory has produced the instruction, so any processing that needs to be done here can be done at the time that we're doing things like fetching registers. So in most cases, that data will be available. We can set the multiplexer by the time that the data arrives from the registers. But we'll still have to wait for this multiplexer to process the two inputs, select the registers before it can send that data to the ALU. Once the ALU has that data, it can send it to the mem to reg multiplexer, which will select it over data memory. Again, we need the control signal for this multiplexer, but that should have already been completed by the time we get here. Our control signal needed to be set for this multiplexer when it ran, so all of our control signals should be pretty much set by this point. Then this multiplexer will take a little bit of time to process, and it will send the results back towards memory. Doing so, we have to make sure that, well, we've selected the correct output register, and we've decided that we want to write two registers. But again, all of this control should have completed by this point. So our ad instruction is pretty simple. We're waiting for a handful of other instruction memory registers, multiplexer, ALU, multiplexer. Other things are generally going to be able to happen in parallel. Our control unit is probably not going to take longer to set all of its control signals than the registers will to produce data. If the control unit did end up taking more time than the registers, then it could become a bottleneck instead of the registers. And how to immediate instruction is pretty similar. We start with the program counter, we move to the instruction memory, we use the registers, the control unit, the ALU, the multiplexers. But this time we only take one result out of our registers, but instead we take the other result from our sign extension unit. So generally our sign extension unit is not going to take a whole lot of time. It really just takes one bit from your instruction and makes 16 more copies of it. So that really isn't going to take a whole lot of time. So that should be able to happen in parallel with the registers or potentially the control unit. If the control unit was slow. If we look at say a load word instruction, this one has some extra stuff. We still got a lot of the same stuff we did with the at immediate instruction. We'll have the program counter, instruction memory, registers, sign extension unit. We do an at immediate instruction effectively. But then we send that address to the data memory. Now we have the additional cost of the data memory as well. Then the data memory will send the results to the mentor edge multiplexer, which will send the results back to the registers. So again a load word isn't going to be too much different from an at immediate. Except that we'll have to use the data memory as well. Store word instruction is pretty similar to the load word instruction. We're going to go through the same main path. But this time we don't actually need to write anything back. Our critical path effectively ends once the data has been stored into data memory because that's all we're asking this instruction to do for us. We don't technically need to include things like the mentor edge multiplexer and the second visit to the registers because they're not relevant to this instruction. The branch instruction is also sort of like an at instruction. We start with our program counter. We use the instruction memory, the registers, the ALU. We do some subtraction here. But this time we're interested in how we change the program counter. In order to decide whether we want to take the address of the next instruction or the address of our branch target instruction will depend on the results of the ALU. So now my critical path will involve going through the program counter instruction memory, registers, ALU, then the branch multiplexer, the jump multiplexer, and back to the program counter. If my hardware was really horrible, I could potentially be spending more time up here with this sign extension unit and this adder than down here with registers and an ALU. But you would have to have some really weird hardware that somehow manages to take longer to do an addition operation than it does to do a subtraction operation. So again, the hardware up here is going to be a whole lot simpler. So our critical path is generally going to involve the registers of the ALU. A jump instruction is really, really simple though. In this case, we want to update our program counter. So we start with our program counter. We get our instruction out of memory and then we process it. Really, all it does is it's going to go up here and get modified a little bit with the address of the next instruction as well as adding in a couple of zeros. Then it gets passed to the jump multiplexer. Jump multiplexer requires the signal from the control unit to say that yes, we should take this, jump. And then it writes the results back to the program counter. So in this case, the control unit is probably going to be interesting because the control unit is going to take longer to determine what those control signals are than it will to actually put together this jump address. This jump address is really just built by shifting a bunch of bits around a couple of lines from program counter plus four, a couple of new zeros coming in, as well as the bits coming straight out of the address. So none of that is really going to require any extra time. So we have to make sure that our control unit is capable of setting the jump multiplexer before we allow it to execute. Thank you.