Approaches to storing and addressing microcode for homebrew CPU

Question

I've been teaching myself about CPU architecture for a while now and have successfully designed a couple myself. They were always based around microcode to drive the CPU's control lines.

The microcode is stored on one ROM chip and addressed by composing an address out of (1 = LSB):

1. Bank
2. CPU flag states
3. Instruction
4. T-state

Let's take my latest CPU as an example of how the address is constructed:

1. Bank (3 bits) - There are 48 control lines in my CPU, so I need 6 bytes to store all control line states. The bank part of the address allows me to address 6 bytes in the microcode ROM.
2. CPU flag states (3 bits) - I narrowed down my flags to zero, carry and compare. Need 3 bits to address all combinations
3. Instruction (8 bits) - The instruction set requires over 127 op-code, so I choose to go with 8 bits.
4. T-state (5 bits) - Some instructions take over 16 t-states to complete (complex ones like conditional CALL / RETURN) so with 5 bits I have enough room for up to 32 t-states

The final example microcode ROM address would look something like:

[flags][instruction][t-state][bank] [000][00000000][00000][000]

Now for my question: In the above example, I seem to have reached the limit of what I can do with this approach. My microcode ROM address is 19 bits long and I have found one chip that supports it (29C040) but it seems that I don't have a lot of options if I want a large address.

I'm thinking about my next CPU which will need more flags (negative, overflow, parity), and who knows, maybe even a few more control lines or an extra bit for T-states.

What would be a better approach to storing and addressing my microcode in that case?

The only thing I can think of right now is to:

• Add more ROM chips (would only free up 1 extra bit? per chip doesn't seem a good approach)
• Limit the instruction set (also, would only give me 1 - maybe 2 - extra bits)
• Limit the number of control lines, but that would allow for less control over the CPU...

I wonder how this is solved in professional, microcode-based CPUs and what I'm missing here.

Answer 1

Your addressing scheme uses completely disjoint areas of microcode memory for every possible instruction. Most CPUs have a lot of microcode that can be shared among instructions. For example, instruction fetch, operand read and result writeback are typically identical across large groups of instructions, with the only difference being the specific ALU operation performed in the middle.

It's also very odd to store the bytes of the microcode word serially — this means that your ROM must cycle 6 times for every "T state". It is much more common to make the microcode memory wide enough so that it cycles at the same rate as the rest of the logic.

Finally, it sounds like you're experimenting with CPU design. Maybe you should consider using wide SRAM for your microcode memory, and loading it up from some external source (an Arduino or equivalent) each time you power up your system. This would make it a lot easier to make changes.

Answer 2

For my homebrew CPU, the CSCvon8, I used a 4Kx16 ROM to hold my microcode. The 8-bit instruction is latched into an 8-bit register to form 8 of the 12 address bits to the microcode ROM.

The remaining 4 ROM address bits come from a 4-bit counter. This allows each instruction to index into 16 microinstructions. And the ROM has 16 bits of output, so I've got 16 control lines I can set/clear per microinstruction.

One of the control lines resets the microcounter to zero, so instructions don't have to have exactly 16 microinstructions. They can be composed of from 2 up to 16 microinstructions.

You could move your flags bits out from the ROM address space. I send three control lines out to a 74HCT151 8:1 mux. This selects one of seven flag bits to send as a control line to the program counter. To generate all the jumps (==, !=, <, <=, >, >=, always, never) I cheat by having my own ALU. You could use some combinational logic to join the N and Z flags appropriately.

What you've got is horizontal microcode which is what I'm using as well. You might want to consider vertical microcode, or another format where the microcode has its own internal branch/jump, i.e. to jump the microcounter based on the flags values.

Have a look at this example: https://web.archive.org/web/20160305185415/http://www.mythsim.org/ and my take on the same approach: https://minnie.tuhs.org/Programs/UcodeCPU/index.html (scroll down to "The Microcode Logic").