Stuck on CPU implementation

[burge91]

Not sure what to do. Not asking for tips, just moaning. Half the battle is confidence really, since I'm not even trying, it's like I've decided "this is where I will fail" for whatever reason I have decided that.

[OppaErich]

Hi,

I skipped that too. The leap was too big. And I have to make to many assumptions. For conditional jumps you need status signals, where do they come from ? I do have an idea of how to implement one but there's too much guess work.

Have a nice Sunday,
Stephan

[ivant]

Yes, the CPU is the hardest hardware project from the book. The good news is, that it consists of relatively simple parts. You can start by implementing the instruction decoder, because it drives a lot of the internal signals.

And you can leave the jump logic for last, because it's a bit confusing, but on the other hand it only changes the PC.

[cadet1620]

My suggestion for writing the CPU is to start by printing several copies of the CPU diagram so that you can write notes and draw on them.

I just created a PDF that prints the diagram to fill 8.5x11 / A4 paper. You can get it from this post: Printable CPU Architecture drawing.

Label all the parts' (c) inputs and outputs. Make sure you account for all the parts' I/Os. For the moment, don't worry about determining which Mux inputs are a/b. ("decode" is not a part; it represents the logic you will add in CPU.hdl)

You can start by writing the HDL for all the parts shown in the diagram.

Give the wires/buses names related to the part. For example:
    ALU(x=aluX, y=aluY, zx=aluZx, ..., out=aluOut, zr=aluZr, ng=aluNg);
You will end up changing some of these names as you analyze the interconnections between the parts and determine the logic/connections for the control signals.

Some things might be immediately obvious from the CPU diagram. For instance, aluX is directly connected to dregOut.  You can immediately use dregOut in the ALU's x input. (In most cases I like using the name of the part that generates the wire, hence dregOut. Control signals generated bu "decode" use the controlled part's name. Do what makes the most sense to you.)

Draw the data flow for various instructions like @1234, A=D, M=D, etc. Here's D;JEQ


You will see that there are some control signals that are only active during a-instructions and others that are only active during c-instructions. It is useful to create two control signals 'aInst' and 'cInst'.


Useful hardware trick: A Mux can be an And gate. If you tie 'a=false' then out = b & sel. You can do this with a Mux16 and get out[*] = b[*] & sel.

--Mark