Error in proposed CPU implementation?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

cadet1620
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

SomeGuy
Well, that answers my question.
I didn't realize there was already a thread that solved this (sorry).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

cadet1620
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

cadet1620
Administrator
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.

Screen smashed by reset bug

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error in proposed CPU implementation?

ybakos
Look at how cool that pattern is.
Loading...