Processor design

[dh]

Here's an interesting thing CJmovie showed me:
http://www.xgamestation.com/index.php . Some documents are free at the moment. Chapter 1 and 11 iirc.

I have a BS2-SX. It's not bleeding edge, nor a real processor really, but it's sure fun to tinker with

I've thought of making an archecture based off the new intel 64-bit processors, but I don't have the money/time/experience to even consider it at the moment .

[edit]
got a new digikey catalog today . If anybody has it (Jan-April 2006, C061), I recommend checking pages 372 to 375. Also, in the PRODUCT INDEX at the beginning of the book, invest some time into looking at the MICROCONTROLLER and MICROPROCESSOR sections

*2 Cheers for that
[/edit]

Cheers, DH.

[beyondsociety]

I have a background in electronics and have tinkered with the idea of designing my own processor. Currently I have wrote an emulator based off of some of my own ideas. I have also bought my own programmable FPGA and designed a basic processor in VHDL. I have successfully been able to download it to the FPGA and test it.

I have also been tinkering around for a while with the idea of making my own game console. Im in the process of redesigning the processor for use in the console.

Anyone interested in the subject should get a book called "Computer Architecture: A Quantitative Approach" by Hennessey and Patterson.

Ive read it and must say it was good. It is a little outdated but still applies to todays processors.

Have you decided whether your processor will be RISC or CISC? Each has its advantages and disadvantages. FPGA is the way to go as you can design the processor in VHDL: VHSIC and then download the design into the chip. ASIC is primary used when you want to be able to manufacture a large sum of chips.

[Kemp]

I don't think RISC vs. CISC is a valid argument these days. Upon contact with the real world the two different design philosophies tend towards each other, so while you can still make the distinction on a technicality, it isn't really worth making.

I may actually work on my processor design, my coursework has spiralled out of control due to my inability to ignore some aspects of the designing and create a naive design. I'm thinking of making one aimed at embedded systems as I'm being exposed to pervasive systems in general and wireless sensor networks specifically a lot and my uni is getting into designing their own units rather than paying over the odds to get them from elsewhere.


Edit:
More thoughts on RISC vs CISC. Thinking about it, a CISC processor is just a RISC processor with a layer of abstraction that breaks the complex instructions into simpler parts (at least the ones that use microcode, see my previous thoughts on microcode).

I guess my processor will be CISC, but not to the extent of x86s, 32 different jump instructions

[Colonel Kernel]

More thoughts on RISC vs CISC. Thinking about it, a CISC processor is just a RISC processor with a layer of abstraction that breaks the complex instructions into simpler parts (at least the ones that use microcode, see my previous thoughts on microcode).

IMO, true CISC processors are hard to find these days. None of the x86 processors are really CISC anymore, at least not in terms of the implementation. You really have to distinguish between the instruction set that programmers see and the one that the processor itself actually executes (micro-ops).

