Troubles making my CPU.hdl... resolved after a week of head-scratching.

[Jack Draak]

I think it was about a week ago that I began working on my CPU design (yup, 6-days since the first real commit). Just minutes ago, I finally passed the CPU unit-test.

A week ago, I was using LogiSim to try to help me visualize and implement a functional design. My first CPU.hdl was virtually devoid of remarks, and may not have even mirrored my incomplete (and also non-functional) design from LogiSim due simply to it's degree of complexity (and my inability to hold an abundance of thoughts in my head at once).

One thing I did early-on, and which I believe wasn't technically required, was to make a "Splitter" chip to help me with my decoding; I feed the IN:instruction bits to Splitter16, and can make natural labels for it's decode output, i.e. a=jg, b=je, c=jl, where abc are the jump bits of the c-instruction.  As I say, I don't feel it was required, but the use of natural wire labels was a boon to my ability to grok the rest of my design implementation as I was building it.

The next thing I must credit for my success (other than determination) was taking the time to try to fully-think-out various sub-processes, and properly documenting my thoughts in remarks and pseudo-code.

...

If you're still looking for more direction.....

At first I was fairly confident that "things would take care of themselves" in regard to the different behavior we need from either A-cycles or C-cycles....

That might actually be true, to some degree, but when I finally passed my unit-test... was only after I took the time to explicitly wire my CPU so that it behaves in different ways for @ or C cycles (well, obviously, but in contrast to "things taking care of themselves" methodology I was trying to employ, I made a more defined split around @/C handling.

...

Phew! Well, now to try to tackle the Computer.hdl.... I wonder if I learned anything this past week that will make this chip easier than the CPU was for me... :)

[Jack Draak]

Wow, okay... talk about elegance in design... Computer.HDL was rather anti-climactic for me.  I added zero documentation. It's only 3 chips. The natural wire labels are essentially self-documenting.

[cadet1620]

Jack Draak wrote

One thing I did early-on, and which I believe wasn't technically required, was to make a "Splitter" chip to help me with my decoding; I feed the IN:instruction bits to Splitter16, and can make natural labels for it's decode output, i.e. a=jg, b=je, c=jl, where abc are the jump bits of the c-instruction.  As I say, I don't feel it was required, but the use of natural wire labels was a boon to my ability to grok the rest of my design implementation as I was building it.

Yes, as in software, it is best to have wire names that mean something.

Multiplexors can do lots of things besides just selecting data. You can combine the two ideas you developed, named control signals and instruction-type enabling of those control signals, using a Mux16.

Not (in=instruction[15], out=aInst);
Not (in=aInst, out=cInst);
Mux16 (sel=cInst, a=false, b=instruction,
       ...
       out[2]=jmpLt,  out[1]=jmpEq,  out[0]=jmpGt);

If you want to, email me your working CPU and I'll reply with comments and one of mine that shows how to use a multiplexor to great advantage in the conditional jump circuit.

--Mark