CPU chapter is frustrating

[nrivera]

The CPU chapter was brutal.

Unfortunately, is unclear how to build it. Watched the video many times, read the chapter several times, I spent about 10 hours.

I'm using the 2nd edition of the book, along with the coursera videos, the language is unclear and focus in odd things, like instruction colours.


A few tips:
- Look at the presentations on https://www.nand2tetris.org/course, they have extra material and the edition 1 of the book seems to be more clear in some aspects. This explains everything that was not in the book and videos.
- The ALU diagram specifies which value is X and Y   ">[]"  top is X, bottom is Y. CPU architecture diagram might give you the impression of the opposite.
- ALU generates C instructions
- Every part before being feed, the instruction should be tested if it's type A or C and act accordingly.
- When the A register holds an address, it was 1 bit less (15 - op code) so the output should skip that one
- when writeM is true, addressM and outM should be populated from two different sources, and with different length.

[WBahn]

It's hard to tell what you mean on some of these.

For instance: "when writeM is true, addressM and outM should be populated from two different sources, and with different length."

As the proposed CPU implementation diagram shows, addressM is ALWAYS the current contents of the A Register, while outM is ALWAYS the current output of the ALU.

[nrivera]

Except one is 15 bits.

The only way to build this cpu was to create a dfd diagram. Funny thing I discovered the older presentations after, where everything is explained very detailed, with information not in the book which is baffling.

[rleininger]

I have a few random observations is response to your original post.  I also struggled quite a bit with building the Hack computer in the hardware simulator.  Even simple computers, such as Hack, are still rather complicated logic devices.

Remember that the book is intended to be a textbook for a college-level course in computer organization, design, and operation. It is not a how-to, step-by-step guide for how to build a simple, simulated computer.  As a textbook, it should be expected to be filled with problems for the student to solve (and it is!).  However, if used in an actual in-person class, the student would have the benefit of pretty immediate feedback to questions from the instructor – especially where the specification is unclear or completely silent.  It’s a little different in the MOOC world, where questions are answered asynchronously in forums such as this one.

The link you provided to the presentations on the From Nand to Tetris web site were originally the slides from the videos that are in the Coursera MOOC.  The slides have been substantially augmented in the last few months subsequent to the release of the 2nd edition of the book.  One would hope that perhaps new videos are also forthcoming, but I would be a lot happier if they would clean up the software tools provided by the course.

One of your “tips” is that “ALU generates C instructions.”  I think it is closer to a true statement to say that the ALU performs the computations required for C-instructions.  Some C-instructions will require additional logic.

The A register always contains 16 bits.  HDL allows you to use any fractional part of those bits for whatever purpose you desire when you are making connections between components.  

[WBahn]

I'm not sure what you mean by a "dfd diagram". Could you elaborate?

The memory (both the ROM and the RAM) use 15-bit address spaces. This is intentional as utilizing the 16th bit, while certainly possible, introduces complexities that simply aren't worth the effort for the purposes of the course. Instead, the design of the instruction set is intended to make using the 15 bits that count as easy as possible. For instance, since the A-type instructions are indicated by the msb being zero, you don't have to do anything special to load the 15-bit unsigned integer from the instruction into the A Register while forcing the msb to be zero -- you simply load the entire 16-bit instruction and it does exactly what you want. The instruction set could just as easily have had the A-type instructions be indicated by having the msb be a 1, in which case you would have had to deal with these issues.

As for AddressM, that is just a matter of picking off the lower 15-bits of the A register, which is very straightforward. There are NO checks involved and you don't need to do different things under different situations. The lower fifteen bits of the A Register ALWAYS go to the AddressM bus. It doesn't matter whether the A Register currently holds a RAM address or not, the RAM always accesses the address corresponding to the lower fifteen bits of whatever happens to be in the A Register. It is up to the programmer to ensure that the A Register contains the correct address when it matters -- namely when M is either one of the sources for a an ALU operation and/or a destination in a C-type instruction. At all other times the fact that the RAM is seeing something that isn't really an address is immaterial because nothing gets done with it -- the RAM cell that is decoded is neither read from nor written to.