How can I design a microprocessor

Forum: Microcontrollers and Digital Electronics Own CPU: architecture?






edit: cough cough I just noticed that there was a small bug in the last two files. That's what happens when you move table lines around in a funny way ... ;-) If you find it, you're welcome to keep it. ------------------------------- Hello everyone, I've had a project in mind for a long time and I've finally gotten to grips with it can deal. The point is that I would like to design a small CPU and then use it in terms of hardware (with logic modules). First of all: I am NOT a professional and deal with hardware, microcontrollers, (digital) electronics "only" as a hobby in addition to the dry study of computer science ... So please bear with me a little. The whole thing should of course have a certain learning effect, but first and foremost it should be fun. But what do I want here anyway? I once thought about a possible architecture and suitable components. I once put that on "paper" and added it. Perhaps one of you can tell me whether this looks quite useful, or whether I've got lost there and it doesn't work out like that? The whole thing should be an 8-bit CPU with 8-bit wide data and address buses. I have an accumulator register which always goes to the first input of the ALU and a cache register as a buffer. AC, AZ and AN are flags for overflow, zero and an indicator of whether there is a negative number in the accumulator. I also considered that the clock should drive the "state counter", which switches the next output on every edge, which means that one of the commands listed below on the right in the drawing is processed. So (1 cycle each): - Get the command from the address in the "CMD_ADDR COUNTER" from the RAM and place it in the DATA_COMMAND register - Set the DATA_COMMAND register - Get the data word from the RAM and place it in the DATA_WORD register - Set the DATA_WORD register - Convert CMD_ADDR Increase 1 - give the command and data to the command decoder, it switches everything necessary or executes the command and applies the new data to the remaining registers - the remaining registers (ACCU, CACHE), the flags, possibly R / W on the I / O bus or / CE on the display are set. This is of course not particularly high-performance or optimized, but quite simple in my opinion. Or are there any (technical) objections? Is that even a totally stupid idea? Have I otherwise forgotten anything important or, in your opinion, are there other errors in my considerations or other gross blunders? I have already worked out and written down an instruction set based on my architecture (Appendix). Is it good like that? Have I forgotten something / overlooked / not considered / etc.? I had already picked out some logic modules (74HCxx series) and had them come over to tinker with them a little and see what was going on and how. I had a few (very stupid) questions about the hardware: - For the registers I can simply use D flip-flops (like 74HC377) and then simply set them at L-> H clock edge of the clock if the feed lines are in the clock before have been set, right? Because reading from the RAM and the calculations of the ALU etc. take a moment so that I cannot set the register at the same time. On the breadboard it works with a D-FF so far ... - Of course, I would also need some multiplexers, but I only found the 74HC157, which is a 4 x 2: 1 MUX. For a word it would always need 2. Is there possibly the whole thing in 8Bit? So basically 8 x 2: 1 MUX? - I chose this as the RAM module: http://www.reichelt.de/Drams-Srams/6264-70/3/index.html?;ACTION=3;LA=5;ARTICLE=2676;GROUPID= 2954; artnr = 6264-70 Should go, right? From the control it looks very simple and I never get the full 8K in my life. So I could branch off from address bits 8 for my address width and then use the rest to differentiate between command memory, data memory, maybe even internal RAM ...?! - Then one little thing still worries me: When I do that with the state counter, I read from my RAM in one cycle and set the register in the next. That means I have to OR the output for the R / W for the RAM with the output for registering. As a state counter I have a 74HC4017 here. However, I did not find out from the data sheet. If the output changes, do I have a short time in which there is nothing to do with any output? It kind of looks like that happens at the same time, but I can't imagine that. Because as soon as there is nothing left at one of the outputs, I lose the R / W signal for the RAM and I would then have to read out again in the next cycle, which then costs time and the register is already set. Or how long can the R / W on the RAM go? Does anyone understand what I mean? :-) Otherwise, I hope that I was able to make it clear how I imagined it and that some of them weren't already lying on the floor laughing. As I said: I read a lot and that's only why I have my "knowledge". Please don't be angry if I don't know what to do at one point or another or if I just stand on the hose. I'm still learning ... ;-) I would be very happy if maybe. someone could answer my questions, or could also tell me whether the project is feasible (it is also clear to me that this is not a weekend project), or whether I have completely taken over and then imagine the whole thing too simply . I would really like to implement the project. Best regards, Christoph



