Testing the μcode address generator

Posted on Mon 06 May 2024 in MUPS16

It's been almost 18 months since I had any time to work on this (life got in the way), but I've started assembling and testing the last batch of boards I designed, and working on the next lot.

The μcode address generator was the simplest piece of the control unit, so I started with that first. This is responsible for storing the instruction word being executed, and decoding its bits into the appropriate address in μcode ROM. There's not too much to it: it's a pair of 8-bit 74HCT377 latches for the instruction word, a 74HCT163 counter that increments on each cycle to allow multiple cycles per instruction (technically it could do up to 16, but the ROM is packed with only 8 slots per instruction), and some multiplexers to handle the three different ways of generating a μcode address (see the instruction set):

  • normal instructions (address is opcode * 8 + counter)
  • R-type instructions (address is (32 + (opcode-24)*4) * 8 + counter)
  • exception (fixed μcode address of 0x300 + counter)

There's a fourth piece of functionality to handle initial startup (or reset): when reset is low, this board works with the reset board to copy the contents of μcode from a serial ROM chip (not on this boarsd) into the 6 RAM chips spread across the remaining control unit boards. It does this by copying the contents of physaddr onto the ucaddr bus, and enabling the appropriate ramcsX line for each 1KB chunk (there are 8 ramcs lines, though I think we'll only need 6 of them).

Bugs

Two bugs found so far:

  • the instruction register isn't zeroed out on reset, so it's indeterminate which instruction's first cycle will run on startup. I think this is actually survivable, since every instruction in memory has exactly the same first two μcode steps, so it doesn't actually matter which one we start with;
  • the rtype internal control line isn't gated on exception being high, so if an exception happens while an R-type instruction is in IR the generated μcode address is incorrect (it will be some combination of the counter, bits 3-8 of physaddr, with bit 9 set high). I think we can also bodge around this bug by writing the exception sequence to all μcode groups from 0x200 to 0x400 (since bit 9 is forced high the minimum address we can generate even with this bug is 0x200).

Improvements

  • Add LEDs! Even if they can't be seen when more than one card is installed, they're useful for initial testing and debugging
  • Add label for slot type (Type B)