|
|
|
|
Are the Program Counter and Control Unit the same thing?
In the course material, both terms are used when discussing the Hack computer and the CPU at a high-level. They seem to be talking about the same thing.
|
|
|
No, they are different parts of the CPU.
Program Counter (PC) is a register, similar to A or D, but controlled differently. At the start of execution of the current instruction, the PC contains the memory address of that instruction. At the end of the execution cycle it should point to the next instruction to execute. Normally this is just the next address (so it should get incremented), but various branch or jump instructions can override that.
In the HACK architecture, the PC is connected to the program ROM, which in turn provides the instructions back to the CPU. This way the CPU tells the ROM which instruction to provide (or rather, the instruction stored in which address).
CPUs are complex circuits, which have to do a lot of things depending on the instruction. For example, in HACK if the instruction is @123, this means to store the binary representation of 123 in register A. If the instruction is D=M-1;JNE, then the CPU needs to process it in a very different manner. The Control Unit is responsible for decoding the instruction and orchestrating the whole process by setting or resetting various signals.
|
|
Administrator
|
I didn't spot where they talk about "Control Unit" -- could you site a specific section where they do and I'll take a look. I see where they refer to "control logic" in several places. In general, the "control unit" is the black box that implements the "control logic", so they are largely synonymous.
But neither is the same as the program counter, which is a specific component with a specific behavior. It is a counter whose output drives the address lines to the instruction memory.
The control unit takes the current instruction, as well as the flags from the ALU (the ng and zr outputs), and generates all of the signals that control the operation of the other components within the CPU as well as RAM. So we are talking about the signals that control writing values to any memory element (A or D registers, the PC register, or the currently addressed RAM address), the various multiplexers in the CPU, and the control signals to the ALU.
|
|
|
ouverson wrote
Based on what you both are telling me, it looks like all the "c" bits represent the Control Unit abstraction.
Am I correct?
More or less, yes.
The Control Unit is not shown as a separate part in these slides and it doesn't have to be implemented as such, but it helps to imagine there's such part. Its inputs are the current instruction (16-bit word), and various flags (in this case, ng and zr from the ALU). Its outputs are the "c" bits. They are as many as needed to tell the rest of the CPU what to do. For example, there will be a "c" bit, which tells the whether the A register should load its input value or not. There will be another "c" bit, which will tell the PC whether to jump or not.
|
|
Administrator
|
Yes, that is correct. Imagine all of those 'c' bits (along with the instruction itself) going into or out of a box labeled "control unit". The bulk of that unit is the instruction decode logic (which is shown as an explicit box in Figure 5.9 of the text).
Thanks. I see them now.
So a strong indicator that the control unit is not the same as the program counter is to note that in Section 5.1.4 they talk about the ALU, the Registers, and the Control Unit as being the three main components of the CPU. But in the last part of Section 5.1.5, which is talking about the registers, they include the program counter register, thus making it NOT a part of the control unit.
|
|
|
This post was updated on .
When I look at slide 32 I can see the ALU (I implemented that) and I can see the Registers (I implemented those), but I did not see the Control Unit; as I could see the PC (I implemented that) I figured that was the Control Unit.
Thankfully I had a gut check.
Thank you both for taking the time to clear up the confusion and explain in such a way that I could comprehend the abstraction.
When Noam is discussing "control bus" in the video (and in slides) the context is the Hack computer and not just the CPU. What is the scope of this Control Unit abstraction/black box?
|
|
Administrator
|
They left the control units off deliberately as that is "an exercise for the student," as the saying goes.
While it would have been clearer that there is a Control Unit and how it interacts with the various parts had there been a black box with that label and the various 'c' lines going to and from it, it also would have cluttered up the diagram pretty severely.
|
|
|
I know that one of the projects this week is to implement the CPU. That the heavy lifting with this job is to connect various and sundry "c" bits on ALU, PC, a couple of Registers, and a couple of Mux16s.
For instance, I know that 6 of the bits from the C-instruction input will be routed to 6 ALU inputs: zx, nx, zy, ny, f, no.
Nowhere (that I can recall) is this work described as the "Control" implementation.
As long as I'm on the right track I'm satisfied.
|
|
Administrator
|
While you could make a separate part named "Control", it turns out that many of the signals would be wires going from an input to an output and this HDL language is not well suited to that. Instead, you just implement the logic by wiring those signals directly to what they control.
|
|
|
Thank you for the confirmation.
|
|
Locked
