what does the C mean in the block

[woodylcy]

I can't figure out what's the C on A Register  , on Mux and on decode.

    I hope someone can help me about this. explain the C

[cadet1620]

woodylcy wrote

I can't figure out what's the C on A Register , on Mux and on decode.

I hope someone can help me about this. explain the C

The C signals in the CPU block diagram are "control" signals. The Instruction Decoder generates the control signals from the bits in the instruction. The control signals are used to make the rest of the CPU do what it needs to do to execute the instruction.

The simplest control signal would indicate that the instruction is an A-instruction. This signal could be named aInst. Its implementation is
    Not(in=instruction[15], out=aInst);
aInst will be used to route instruction to the A-register and store it.

Although you can use instruction[15] wherever the CPU needs to know if it is executing a C-instruction, it's more understandable to create a cInst control signal. (And a lot less typing!)
    Not(in=aInst, out=cInst);

The CPU also needs to store the output from the ALU into the A-register, depending on the destination bits in the C-instruction, so you need a destA control signal. This signal is only active during C-instructions. Its implementation is
    And(in=cInst, b=instruction[5], out=destA);

When does the A-register need to be loaded? Whenever aInst or destA is true.
    Or(in=aInst, b=destA, out=loadA);
What data needs to be loaded into the A-register? A multiplexer chooses that based on aInst.

Other control signals are similarly generated by further decoding the C-instruction, and they are used to control other parts of the CPU.

--Mark

[woodylcy]

Oh。。 I am so glad you replied me。
I got some of your idea。 But I am still confused with this：

     When it's a A instruction，  the code also executes the function that used to decode C function。
for example。 a A instruction：@7         0000 0000 0000 0111
     
     And(in=cInst, b=instruction[5], out=destA);  will change the control bit :destA  to 0。 This
 may be same to other control bits, such as writeM、 destD....

I mean when executing A instruction, do we only need to store A to ARegister?  But the .hdl code will execute other functions used to execute C instruction.    

thanks for your help, dear cadet1620

[woodylcy]

I just changed my .hdl code a little, it works now. But I still have some problems.  The outM should be set to random value, how to do is? 

   Does it mean when execute A instruction, changing the control bits won't matter?

The logic used to decode C instruction also decodes the A instruction.  

[cadet1620]

HDL doesn't execute line by line like a programming language.  It's more like a set of instructions telling you how to build a circuit board.  You can change the order of the lines in the Parts section and the HDL will still work.  It doesn't matter what order you solder the parts into the circuit board as long as all the parts get put in.

Once you apply power to the circuit board, all the parts are operating continuously.

When an instruction is decoded by the CPU, all of the control signals are set simultaneously.  When the CPU is executing an A-instruction, the ALU is computing something--we just don't care what it is since it won't be stored anywhere.

It's like in the ALU where the ADD and the OR are always computed and a Mux chooses the correct one based on the f control signal and the other one is ignored.

(In real hardware there's no such thing as simultaneous.  The control signals can be glitchy for a few nanoseconds as the instruction bits arrive at the CPU at slightly different times.  That's one of the reasons why we need the system clock and the DFFs.)

--Mark

[cadet1620]

It's been a while since I read chapter 5.  If the book uses the word "random," that is a minor error.  The outM signal during A-instructions should be described as "undefined."  Any value that is output is OK.  (In fact, it's the throw away output from the ALU that I mentioned in the previous post.)

--Mark

[ohmganesha]

cadet1620 wrote

...
Once you apply power to the circuit board, all the parts are operating continuously.

When an instruction is decoded by the CPU, all of the control signals are set simultaneously.  When the CPU is executing an A-instruction, the ALU is computing something--we just don't care what it is since it won't be stored anywhere.

It's like in the ALU where the ADD and the OR are always computed and a Mux chooses the correct one based on the f control signal and the other one is ignored.

(In real hardware there's no such thing as simultaneous.  The control signals can be glitchy for a few nanoseconds as the instruction bits arrive at the CPU at slightly different times.  That's one of the reasons why we need the system clock and the DFFs.)

--Mark

Thanks for that explanation. My minecraft computer works and behaves exactly as you describe! Although my control signals are glitchy for almost a full second. I had similar thought and questions as woodylcy. But they answered themselves through building it :)