Last visit was: Mon Sep 26, 2022 6:30 pm
It is currently Mon Sep 26, 2022 6:30 pm

 [ 237 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 16  Next
 rj16 - a homebrew 16-bit cpu 
Author Message

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
LOL, yeah... I have strongly considered not pipelining. I don't have the problem of having to do that at work, so it's a fun challenge.

But on the other hand it will make the videos much, much, much more difficult to comprehend. The challenge would be around trying to figure out how to present what's going on in an understandable way that doesn't hurt the brain terribly. It's also likely to turn into a very long project and I would really like to get to the part about porting an OS.

On the other hand again, there's almost zero content on youtube about pipelining other than academic lectures. There's one person that has a two or three stage 8-bit processor that's really neat. But he didn't have a lot of hazards to deal with due to the architecture he chose.

Anyway, I am very interested in more thoughts, and thank you for the input so far, this is good to think about!

Thu Mar 11, 2021 6:25 pm

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Good luck!

Last edited by DiTBho on Fri Mar 12, 2021 7:45 pm, edited 1 time in total.

Thu Mar 11, 2021 7:04 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
It's a good point that there mightn't be much out there about pipelining.

From a teaching perspective, it feels to me like
- making a just-workable simple CPU
- adding useful things like indexed or indirect addressing, loop instructions
- making a just-workable pipelined CPU
represent two different forks on the one base. Pipelining a more CISCy machine is going to be more involved and less clear from a teaching perspective. But showing how to implement CISCy features in a basic machine is also arguably worth teaching.

One of the ways commercial (industrial) CPU designs fail is by being overambitious, and shipping late or with bugs, or both. I think one reason there is that a CPU team - or at least its senior members - need to learn their trade. The most successful engineers (that I know) are those who have worked on a series of increasingly involved CPUs.

So, a series of target machines, and building up to each, and it not necessarily being a linear progression, might be worth considering.

Of course, you also need to do what's fun and interesting for you!

Thu Mar 11, 2021 8:00 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
Something I have recently learned about myself is that I really like to take the road least travelled just for the sake of taking the road least travelled. But unfortunately it's both a lonely road, and has a very high rate of discouragement and failure.

I really want to build a pipelined cpu, but is that because most people don't build one (at least not for fun) and that's why it appeals to me? I think that's probably a large factor, yes.

Well okay, maybe I should consider rearranging some priorities. I want to maximize the chances of me actually completing this project. So maybe instead I should maximize the enjoyment of building and using the processor.

Any ideas? Anything else besides pipelining I should consider dropping for the sake of enjoying building this more?

Fri Mar 12, 2021 1:26 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
I find it's a nice reward when something works - so, perhaps cook up a couple of simple programs, and then build up the CPU until it can run them. Not exactly test-driven development, but success-driven exploration.

Fri Mar 12, 2021 1:36 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
Crazy week, I haven't had a chance to record anything. Hopefully tomorrow, as I have the day off. But I have been thinking a lot about what would be the most fun and the direction I would want to go with this project.

I think I might still want to pipeline this processor. I am still debating that. But I don't need to make that decision now. So let's set that aside.

I think I would really like to build this with discrete logic. I think that's going to be the most fun. FPGAs are great, and I think would be awesome as a breadboard-like verification environment before I delve into making PCBs and spending money on parts. But there's something to be said for PCBs and chips and wires and blinkenlights galore.

So that said, 32-bits is not realistic to build with discrete logic. Certainly not a RISC computer with multiple buses running everywhere. The thing would be the size of my desk, and cost a lot to build.

So I think I need to strongly consider going back to 16-bits. It would be roughly a quarter the size and cost.

But I think there's still a way to do 32-bits -- the same way the early versions of the m68k did it: 16-bits at a time. It'll be slow but it will be realistic to build in discrete logic.

In fact, I wonder if it makes sense to build a super simple 16-bit RISC random logic machine just to run the microcode of a 32-bit macro machine? Or would it be simpler just to build the micro-machine the traditional way? Or is there even a difference? Is the micro-machine in most CISC computers just a VLIW RISC machine?

There's also the debate of whether or not I really need it to be 32-bits at all. I did find that Xinu will just about fit in 64 KB -- it's 76-ish KB. But with a relatively crude MMU, it could fit. Or it could have some features removed to fit without a MMU.

What do you all think?

Fri Mar 19, 2021 12:22 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
I think it's worth being conscious of, and perhaps trying to avoid, the trap which leads to wanting 32 bits, high performance, simple and low cost implementation. Because you can't have everything!

If you've programmed an 8 bit micro, you know it can perform 16 or 32 bit operations. There's no question of capability, only of efficiency.

> Is the micro-machine in most CISC computers just a VLIW RISC machine?

I would ask, is that a useful way to look at things? I think it depends on what question you're trying to answer. An instruction set is one thing, and an implementation is another. A complex instruction set is going to have a complex implementation: either in logic, or in microcode, or both.

Getting a processor project finished is, I think, a function of two things: maintaining interest, and limiting the scope. I think it's a useful tactic to start with a severely limited scope, and implement that, and then gradually increase the scope. A lot of people start the other way: they try to keep their interest by increasing the scope, but what they are doing is piling up work ahead of them: specifying, building, verifying, documenting, targeting. A lot of those projects stall, I reckon.

It's true that a 16 bit address space is quite limiting, especially if you bring modern expectations about toolchains and operating systems. I don't think it's too limiting, but that's a personal judgement. We know that there are several ways of extending addressable memory, and some are more complex than others.

A 16 or 24 bit machine needn't be a great deal more complex: it doesn't have to have lots of complex addressing modes, or be a three address machine, or have loads of registers. The temptation to fill up the instruction coding space is, I think, to be resisted. That's not the heart of the task of bringing a processor to life.

What would satisfy you as motivating goal? Would it feel good to run a Fibonacci program, a factorial program, a pi program? Or do you feel compelled to bring up Xinu, or something like it? Could you get there in a series of steps?

Fri Mar 19, 2021 2:54 am

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
Thank you! You make very good points. 16-bit it is.

The problem with my current designs is that I end up with 7 opcode bits in the end, which is 127 instructions. Temptation is strong to try to use all of them.

A MISC processor has a limit of 5 opcode bits, or 32 instructions. Maybe I should adopt the limits imposed by the wikipedia article?

I spent some time aggressively cutting down the number of instructions. I think I can implement everything I want in 32 instructions. I think it will still support a C compiler, but I will need to go with LCC instead of GCC I think, which is fine.

It might even still support a unix-like OS, but by MISC rules, I can't do memory protection. However, if every process has its own 64 KB, that's not technically protecting memory, since there's no page faults.

Interestingly enough, it looks very similar to what I have implemented so far in my videos. So, I can pretty much just carry on. But now there's a chance it can be implemented in discrete logic, and my chances of completing this project went up a lot :-)

Fri Mar 19, 2021 7:02 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
Ooh, I don't much like that Wikipedia article! It's nice, of course, to have a list of interesting possible choices, and a list of comparable-complexity real life designs, and to have links to papers. But it looks to me like an attempt to carve out a well-defined category where there isn't one, or where the category isn't too helpful. Like "plants with yellow flowers", although that might be a poor example.

Still, if the idea is to try to be fairly simple, that's a story. (Are you aware of the OPC machines? Cooked up mostly by @revaldinho here, with me and with @hoglet. They were simple for a different reason, but I think they serve as interesting demonstrations. Maybe have a look at these threads: 1, 2, 3. There are other interesting MISC-ish ideas also discussed elsewhere here on this forum, of course.)

Fri Mar 19, 2021 9:58 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
Yeah, those are good, thanks for the reminder as I haven't looked at them in a while. I think I would want something along the lines of the OPC6. But I want to stick with a few of the interesting ideas I came across in my travels so it's still got a bit of my preferences in it.

Anyway, here is the next video. It's mostly just a montage of converting back to 16 bits, while I talk about this decision. Nice and short.

[018] New Direction, Back to 16-bits!

Makes me wonder if I should do more talking over the sped up parts of the video, just to save time. Let me know if you think that's a good idea. I worry it might make it harder to follow what I am doing. But I could record the voice over later in the day when I am less rambly but get the building done earlier when I have the time. I dunno, I might try it for a video or two.

In other news, I have been heads down coming up with a ISA. It's going to be a horrible pain to decode it, though it's straight forward because now I have encoding space to categorize instructions better. I don't really want to spend all my energy in an endless redesign loop, but I do feel like there's got to be a way to make it a lot simpler. If you have any ideas, let me know.

For those who like these sorts of tables (note: very much still work in progress!):

rj32 isa v9.png

You do not have the required permissions to view the files attached to this post.

Sun Mar 21, 2021 12:25 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
LOL I still over engineer things. Here's a much simpler version:

rj32 isa v9.png

I really wanted to keep the 6 bit immediate I think. But once I finally let go, I managed to find a simpler solution.

I tried to make the circuit for the previous post and it was a nightmare. This one should be a lot easier because the opcode is directly encoded in the instruction for most of the instructions. The only complicated parts are the immediate bearing instructions, and there's only 5 options to decode from 3 bits to figure that out. Muuuuch better.

Edit: Updated the image with a few fixes: renamed fmt0 to fmt, moved the fmt bits around and some typo type things.

You do not have the required permissions to view the files attached to this post.

Last edited by rj45 on Mon Mar 22, 2021 10:38 am, edited 1 time in total.

Mon Mar 22, 2021 2:24 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
Oh, I meant to say: narrating over your progress afterwards might be an excellent idea, especially if you use fast-forward and jump cuts, comparing to narrating as you go.

Mon Mar 22, 2021 8:29 am

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
Next video is up. I dive into the diagram in the previous post, explain it a bit, then start building a circuit to decode it. Which, is WAY simpler than the ISA two posts ago.

[019] Instruction Set Decoding! (Part 1)

I tried doing a voice-over of the sped up video, but it's actually kind of awkward since I am watching a video and trying to narrate it. I might try again in the next video, but if it keeps being super awkward I might want to go back to what I was doing before. I dunno... maybe practice will make it better. Let me know what you think. It does make the videos shorter which is nice.

Thu Mar 25, 2021 1:10 am

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 123
The second video in the decoding saga is up. I finish the decoding circuit, but I have to integrate it into the rest of the build, so the processor is still broken.

There's a fair bit of tinkering with unit tests at the end that might be painful to watch. You aren't missing anything if you stop watching at that point.

[020] Instruction Set Decoding! (Part 2)

I also tried a different way of doing a voice-over on the building part, where I originally recorded it inline as I was building but later floated the audio on top and sped up the video. I kept pointing at things though which made it really annoying to align the audio with the sped up video. But it worked okay, if I can remember not to point at things.

Sat Mar 27, 2021 12:34 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1712
Just a quick comment - there's a gap of nearly three minutes where you're not saying anything, and I wondered if my computer had broken, so it might be worth putting in a few words of commentary even when there's nothing very specific happening - maybe even just noting that it's nearly done. An audio-described progress bar!

Sat Mar 27, 2021 12:48 pm
 [ 237 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 16  Next

Who is online

Users browsing this forum: CCBot and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software