Error in proposed CPU implementation?

[SomeGuy]

After looking at chapter 5's proposed CPU implementation, I noticed that the A register's output is directly connected to the PC register's input.

To me, it seems that doing this will sometimes give errors.
Consider the instruction A=0;JEQ
Let's say that at the time this instruction is reached, PC=1, and A=1
What should happen:
  the value 0 is evaluated
  A is set to the ALU's output value (zero)
  PC is set to A's value (zero)
What would happen in the proposed implementation:
  the value 0 is evaluated
  A will be set to this value after the next tock (zero)
  PC's input is still A's current value (one), so it will be set to one after the next tock

I solved this by adding a Mux that sets the input of PC to be either the ALU's output or A's output, depending on whether A is a destination of the C-command or not.

[cadet1620]

SomeGuy wrote

After looking at chapter 5's proposed CPU implementation, I noticed that the A register's output is directly connected to the PC register's input.

To me, it seems that doing this will sometimes give errors.
Consider the instruction A=0;JEQ
Let's say that at the time this instruction is reached, PC=1, and A=1
What should happen:
  the value 0 is evaluated
  A is set to the ALU's output value (zero)
  PC is set to A's value (zero)
What would happen in the proposed implementation:
  the value 0 is evaluated
  A will be set to this value after the next tock (zero)
  PC's input is still A's current value (one), so it will be set to one after the next tock

I solved this by adding a Mux that sets the input of PC to be either the ALU's output or A's output, depending on whether A is a destination of the C-command or not.

In fact, the CPU Emulator works the way you expect. There's a forum thread with more details about this.

--Mark

[SomeGuy]

Well, that answers my question.
I didn't realize there was already a thread that solved this (sorry).

[cadet1620]

No worries about missing the old thread. It's good that you are understanding the material well and looking closely enough at the design to see this problem.

Another interesting question about the proposed design is:
    What devilry occurs during reset if the instruction at RAM[0] is
    AM=A+1 ?
and how do you prevent it from happening.

--Mark

[SomeGuy]

I think that, while reset is asserted, the contents of increasing RAM addresses will be changed on each cycle. At a higher level, this could result in confusion if a programmer isn't aware of this effect.
Is this what you're getting at?

As for how to prevent it, I guess we could unassert the 'writeM' pin and the 'load' pins on register A and D while 'reset' is asserted.

Good question. Really. I would have never thought of this.

[cadet1620]

Yes, that's the problem. The instruction at 0 executes repeatedly during reset. You can watch this happen in the Hardware Simulator by loading AM=A+1 into RAM[0], setting reset=1, and letting it run. It will eventually write a counting pattern to the screen.



You don't need to specifically add reset to individual control signals; it's better to have master signals aInst and cInst (you may already have these if you didn't use instruction[15] directly). Then these signals can be anded with reset and all the other control signals will behave correctly.

--Mark

[ybakos]

Look at how cool that pattern is.