Be careful not to confuse microcode with micro-ops... Although they can be the same, that would be a coincidence of the implementation. Micro-ops (or macro-ops if you're AMD ) are really just the internal RISC instruction set of the processor, while microcode is a way to implement instruction decoding logic. Although microcode is a lot more flexible than "hard-wired" gate logic, it also has a slower propagation delay IIRC. This means it's unwise to use it for frequently-executed instructions, because it forces you to either reduce the clock rate or increase the number of decoding stages in the pipeline.

[Kemp]

Be careful not to confuse microcode with micro-ops... Although they can be the same, that would be a coincidence of the implementation. Micro-ops (or macro-ops if you're AMD ) are really just the internal RISC instruction set of the processor, while microcode is a way to implement instruction decoding logic.

Heh, a very fine distinction, and one that is too fine for me. I see the difference and choose to ignore it ;D

Although microcode is a lot more flexible than "hard-wired" gate logic, it also has a slower propagation delay IIRC. This means it's unwise to use it for frequently-executed instructions, because it forces you to either reduce the clock rate or increase the number of decoding stages in the pipeline.

Microcode is a bit slower, yes, but is a lifesaver for someone like me Mixing microcode and hard-wired logic isn't something I'd considered before, I think I'll just stick with microcode for now though, nice upgrading potential after all the bugs in the first run have been found, lol.

[Candy]

Be careful not to confuse microcode with micro-ops... Although they can be the same, that would be a coincidence of the implementation. Micro-ops (or macro-ops if you're AMD ) are really just the internal RISC instruction set of the processor, while microcode is a way to implement instruction decoding logic.

Ok, I didn't notice the difference. What's microcode then?

I don't expect the instruction decoder to be much work, only repetitive.

Microcode is a bit slower, yes, but is a lifesaver for someone like me Mixing microcode and hard-wired logic isn't something I'd considered before, I think I'll just stick with microcode for now though, nice upgrading potential after all the bugs in the first run have been found, lol.

The only advantage I can see for microcode is in ASICs and hard-baked chips, since I'm aiming at only FPGA's I can reconfigure and upgrade it entirely.

[Kemp]

The advantage is more to do with the sheer complexity of the decoding logic once the instruction set reaches a usable size, it becomes a nightmare. And if you plan something out wrong then a rather large chunk has to be redesigned, compared to changing a few microcode instructions.

That said, it is your choice as it's your design, don't let me put you off if you find that way more comfortable.

[Kemp]

I'm thinking of 24 bit processors right now. Is there any disadvantage to doing this or is sticking to strict powers of 2 simply tradition?

I'm thinking of this because neither 16 nor 32 bit processors really fit my intended target (I'm sticking to same-size address and data buses for now). 16 bit processors can only address up to approx 64KB of memory (flat, non-paged, non-segmented, etc) which isn't really enough for my purposes, while 32 bit processors can address a lot more than I'd need but take up a lot more board space in terms of pins and tracks. Maybe a 32 bit processor with a limited address bus might be a good idea. Drop the address bus down to 24 and leave the data bus at 32, that would make 16MB of addressable memory which should be enough. But then why not drop the data bus down as well? Thus I return to my original point...

Note that unlike a certain company who's name ironically forms the start of the word Intelligence, I'm not going to do a 32 bit processor with a 16 bit external data bus, that was just stupid

</random thoughts>

[Solar]

Early 680x0 models had this setup - 32bit data, 24bit address bus.

As for 24bit data bus... how do you intend to interface with memory (which, unless you design that yourself, too, will be strict powers of 2...)?

[Candy]

I'm thinking of 24 bit processors right now. Is there any disadvantage to doing this or is sticking to strict powers of 2 simply tradition?

I'm thinking of this because neither 16 nor 32 bit processors really fit my intended target (I'm sticking to same-size address and data buses for now). 16 bit processors can only address up to approx 64KB of memory (flat, non-paged, non-segmented, etc) which isn't really enough for my purposes, while 32 bit processors can address a lot more than I'd need but take up a lot more board space in terms of pins and tracks. Maybe a 32 bit processor with a limited address bus might be a good idea. Drop the address bus down to 24 and leave the data bus at 32, that would make 16MB of addressable memory which should be enough. But then why not drop the data bus down as well? Thus I return to my original point...

I picked 16 bit with external 21 bit interface, so you're not entirely alone. I picked the 21 bit interface so I could have 2mbytes of sram (which I can afford, and it's quick & simple to use, so why not). I'm using paging with 512 bytes per page (or 256 words, since it uses only words) with 4096 pages total in memory, which suffices for most things I think.

24 bits has a disadvantage in that it doesn't fill up a nice power of two. You can't use 24 bits easily in conversion functions, you can store the bit positions in 5 bits, but you waste half a bit etc. It's just suboptimal. If you're going to use more than 16 bits, you might as well extend to 32 bits. Not much difference. For the external bus, ignore the other 8 bits and just pretend they're there. Also, it makes pointers interchangeable with normal variables which is a very good thing.

[me=Candy]loves pointer-messing-about [/me]

[Kemp]

So you're saying make it all 32 bit internally and just don't provide the external address bus with the extra 8 bits? (Sorry if that sounds like me challenging the idea, I'm just asking if that's what you meant, my internal parser came up with a few alternate meanings, lol).

I can see where that could be a good idea, the processor itself would have nice powers of 2 and be all happy, while still saving the board space by dropping 8 of the pins. You've got me thinking of a 24 bit address bus (just hardwire the top 8 to 0v as far as the memory is concerned, they won't be needed anyway if the amount of attached memory stays under 16MB) and a 32 bit data bus. Does that still leave the problems with the address bus being 24 bit?

