The way to think

[Aleksey]

Hello everybody! I really like the course, but I don't really understand how to implement a CPU. I have some small ideas that I have combined into an hdl file. After that, I used a kind of TDD approach - I ran tests, looked at the parts of the crash, and fixed the implementation. Should i use truth table of another way to implement it?I think I'm using more intuition.

[WBahn]

There are many ways to approach the design.

TDD is a great method, provided you are making considered and deliberate decisions in order to pass tests. If you are just randomly changing things hoping that some new test will happen to pass, then that's a very different matter.

Since the CPU data path layout is given to you, you can focus on the instruction decoding to generate all of the control signals. You certainly could do a truth table, but I sure would not want to. A fully enumerated truth table would have eighteen inputs (sixteen from the instruction and two from the ALU flag bits) yielding over 260,000 rows. You would also have numerous outputs of your truth table. So don't go down that rabbit hole.

The better way is to pick one of the control signals that needs to be generated, study what the functional purpose of that signal is, and then design the logic to generate that signal given a particular instruction (and, in some cases, the ALU outputs).

By functional purpose, I mean that while a particular signal might go to a Mux, it's functional purpose is not just to select which of the two input signals appears on the output of that Mux. What does it accomplish in the context of the CPU? Describe it succinctly in words. For instance, you might say that a particular control signal chooses whether the data from the A register or the M register (the data and the currently addressed RAM location) is given to the Y input of the ALU.

The next step is to take that description and write it in terms of what that signal needs to be in terms of the instruction (and whatever else might be needed). At that point you are in a pretty good position to design the logic to make things happen correctly.

[Aleksey]

Thank you for explanation. It is more clear now, before it seemed more randomly. Guess need to practise more.

[Ty]

I have found the CPU challenging as well.  There seems to be a specific implementation in mind; based on the chips we created.  I have been through several iterations and am finally close to the solution - I think.

[WBahn]

There very much is a specific implementation in mind. The data path is explicitly given to you. You could device a different one as long as it exhibits the same behavior -- but that is a road best left untraveled. You have to design the control logic and the authors definitely have a particular implementation in mind and are paving the path toward that implementation with the parts they have you construct. There are numerous ways of implementing the control logic (or at least certain pieces of it), but many would lend themselves to the use of intermediate gates that you aren't told to build. You can certainly build them if you want to and this is not as treacherous a path as playing with the data path architecture, but just keep in mind that there IS a pretty simple way to design the control logic using just the gates you have. By the same token, if you have a gate that you haven't used, then it might be worth pondering how that gate might be useful in designing the control logic because if it wasn't, they wouldn't have had you build it. There's a reason why you didn't build a two-input Nor gate, even though it is one of the fundamental building block of digital logic -- it turns out you just didn't need it for THIS digital logic.