CPU.hdl passes, Computer.hdl does not (upon reset signal)

[rpc0618]

I'm confused about what to do here. My first instinct after testing my Computer.hdl with ComputerAdd.tst was to just reset the ARegister when the reset button was pushed, as it seemed to expect the A Register to be reset as well as the PC. But then when I ran ComputerMax.tst, I got the opposite result where the A Register was reset when it was not supposed to be (whether I had "fixed" the A Reg to reset specifically or not).

I hope someone is awake out there and can help me. :) If not, I guess there's always tomorrow. :-P

The first picture is from ComputerAdd.tst :



and the second picture is from ComputerMax.tst :


If you like, I can email my source .hdl's to anyone willing to help me out on this one.
Thanks!

 - Rich

[rpc0618]

So I was messing around with bitbucket, and trying to get to understand the whole GIT thing...

and now you can find my cpu.hdl from this link:

## DELETED ## ;-)

after clicking PROJECTS, then 05. I'd post a direct link to the .hdl, but given the strange and long folder name, i'm wondering if it's a temporary one.

Peace,

Rich :)

[cadet1620]

The problem is the Mux in your Computer.hdl.

Reset in the Hack computer is a synchronous event; it should only take effect when the clock ticks.

What's happening is that the Mux causes reset to asynchronously force the input address to the ROM to 0 during execution of the current instruction. This results in the instruction at address 0 executing instead of the final instruction of the program.

In ComputerMax.tst, an @0 executes instead of the @14 at address 14.

ComputerAdd.tst is a bit odder; add.hack doesn't end in a loop so the instruction that should have executed instead of the @2 was the instruction at address 6 which is off the end of the loaded program! ROM is initialized to 0 so the test normally executes an @0 instruction at address 6.

You can look at the test code by loading the .hack files into the CPU Emulator.

--Mark

[Now that we've identified the problem, please delete the link to your source code. We don't want solutions to remain on the forum.]

[rpc0618]

Thanks!!!

And will do.

On Fri, Jun 7, 2013 at 10:51 AM, cadet1620 [via Nand2Tetris Questions and Answers Forum] <[hidden email]> wrote:

The problem is the Mux in your Computer.hdl.

Reset in the Hack computer is a synchronous event; it should only take effect when the clock ticks.

What's happening is that the Mux causes reset to asynchronously force the input address to the ROM to 0 during execution of the current instruction. This results in the instruction at address 0 executing instead of the final instruction of the program.

In ComputerMax.tst, an @0 executes instead of the @14 at address 14.

ComputerAdd.tst is a bit odder; add.hack doesn't end in a loop so the instruction that should have executed instead of the @2 was the instruction at address 6 which is off the end of the loaded program! ROM is initialized to 0 so the test normally executes an @0 instruction at address 6.

You can look at the test code by loading the .hack files into the CPU Emulator.

--Mark

[Now that we've identified the problem, please delete the link to your source code. We don't want solutions to remain on the forum.]

---

If you reply to this email, your message will be added to the discussion below:

http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/CPU-hdl-passes-Computer-hdl-does-not-upon-reset-signal-tp4026950p4026958.html

To unsubscribe from CPU.hdl passes, Computer.hdl does not (upon reset signal), click here.
NAML

[retepaskab]

It's more like an unneeded part problem than asynchronous-synchronous problem.
The programs executed are correct both ways.

Even, the computer.hdl specification says:
When reset is 1, the execution of the program restarts.
So I see no reason to execute one more instruction at PC :)

But correcting it gives some insight that we are doing circuits on this level, not sequential programs.