I'm slightly confused as to exactly how I want to handle this now. A 32 bit internal address bus and 24 bit external would waste the logic that deals with the extra 8 bit internally, but you say a 24 bit address bus on both sides would be hard to handle?


Edit:
Ok, I'm just not seeing the problem with the addresses being 24 bit everywhere, maybe it's just me being dumb.

[Candy]

So you're saying make it all 32 bit internally and just don't provide the external address bus with the extra 8 bits? (Sorry if that sounds like me challenging the idea, I'm just asking if that's what you meant, my internal parser came up with a few alternate meanings, lol).

Yes, that's exactly what I meant.

I can see where that could be a good idea, the processor itself would have nice powers of 2 and be all happy, while still saving the board space by dropping 8 of the pins. You've got me thinking of a 24 bit address bus (just hardwire the top 8 to 0v as far as the memory is concerned, they won't be needed anyway if the amount of attached memory stays under 16MB) and a 32 bit data bus. Does that still leave the problems with the address bus being 24 bit?

I don't see any direct problems, but you would get binary convertability between addresses and numbers, which is very nice.

I'm slightly confused as to exactly how I want to handle this now. A 32 bit internal address bus and 24 bit external would waste the logic that deals with the extra 8 bit internally, but you say a 24 bit address bus on both sides would be hard to handle?

I'm saying that implicitly using a 32-bit address everywhere of which you only implement 24 bits is a good idea. You waste one byte per address, you gain aligned offsets, easy pointer math, extendability, scalability and a few minor detail things (such as not having the feeling that you're wasting a few bits everywhere - I hate that feeling).

Edit:
Ok, I'm just not seeing the problem with the addresses being 24 bit everywhere, maybe it's just me being dumb.

Well... there isn't strictly speaking "a problem". It's just something that's odd and therefore unknown. Since you save very little and lose a few big improvement points, most people choose otherwise. If you don't see a big improvement in my points, be my guest to ignore the idea and to just make it all 24 bits.

[Colonel Kernel]

Ok, I didn't notice the difference. What's microcode then?

Microcode is a lower-level concept. A typical micro-op would be something like "add r1 and r2 and put the result in r3", whereas a line of microcode would be more like "enable the ALU and register file, use bits 5-10 of the instruction register to select the destination register...", etc.

Basically, microcode corresponds directly to what would otherwise be hard-wired gate logic for controlling instruction execution.

[Kemp]

I may be thinking of addressing the RAM a bit too much, but 24 bit and 32 bit addressing are exactly the same within the 16MB that's available aren't they? I mean

00000000000000001101001001010100

and the same number but with the upper 8 bits hardwired to 0 are still the same address. Using 32 bits for data and 24 bit addressing shouldn't be too much trouble as and number you want to use as an address will just wrap around if you make it too big (heh, I'm becoming Intel with the wrapping of addresses, if I start talking about optional switching on of address lines then please shoot me ).

Ok, so addressing the RAM shouldn't be a problem with differing size buses, now how about internally? I'm kinda stuck there. Making it 24 bit internally would make the most logical sense I guess, as implementing the other 8 lines would be a waste of chip space, but then my mind crosses over into making it 32 internally, which means it would make sense to expose the extra 8 lines for if memory requirements expand, which then means I'm just doing a 32 bit processor.

So, I guess the question I need to ask myself is do I limit the address bus on the chip to save space and cost (in terms of burning if it's done on an FPGA, in terms of money if made for real) or do I leave it to the external electronics to not bother using the extra lines which allows for much expansion?

I'm think I'm tending towards making it 32 bit entirely and letting the external electronics decide what needs interfacing to, expandability = good I suppose.

[Xardfir]

Hiya,
I was just wondering (as I don't recall it having being mentioned) what type of memory achitecture (Candy) you have in mind - 'Havard' or 'classic Neumann'?

I'm thinking that if you're taking an FPGA route, the amount of external pins available might not initially encourage having two seperate address/data busses (one for code, one for data) but the 68k architecture IIRC had the ability to use 4Gbytes of code and 4GBytes of data, with each address space accessed dependant on the type of cycle. Kind of like a 33rd address bit that is set or reset on a 'code access cycle' or 'data read/write cycle'.

A single buss (keeping it simple) could be used to start with, whilst allowing for a full Havard system (separate caches, multiple busses) later on.
Of course the question would then arise:
"How many address bits to dedicate to each of the code / data address spaces?".