Feedback on processor design

[davidv1992]

I recently decided that I wanted to build a complete computer out of only discrete transistors, resistors, diodes and such. At https://github.com/davidv1992/Trans1/raw/master/DR1.pdf I have uploaded the first design document I made for this project, and was hoping to find people wanting to comment on it, and here seemed as good a place as any.

I am primarily looking to figure out if I have missed useful additions to the instruction set (see section 5), although methods for reducing transistor count in the various components would also be appreciated. When responding, please note the following:
a) This processor is intended to be small, since I am trying to not go entirely stirr-crazy soldering the thing together. This means that this is not intended to be a feature-rich design. I am primarily intrested in whether I missed functionality that would be difficult or long to implement in code, but that would require (relatively) few gates/transistors to implement in the hardware.
b) I am planning to use through-hole components, I simply don't have the skills needed to solder surface mounted components, and am unwilling to make this the project to learn that.

EDIT: Fixed url

[alexfru]

Have you considered using an FPGA instead?

[Octocontrabass]

You probably shouldn't use a file host that deletes the file after one download.

I suggest comparing your project to this CPU made of transistors. (Note that this one is using surface-mount components. The creators claim it would be about 19 square feet if it were built using through-hole components.)

[davidv1992]

Sorry for the shaky file host, I have bit the bullet and created a git repo that now hosts the design document.

@alexfru: As for using an FPGA, yes i have considered it, but for me part of the fun is working with discrete components and designing almost everything from scratch.

@Octocontrabass: Thanks for the link to the MOnSter project. Their size estimate is somewhat on the large size for through-hole components, my best guess is that it is at least in part based on the fact that they seem to be (somewhat) following the original layout of the MOS 6502 itself. Judging from their pictures, significant portions of their board are left unused. I'm hoping to keep mine well under a square meter of circuit boards.

[Brendan]

Hi,

Sorry for the shaky file host, I have bit the bullet and created a git repo that now hosts the design document.

I'm not sure that's a good idea - a determined attacker may still be able to discover the URL and obtain the classified/secret documents.


Cheers,

Brendan

[davidv1992]

Hi,

Sorry for the shaky file host, I have bit the bullet and created a git repo that now hosts the design document.

I'm not sure that's a good idea - a determined attacker may still be able to discover the URL and obtain the classified/secret documents.


Cheers,

Brendan

As said, I misunderstood my first file host, didn't much care for the "secrecy" they offered (or not, as you mentioned). Feel free to read and share that document if you want.

[Brendan]

Hi,

As said, I misunderstood my first file host, didn't much care for the "secrecy" they offered (or not, as you mentioned). Feel free to read and share that document if you want.

I found it (originally I didn't realise you've edited your first post to update the link).

After a very quick look; I think you've under-estimated the bill of materials. For example; 16 boards with 8 bytes of RAM per board would consume almost all of the transistors (128 bytes = 1024 bits = 4096 transistors) without any address decoding logic.


Cheers,

Brendan

[davidv1992]

@Brendan: I redid the calculations for those, and still arrive at the same numbers. However, do note that I am planning only 8 RAM boards (so 64 bytes) at the most, precisely because they take so many transistors. That reduces the part count for those to about 2700 transistors. That still is more than half of the total number of transistors used, but given the minimalist nature of the rest of the processor, that is not unreasonable.

The 16 boards you are most likely referring to are ROM boards, which only need a single diode per bit, and then only if that bit is actually on (or off, depending on which set of datalines I decide on using to perform reads). Those boards need a lot fewer transistors as a result of that.

[Brendan]

Hi,

@Brendan: I redid the calculations for those, and still arrive at the same numbers. However, do note that I am planning only 8 RAM boards (so 64 bytes) at the most, precisely because they take so many transistors. That reduces the part count for those to about 2700 transistors. That still is more than half of the total number of transistors used, but given the minimalist nature of the rest of the processor, that is not unreasonable.

The 16 boards you are most likely referring to are ROM boards, which only need a single diode per bit, and then only if that bit is actually on (or off, depending on which set of datalines I decide on using to perform reads). Those boards need a lot fewer transistors as a result of that.

Considering that something like "x << 4" is going to consume 4 instructions (and I assume at least 4 bytes) your RAM and ROM sizes are going to be very limiting - so limiting that (from an economics perspective) it'd probably be more viable to not have any CPU and just have "program boards" containing special purpose logic (e.g. maybe a little like Magnavox Odyssey).

I'm also wondering why discrete transistors (and why not something like 7400 series logic gates). Creating one logic gate from transistors sounds like fun the first time, but after that it'd quickly become a tedious chore.


Cheers,

Brendan

[davidv1992]

Hi,

@Brendan: I redid the calculations for those, and still arrive at the same numbers. However, do note that I am planning only 8 RAM boards (so 64 bytes) at the most, precisely because they take so many transistors. That reduces the part count for those to about 2700 transistors. That still is more than half of the total number of transistors used, but given the minimalist nature of the rest of the processor, that is not unreasonable.

The 16 boards you are most likely referring to are ROM boards, which only need a single diode per bit, and then only if that bit is actually on (or off, depending on which set of datalines I decide on using to perform reads). Those boards need a lot fewer transistors as a result of that.

