Summer schedule; monthly designs and builds!

[tokumei]

Well, I will be keeping myself busy in the summer. I had originally planned to do an AVR CPU. That is still on the list, but it will be getting bumped down a little. Right now my top priority is my base automation project.

Besides that, I will be making a personal challenge to myself. I will be attempting to build 1 CPU for each month of the summer - June, July, and August. Each one will incorporate something different that I've never tried, usually a different architecture. If I like this idea and it doesn't bog me down, I will probably continue it into the school year.

So, for June, here is my goal (codename Juno):
- Accumulator architecture (new)
- 8 bit data size (new PR)
- 16 bytes of addressed memory
- 64 lines of PROM (new PR)
- 2 stage pipeline (fetch, execute)

For July (codename Julius):
- Dual ALU system
- 3 stage pipeline - Fetch/decode, execute, writeback
- 8 byte shared register file (4-6 general purpose registers)
- ALUs clocked out of phase with each other - one will read and execute while the other writes back. If the writeback and read are operating on the same register, the read will be using the register's state before the writeback.

For August (codename Augustus): IDK, give me ideas!

[tokumei]

Here is the current revision of my Juno instruction set:

;

For clarification, the operand name/description is outside of the parentheses, and the operand type is inside:
- A "pointer" means that the actual value used will be fetched from the memory location whose address is equal to the operand.
- An "immediate" means that the value passed in the operand is the literal value used.
- A "2s comp. immediate" is like an immediate as described above, but when padding to an 8 bit value the pad bit will be equal to the most significant bit. This effectively means that the operand's signed value at its original length will equal its signed value when padded.

I also forgot to mention: You may have noticed that the shifter accepts a signed immediate. That's right; I will be building my first bidirectional, variable shifter. I also plan to use that design at some later date (maybe the Augustus project) for a floating-point arithmetic unit.

[tokumei]

Progress update: Today, I started with an ALU...

... and ended with a nearly finished dataloop.

This project has gone very well so far! I am currently estimating it to be an 8 tick clock, which would be absolutely fantastic. Both the ALU and the barrel shifter could be clocked at 7 ticks, and memory operations will take 3-5 ticks.

[tokumei]

I've made an update to my ISA. My instruction space has been cut to 32 lines in favor of more jump conditions:

[tokumei]

Progress update #2. I have no life - I just spent 6 hours again in a single day. PROM and program counter have been completed today, as well as a bit of signal busing. Tomorrow's big task will be the instruction decoder.

There is now a warp if you want to see the build's progress; /warp juno

[tokumei]

I finished the instruction decoder a few days ago; since then I've also completed the wiring of buses and other signals between the major components. This week I'll be working on the timing, which is a critical part of my pipeline since I'm not putting a latch or buffer between my decode and execute phases. The only thing that hangs the cycle is branching, which is handled by a separate part of the control unit.

[Phase]

Awesome job! I wish I could be this dedicated...

[LambdaPI]

Damn you are fast nonemu.

[tokumei]

I've made a lot of CPUs before that half-worked, so I kinda know what I'm doing. The only issue with them is I never had the motivation to sync the outputs of the instruction decoder. Speaking of which, though it's not perfect, Add Immediate seems to work

[LambdaPI]

Are you going to implement any branch prediction (probably not since it's a 2 stage machine)

[tokumei]

No. Branching will simply hang the cycle until the previous instruction is done executing, then it will update the PC.

[tokumei]

Okay folks, it's now July. I have to admit, I didn't work on Juno a lot in the past two weeks, but it is somewhat working. When I can set aside a couple of hours, I will work out the rest of the kinks. Now, it's time to start planning my Julius project.

As mentioned before, it is a dual-ALU system. It is an interesting form of parallel processing that I've only recently heard about. It's similar to having two cores, except they share a register file and instruction pointer. Each clock cycle, the control unit alternates between processing an instruction for alu 1 and alu 2.

I also have an idea for the Augustus project: I would like to build a CPU that specializes in mathematical operations: Addition, subtraction, multiplication, division, comparison and their floating-point equivalents. If it is feasible, I might make 16 bit operations.

[tokumei]

Another feature I would like to incorporate (possibly this month, if not then in august) is high-capacity memory, more than 64 bytes. This would involve caches of different types: a direct sequential mapping in program memory and a set associative mapping elsewhere.

[jxu]

I like the codenames. There has been a lack of badass Roman names for redstone projects.