De-bus pins?

[mmiller7]

I'm working on the CPU and I wonder if there's any easy way to reference a sub-bus without using lots of extra gates?



For example, instead of typing "instruction[11]" over and over I want to type "c1" to reference the bit.

I came up with this but it seems ridiculously inefficient adding over a dozen extra And-gates:

//Rename the pins
And(a=instruction[11], b=true, out=c1);
And(a=instruction[10], b=true, out=c2);
And(a=instruction[9], b=true, out=c3);
//...and so on

P.S. I don't think this hdl is giving anything away, it's just the definition of the C-Instruction bits directly from the book, I'm not really doing any logic.

[cadet1620]

mmiller7 wrote

I'm working on the CPU and I wonder if there's any easy way to reference a sub-bus without using lots of extra gates?

I don't think that there is a way to alias I/O wire names in HDL.  You can alias internal wire names by having multiple 'out=' in a part statement.

FWIW, I have this layer of ANDs in my CPU, but they AND with instruction[15].  Although not necessary for the Hack CPU, experience makes me qualify all the C-instruction control signals so that they are in a defined state during A-instructions.

A few extra AND gates in the CPU are trivial -- The RAM16K contains > 13 million NAND gates!

--Mark

[mmiller7]

Ah, ok.  That does make sense...when you're talking about millions of gates a dozen really is trivial.

Designing real-world hardware I think I can understand why it might be desirable to specify what happens to sub-componants when they are "inactive" but I felt like for the purpose fo the HACK computer it shouldn't really matter.  During an A-instruction I wrote it so the output of my ALU goes nowhere so I felt like it would be redundant to try and specify what it's doing.  I suppose it all depends how the data is going to be used as to what the state should be.

[cadet1620]

mmiller7 wrote

Ah, ok.  That does make sense...when you're talking about millions of gates a dozen really is trivial.

Designing real-world hardware I think I can understand why it might be desirable to specify what happens to sub-componants when they are "inactive" but I felt like for the purpose fo the HACK computer it shouldn't really matter.  During an A-instruction I wrote it so the output of my ALU goes nowhere so I felt like it would be redundant to try and specify what it's doing.  I suppose it all depends how the data is going to be used as to what the state should be.

Quite right.  In the Hack CPU it doesn't matter if random things are happening in the ALU during A-instructions.  In my design, even though all the control signals are gated by C-instruction, random data still appears on the outM bus during A-instructions since the ALU's computing A&D, but that doesn't matter since writeM is not set during A-instructions.

Being systematic about things like this can help if a project is passed from one engineer to another, or if you have to revise your own work a year or two later when you no longer remember all the little details.  It can also help in debugging; signals on logic analyzer or oscilloscope are easier to understand if they aren't doing random things half the time.

--Mark

[cadet1620]

cadet1620 wrote

FWIW, I have this layer of ANDs in my CPU, but they AND with instruction[15].  Although not necessary for the Hack CPU, experience makes me qualify all the C-instruction control signals so that they are in a defined state during A-instructions.

I've started experimenting with adding another instruction to Hack, and I realize that I should have qualified all these control signals with cinstr, where cinstr = instruction[13] AND instruction[14] AND instruction[15].

C-instructions have the top 3 bits all 1 per 6.2.2, but my new instruction has bit 13 = 0 and doesn't want all those C-instruction control signals active.

--Mark