Maker Pro
Maker Pro

My Video: My CPU: Goodbye Gated Clocks! Hello Indirect Jumps (Now With More Programs)

mcsoftware

Oct 13, 2015
26
Joined
Oct 13, 2015
Messages
26
In this video in my CPU series, I've removed the gated clocks and in doing so, made my design easier to implement on an FPGA and also allowed for my indirect JUMP instruction to be put back in. The term "gated clock" means that the clock line of a counter, register, flip-flop, etc. is driven by a logic gate such as an AND, and not by the main clock. Some people have even forbidden the use of gated clocks.

 

Austin Clark

Aug 29, 2016
16
Joined
Aug 29, 2016
Messages
16
Removing gated clocks is a definite improvement. I mean, gating your clocks sorta eliminates half of the purpose of a "clock" in the first place.

That being said, just glancing at your design, I feel like it's more complex than necessary. Could you create a simple block-diagram of your architecture? That should help tremendously. I've designed several CPUs (mostly in Logisim, though I have built one in hardware) and feel like simplicity is key.

At the very least, keep responsibilities/functions clearly separated between the different components/blocks. ALU/Registers/Control Unit/Memory etc; should be their own circuits in Logisim, and eliminate all "glue" logic in-between.

Keeping things organized and simple will keep the project manageable, even as you add features, and prevents bugs/mistakes. Otherwise, things become incomprehensible pretty quick.
 

Attachments

  • Schematic.png
    Schematic.png
    20.6 KB · Views: 102

mcsoftware

Oct 13, 2015
26
Joined
Oct 13, 2015
Messages
26
Removing gated clocks is a definite improvement. I mean, gating your clocks sorta eliminates half of the purpose of a "clock" in the first place.

That being said, just glancing at your design, I feel like it's more complex than necessary. Could you create a simple block-diagram of your architecture? That should help tremendously. I've designed several CPUs (mostly in Logisim, though I have built one in hardware) and feel like simplicity is key.

At the very least, keep responsibilities/functions clearly separated between the different components/blocks. ALU/Registers/Control Unit/Memory etc; should be their own circuits in Logisim, and eliminate all "glue" logic in-between.

Keeping things organized and simple will keep the project manageable, even as you add features, and prevents bugs/mistakes. Otherwise, things become incomprehensible pretty quick.

I don't know if I can create a block diagram. At least not right now.

I am slightly constrained by the original idea of this CPU. It's an implementation of my CPU designed for a homework assignment in my class in college (you might have seen the original design in my video). I didn't want to say it in the video (because it ages me :) ) but that assignment was 30 years ago. About a year ago (when I found out about Logisim) I decided to put my design into Logisim to see if it worked. For the homework assignment, we didn't have to determine things like falling edge, rising edge, clocking, and resets on the components, so those things had to be determined when I put it in Logisim. The professor gave us 16 instructions the CPU had to do (though I think he made a few mistakes - for example, there's at least one instruction that doesn't make any sense to me (the STORE instruction, which BTW, I didn't fully implement in Logisim because it doesn't make any sense - the professor's hand-written assignment says the final result of the STORE should go to the Z register. But why would you want to do that? Shouldn't STORE go to memory?) BTW, the implementation is based on the simple processor in the book "Logic Design and Computer Organization" by Morton H. Lewin (probably 1st edition (1983)) which was the textbook for that class. I can tell you I don't use a MAR. There's a MAR in the second processor in that book, but I'm pretty sure that came after our assignment.

Having said that, my second video did deviate from the original design. To avoid adding a whole lot of complicated ORs, I had no choice but to replace the instruction decoder and set of ORs with a control ROM.

When I first put it in Logisim, there was one thing (at least) I couldn't remember why I did it that way - why did I put a MUX on the input of the instruction register when both of the MUX inputs are the same. The only thing I could think of is maybe one line has padded bits. In Logisim, that MUX could be taken out.

And there is at least one thing I had to put in in order for it to work in VHDL and Verilog - the priority encoder on the A register's MUX. And it had to be 4 input even though I only needed 2 input to get around a Logisim VHDL/Verilog bug.

And then, admittedly, there's personal taste. Personally, I don't like it when I see a Logisim processor with a few main circuit blocks and 40 subcircuits. In at least one of those cases, the CPU didn't even work/do anything. Admittedly, though, I don't exactly like a mess of spaghetti either, so somewhere in between would be nice. I'm pretty sure adding subcircuits (unless you butt subcircuits together) makes it slower since it adds wires and pins, and in Logisim, every added component (even wires) makes it slower. But I will keep your advice in mind.

In case you didn't see my original design in my video, here it is:blob.png

(Sorry if a thumbnail would have been better).
 
Top