What is the difference between your CPU and what feels like 700 other versions?



You learn a lot in the process to design your own CPU and to simulate it at least on the register transfer level.



Josef G. has already finished developing it, very modern in the FPGA. What do you want to reinvent the wheel?



Of course, and because there are already 5 million LED flashing programs for uCs, uC beginners don't need to write any more.



Of course, blink programs and your own CPUs are almost the same :) Josef G. has really created something perfect. Why not use it?



Because it's not about the end result, but the journey is the goal?



I couldn't see address widths / sizes from the description. Are you dealing with programs with a maximum of 2-digit number of operations? Or should it be a basically complete CPU after all? Because how do you make subroutine calls? Indirect / calculated addressing, for example to pound through the characters in strings, is done via self-modifying code? Otherwise I don't see anything about it.



Simply copying other people's developments only proves that you can read and solder or program FPGAs. That's hardly going to be the point here.



Christoph B. wrote:> - The remaining registers (ACCU, CACHE) If you want to promote understanding, then avoid terms that already have completely different meanings. Like cache.




Hello, thank you very much for the numerous answers! Abdul K. wrote:> What distinguishes your CPU from the perceived 700 other> versions? Mops Fidibus wrote:> Josef G. has already finished developing it, very modern in the FPGA.> What> do you want to reinvent the wheel? I designed and understood my CPU myself. I don't want to do something unprecedented or reinvent the wheel, but: Juergen G. wrote:> Of course, and because there are 5 million LED flashing programs> for> uCs, uC beginners don’t need any more write A. K. wrote:> Simply copying other people's developments only proves> that> one can read and solder or program FPGAs. That is what this> will hardly be about. Boris B. wrote:> Because it is not about the end result, but the journey is the goal>? Exactly! It should still be the ultimate, but rather serve as a project for learning, understanding, tinkering, handicrafts and having fun. I am very happy to look at the project mentioned, thanks for the hint! foo wrote:> You learn a lot while designing your own CPU and> at least simulating it at> register transfer level. Yes - I've already started simulating. Is just a little difficult to do the whole thing with the appropriate ICs. So far I have always been building subcomponents on the breadboard and seeing what comes in and out. But simulating is definitely not a bad idea! A. K. wrote:> Christoph B. wrote: >> - The remaining registers (ACCU, CACHE) >> If you want to promote understanding, then avoid terms that> already have completely different meanings. Like cache. Of course that's true. Is changed. Thanks! A. K. wrote:> Address widths / sizes could not be taken from the description.> Is it about programs with a maximum of 2-digit number of operations? Or should it> then be a basically complete CPU? >> Because how are subroutine calls designed for you? >> Indirect / calculated addressing, for example to pound through the characters in> strings, is done via self-modifying code? Otherwise> I don't see anything about it. I have now entered register and bus widths. I can implement subroutine calls using the conditional and unconditional jump instructions, right? But I hadn't taken into account that the 'return address' has to be saved somehow. I inserted a corresponding command, which then fetches the current command address (which can then be put somewhere). Then I can jump back to the saved address (+1). Thanks for the hints! I'm still grateful for any criticism ...



Download Quartus II from Altera. You can simulate there. The code entry can be done in VHDL or something else. It is also possible to work symbolically with flip-flops and gates, Tristte and Muxen. I think there are all the 74xxx and so on as building blocks.



Do I understand correctly that all commands consist of an 8-bit opcode and an 8-bit operand, with only 5 bits being used by the opcode so far? Depending on the opcode, is the operand a constant, a code / data address or unused? Since the RAM is apparently only addressed by PC, are all possible variables outside of the A / B register directly the operands of commands? Interesting approach, but I suspect that it won't get you very far.



With 2x 74HC670, for example, instead of either the A or the B register, 4 registers can be implemented there with very little effort. Which could probably solve a few problems, because then there are at least a few real addressable variables.



