+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: In Progress (https://forum.openredstone.org/forum-20.html)
+---- Thread: Easing my way back into CPU design and building (/thread-10874.html)
Easing my way back into CPU design and building - tokumei - 09-12-2016
Links: Specification (GDocs), Mapping (GSheets)
The title sums it up well. I'm going to be working on a new architecture / instruction set and building a CPU to go along with it. It's just a warmup exercise for some of the cooler stuff I'm planning for later :3.
Ideas so far:
- Harvard memory architecture
- 4 bit data width; 8 bit instruction width
- 3 general purpose registers and one null register (might substitute for a 4th GPR)
- 16 lines of instruction memory
- No higher level storage 8 16 words of secondary data storage
- No call stacks - not practical for such a small instruction space
- 2 or 3 stage pipeline - a new thing I haven't done yet
- Conditional branching with some simple conditions (zero/overflow flags)
- Branch prediction
Updates:
- 2016-09-12: I have made an official for mapping of the instruction set. Please check it out and make comments here!
- 2016-09-13: I have added two new instructions, Load and Store, both of which take up the rest of the empty instruction space. They accept 3 bit memory addresses which are separate from the register address space, so it adds an extra 8 words of data capacity.
- 2016-09-13: I have added a new document, the architecture specification. This will be the home of all the specs that fit better in a typed document than a table.
- 2016-09-16: A rough wiring diagram has been drawn; now working on digitizing it and figuring out tick speeds for components.
- 2016-11-15: I got distracted by school and some other projects, I'm going to start working on this again.
RE: Easing my way back into CPU design and building - Koyarno - 09-12-2016
Some suggestions:
What about a 2 operand IS with a 4 bit opcode? A as source and destination and B only as source.
Register 4 could be a stack to handle the load immidiates and memory operations if you dont want to deal with 2-word instructions.
If you want to start on pipelines, best is to keep to 2 stages. A fetch/decode and Execute so you dont have to deal with forwarding/stack inconsistensies.
It also makes conditional jumps right in line with the conditions from the previous instruction, so no flushing of wrong instructions is needed.
Hope that helps out
RE: Easing my way back into CPU design and building - tokumei - 09-12-2016
(09-12-2016, 10:16 AM)Koyarno Wrote: Some suggestions:
What about a 2 operand IS with a 4 bit opcode? A as source and destination and B only as source.
Register 4 could be a stack to handle the load immidiates and memory operations if you dont want to deal with 2-word instructions.
If you want to start on pipelines, best is to keep to 2 stages. A fetch/decode and Execute so you dont have to deal with forwarding/stack inconsistensies.
It also makes conditional jumps right in line with the conditions from the previous instruction, so no flushing of wrong instructions is needed.
Hope that helps out
That was my plan, 4 bit opcode and 2 operand layout using operations like += and -=. Of course the immediate would use a full word (both operands) so it will probably have a designated register (though it's also GPR). Another idea, I could remove 2 bits off the opcode for the "add immediate" instruction - there will likely be enough extra instruction space to do so.
There won't be any "memory operations" as there won't be any external memory to work upon. Existing ALU operations like add/subtract can be used to move register values around if (but not likely to be) needed.
Thanks for the pipelining advice too. This is my first time so it's going to be fun learning how to implement it.
RE: Easing my way back into CPU design and building - tokumei - 09-13-2016
Okay, I have made an official for mapping of the instruction set. Please check it out and make comments here!
I have a few empty opcodes that could potentially be used to expand the functionality of the current instructions. Or I could add a few new ones. Maybe some external memory for longer term storage?
RE: Easing my way back into CPU design and building - Nickster258 - 09-13-2016
I find your ADDi very interesting.
Definitely tempted to do something similar to this for my next(hell, maybe?) project.
RE: Easing my way back into CPU design and building - tokumei - 09-13-2016
(09-13-2016, 06:22 AM)Nickster258 Wrote: I find your ADDi very interesting.
Definitely tempted to do something similar to this for my next(hell, maybe?) project.
Yeah, variable length opcodes are in a lot of RISC architectures. See page 13 on this pdf (ARM instruction set) for an example. In most of those cases, the opcode is partially replaced with flags that modify the behavior of the operation, but some others use the extra space for more operands.
RE: Easing my way back into CPU design and building - Nickster258 - 09-13-2016
My only problem with that, in that it has not just one but a few variable width opcodes, is issues with instruction decoding time.
RE: Easing my way back into CPU design and building - tokumei - 09-13-2016
Decoding time will hardly be affected. I will just have to pipe the first 5 bits into a logic array that has hardcoded sum-of-product equations for each control signal needed by the ALU or other components.
For example, the control signal for "cut carry" is only needed when the input matches 0110x (NOR) and 0111x (XOR), which can be simplified to 011xx. Therefore, the sum-of-product equation (implemented using AND and OR) is a simple monomial: (!b0)b1b2 (b standing for bit).
Computing any control signal using this method will take 2 ticks, maybe 3 at the absolute worst case. On top of that, it is much more versatile than a decoder that has an output for every instruction. Using that method, control signals have to be spaghettied together from multiple decoder outputs. I used that method a few times before I discovered logic arrays, and I never want to go back to it.
RE: Easing my way back into CPU design and building - tokumei - 09-13-2016
I have added two new instructions, Load and Store, both of which take up the rest of the empty instruction space. They accept 3 bit memory addresses which are separate from the register address space, so it adds an extra 8 words of data capacity.
RE: Easing my way back into CPU design and building - Matthew - 09-14-2016
(09-13-2016, 06:22 AM)Nickster258 Wrote: I find your ADDi very interesting.
Definitely tempted to do something similar to this for my next(hell, maybe?) project.
nick?... redstoning?... i cant believe my eyes
RE: Easing my way back into CPU design and building - Nickster258 - 09-14-2016
(09-14-2016, 12:16 PM)Matthew Wrote:(09-13-2016, 06:22 AM)Nickster258 Wrote: I find your ADDi very interesting.
Definitely tempted to do something similar to this for my next(hell, maybe?) project.
nick?... redstoning?... i cant believe my eyes
Shhhhhhhh its a secret.
RE: Easing my way back into CPU design and building - tokumei - 09-16-2016
I'm pretty sure this instruction set has been finalized, so now it's time to plan the actual CPU build to go alongside it! A couple of days ago, I drew this pretty diagram. Okay, maybe it's not so pretty. My wiring skills aren't that great, but I think I have figured out all of the major buses between components. The next step is building the individual components, then figuring tick speeds for each of them so I can (hopefully) synchronize easily.
RE: Easing my way back into CPU design and building - tokumei - 11-15-2016
Bump: Wow, I had totally forgotten about this project. I got distracted by school and some other projects, I'm going to start working on this again.
I made that diagram a lot more pretty, but now I can't find it anywhere. Going to re-draw it digitally.
RE: Easing my way back into CPU design and building - Chibill - 11-15-2016
rip
RE: Easing my way back into CPU design and building - LordDecapo - 11-16-2016
lol. the self bumb makes it so much better xD
RE: Easing my way back into CPU design and building - tokumei - 11-16-2016
You're welcome.
Update: Cleaned up the diagram a lot!
![[Image: vSEVQpQCP-gKF79anEBjq2LhIS9p7kw4hjgzblFI...35-h626-no]](https://lh3.googleusercontent.com/vSEVQpQCP-gKF79anEBjq2LhIS9p7kw4hjgzblFIyhb5mKoTk4PipJMuvi1kRF64V25QFwiaadWyDb_6VlqVlC5AiUgjCuIzr3h9YefuXzUQqFR8bcBmispTZxM3g1YuIb0C1FNnD2iCWZbEoPu7Xh9JGAyXR-9a4VoAraAFrhNvPpgj5EJtRwz_1FUJj_8su2UIWoBzsFxIN6IcUPsb25SbwuvIf7QwofP3ftXVTLDU3B8lCB2rGwuXs708of61-zxwAWf85GLhCLe1TLEjHS-CvazefLpQBp_Bt-TSJReF8ASjA90TxTjVdwITi1AhjkcMxIfaImc_AbygZJD9X8df_lKekeqhnbfsK83XY2i4oKr2ZXb8n9m6pPyubttjGyT5IOasDYIJUWsHN6bT8841m2u7cHLwMB7KtPtifjlQfsJgr4BBFnU6w4evc2EJY42U17NU1XX1QZF5Ay5U3-xnrRyiW-_DjZFq5AWdzaBtZoFCCEErWAntjmd8FhvB9oRJc6rIAgrW5jE7aSjjHDFUFkM-W6NOWxdrvzIF8pQlUm2zoLs9gPBO6c73dW0af57brxlmfQglaybRugJX-23UTghFpLsdNSvQ37OKH3xf4oWv=w835-h626-no)
And no, this is not how it will be laid out, that would be highly inefficient.
Next step: I am going to be working on how to optimize the instruction decoder. My favorite task because it involves computing sums-of-products and building logic arrays :3
RE: Easing my way back into CPU design and building - Chibill - 11-17-2016
Your image is dead....
RE: Easing my way back into CPU design and building - tokumei - 11-17-2016
Aw man, I had hoped google would let the public see. I guess not. The old link is an album that now has the new diagram. Click here if you are too lazy to scroll.
RE: Easing my way back into CPU design and building - tokumei - 12-25-2016
Update: The instruction decoder seems to be done! Now I will begin work on the ALU and memory units. My plan right now is to learn and use CCA.
RE: Easing my way back into CPU design and building - tokumei - 03-22-2017
Wow, it's been a long time since I've touched this project. BUT I am determined to finish this! Let's get back on track.
From what I can tell, I have most everything done: ALU, registers, external (swappable) memory, and program decoder all seem to work. I ended up using a 4-bit diagonal CLE, neworegs, and a custom vertical memory design. What needs to get done: clocking, synchronization (which are the parts I despise the most)
RE: Easing my way back into CPU design and building - tokumei - 03-22-2017
Oh, and pipelining. I'm going to make a 2-stage pipeline (Fetch/decode, execute). I'm not going to optimize branching using any kind of prediction, just going to hang the next instruction until it finishes - unless I can fit branching into 1 stage.
RE: Easing my way back into CPU design and building - Chibill - 03-23-2017
You could have it ready the instruction that would run if it's a branch and when it decides to branch use that fetched instruction instead of the alternative. This could be built into the fetch/decode stage.
RE: Easing my way back into CPU design and building - Koyarno - 03-23-2017
Its definately possible to do both conditional jumps and unconditional ones in the first stage. There would be no time difference between the two jumps and theres no branch penalty.
Taking out the jump instruction entirely in the code stream is very complex however
For a jump entry you would need to save
1. the jump source address to search for
2. the instruction it points to.
3. the condition you were looking for.
4. the prediction (2 bit+saturation counter?)
and besides that
1. PC recovery register if guessed taken, but not taken
2. some condition module that can work in parallel with the rest of the cpu
fun for experimentation, but you need alot of info for just 1 jump.
RE: Easing my way back into CPU design and building - tokumei - 03-28-2017
Okay, that just went over my head. I'm not trying to branch predict xD