Considering that something like "x << 4" is going to consume 4 instructions (and I assume at least 4 bytes) your RAM and ROM sizes are going to be very limiting - so limiting that (from an economics perspective) it'd probably be more viable to not have any CPU and just have "program boards" containing special purpose logic (e.g. maybe a little like Magnavox Odyssey).

I'm also wondering why discrete transistors (and why not something like 7400 series logic gates). Creating one logic gate from transistors sounds like fun the first time, but after that it'd quickly become a tedious chore.


Cheers,

Brendan

To be quite honest, from an economics perspective, this entire project (even with special purpose logic program boards) can be called not-viable. I have started to look into the Odyssey, and that kind of design, I am not sure it is something i'm interested in, but it looks intriguing. Thanks for mentioning/suggesting that.

Taking inspiration from special purpose logic boards, I could (in the future) potentially build special purpose memory boards that carry out such operations. Using that, something like x << 4 could be done in 2 instructions, and if such a special purpose board used one of the two low memory slots those instructions would take only 2 bytes.

On the why discrete transistors, for one I am one of those persons that likes the sort of tedious chore of repeatedly soldering the same thing. Also, I just like the idea of having designed almost everything myself (with the exception of the transistors and resistors that is), and being able to reduce the number of active components to an absolute minimum.

[alexfru]

I am primarily looking to figure out if I have missed useful additions to the instruction set (see section 5)...

XOR.

Would be nice to have addition/subtraction with carry/borrow (and therefore a few instructions to set/clear/invert the flag, not to mention the architectural existence of the flag itself) and shifts/rotations through carry. In case you ever want to handle integers longer than 8-bit without writing lots of stupid code. (Although, it's all stupid anyway, even the 8051 is much better than this).

I'm not seeing any instructions dealing with interrupts other than waiting for one. What about disabling/enabling/masking interrupts? What about entering and leaving ISRs (their location, disabling interrupts on entry (unless only one interrupt can be serviced at a time), returning from an ISR and possibly acknowledging and re-enabling interrupts)? If interrupts are asynchronous, what about preserving and restoring the context of whatever an ISR preempts? Any additional registers or dedicated memory locations for the save/restore area?

How about stack and subroutines? Would be handy for long things that you wouldn't want to duplicate just because you want to use them in more than one place.

[davidv1992]

XOR is currently present as it is very simple to implement into the adder by allowing/inhibiting carry propagation. I am not to sure it should be a priority though.

As i already want to store carry out for flags, I am currently planning to allow feeding it back into the adder, turning the shifts into rotate left/right sounds interesting, need to have a think about how I would implement that exactly into the instruction set.

I am currently not planning on having interrupts beyond the SLP instruction. The SLP instruction started from me noticing that I had an instruction left close (in terms of encoding space) to the HLT instruction, and currently it would be primarily intended for delay loops, reducing their complexity. For input, the only source of input is going to be external buttons, and given that this is going at any time to be a single user/single program machine, I think polling for input is acceptable.

Because there is no real interrupt mechanism, I also decided to remove any form of stack. Yes it would be nice to have subroutine functionality, but within the limited memory I don't think it is going to be all that useful (though I could be completely wrong on that, I will see once I build a simulator), and removing it removes the need for a register that needs to drive the data bus. At the moment, I'm liking those savings more than the added functionality of a hardware stack.

It is good that you mention it though, because currently I don't have indirect jumps. Given that programs are mostly in ROM, it might be useful to make one of my jump commands take its destination address from the registers.

[davidv1992]

Thank you everyone for the feedback. I have been able to use it to refine my design a bit. I have managed to add both rotates through carries and indirect jumps to the instruction set in a way that didn't cost too many components.

I have spent the last few days planning out the exact opcode assignments, and building an assembler and simulator. Based on experience with those, code densities are roughly what I expected: not great, but workable. It is quite a fun exercise to try to optimize the small programs I have for size.

Furthermore, I have figured out a few more optimizations for gate designs. Using this, I am hopeful that the total build can stay below 3000 transistors.

[glauxosdever]

Hi,


I don't know if this is relevant for your design goals, but I'll suggest some more operations. Negation, reversed subtraction (B - A), possibly multiplication/division/modulus could be useful too (but they add complexity). Maybe even bitfield packing/unpacking (mask and shift in one instruction). Also XOR and shifting by more than 1 as others have suggested.

In case you design something more complex as a later project, I suggest using Logisim or some "real" EDA software (it might push you back though - EDA software is usually hard to use).


Regards,
glauxosdever

[Sik]

I'd forget about multiplication/division, that stuff is going to be huge. There's a reason why it wasn't there in early processors and when they first got introduced they were extremely slow (as they still were microcoded because it just wasn't feasible to include dedicated hardware out of sheer size).

I'm also wondering why discrete transistors (and why not something like 7400 series logic gates). Creating one logic gate from transistors sounds like fun the first time, but after that it'd quickly become a tedious chore.

Why 74xx when FPGAs exist? And why FPGAs when it could be emulated?

The use of discrete components definitely seems to be the whole point of the project. Arbitrary restrictions exist for fun =P