Uwe wrote:> Download Quartus II from Altera.> You can simulate.> The code can be entered in VHDL or something.> It is also possible to work symbolically with flip-flops and gates,> Tristte and Muxen. I think there are also the whole 74xxx and so> as building blocks inside. Loading! Had already tried to integrate some 74xxxx libs with the Xilinx ISE, but that was more of a beating of the pot ... I'll see what can be done with it. A. K. wrote:> Do I understand correctly that all commands consist of an 8-bit opcode and an 8-bit> operand, with only 5 bits being used by the opcode so far? The> operand is, depending on the opcode, a constant, a code / data address or> unused? Yes, or the buses for the CPU opcodes are only 5 bits wide. A. K. wrote:> Since the RAM is apparently only addressed by PC, are> all possible variables outside the A / B register directly the> operands of commands? Interesting approach, but I suspect that it won't> get very far. You mean that I have too little space to store something and that the two registers are not enough? Yes - I've already thought that too. In general, I could access a RAM on the I / O bus, but then it is occupied again. So actually I could put values ​​with fixed addresses in an additional RAM module ... Then I would have 256 additional addressable registers. Would that be a good idea? If I bend two more commands to write from the RAM address x to the ACCU and vice versa to write the content from the ACCU to the RAM address x, that should be feasible. Or am I wrong? A. K. wrote:> With 2x 74HC670, for example, instead of either the A or the> B register, 4 registers can be implemented there with very little effort. Which could probably solve a few problems, because then there are> at least a few real addressable variables. I also ordered some of them, thanks for the tip! But that would also be done with an extra RAM solution, right?



Christoph B. wrote:> Abdul K. wrote: >> What distinguishes your CPU from the felt 700 other >> versions? >> Mops Fidibus wrote: >> Josef G. has already developed it, very modern in the FPGA. >> What >> do you want to reinvent the wheel? >> I designed and understood my CPU myself. I don't want to> do something unprecedented or reinvent the wheel, but:> Then I overlooked the fact that you only develop the part for learning. From the point of view of others, it is important to know whether it fixes any deficiencies in other architectures and is therefore worth a look. Otherwise, the circle of those interested is limited to those who enjoy developing CPUs. I swear by this man here, and that's probably why his CPU isn't bad either: http://www.holmea.demon.co.uk/GPS/Main.htm


@Christoph B. I'm also currently building my own CPU, but on a 4bit and TTL basis based on a circuit diagram from the 80s. Maybe you can exchange ideas. My cycle unit is already there. Not dolles but a first step. http://www.youtube.com/watch?v=_-bqaRML-e4



In order to optimize the instruction set, one could write a simple simulator (e.g. in C or assembler). A while ago I did this for a simple exercise CPU that I found on the Internet. I then ran the simulator on an Atmega8: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=24



> I thought about a possible architecture and> suitable components. If you want to build that with 74HCxx, then you should choose an architecture that doesn't have thousands of building blocks (like http://cpuville.com/). Because that not only makes effort in the construction, costs money and is prone to errors / faults, but also the opposite of "egegant". There are already some TTL CPUs on the net, look for the ones that require the fewest (available) components, such as http://repository.cmu.edu/cgi/viewcontent.cgi?article=1595&context=compsci&sei-redir=1&referer= http% 3A% 2F% 2Fwww.google.de% 2Furl% 3Fsa% 3Dt% 26rct% 3Dj% 26q% 3Dminimal% 2520homebrew% 2520ttl% 2520cpu% 26source% 3Dweb% 26cd% 3D6% 26ved% 3D0CFgQFjAF% 26url% 3Dhttp% 253A% 252F% 252Frepository.cmu.edu% 252Fcgi% 252Fviewcontent.cgi% 253Farticle% 253D1595% 2526context% 253Dcompsci% 26ei% 3DG8buUcmXMtDQsgbLy4H4AQ% 26usg% 3DAFQjCNFJCarYW01FS7ahPOhQMqzRyabnPw # search =% 22minimal% 20homebrew% 20ttl% 20cpu% 22 Otherwise you drive better with a small FPGA (Development Kit) and can redefine the CPU until you like it. Oh yes: The second problem: The software: As soon as you have the hardware, you want to run something. So you should be compatible with an existing CPU with interesting programs so that you don't have to write every program yourself. CP / M is a good choice, which is now also available in Source. Or a Gameboy compatible hardware.