Designing an 8-bit CPU - 2 - starting the register file

After setting out my goals for an 8-bit CPU using discrete logic chips, I've started to design the register file.
My audio setup is still a work in progress :) I have been concentrating on designing and wiring rather than microphones.

[@ArneChristianRosenfeldt]

I have a hard time to believe that SRAM is not the fastest solution in the end, kinda like the ZeroPage in the 6502 only that SRAM is faster. Change you ISA to allow for instructions with more bits. Two byte instruction words. pcEngine and SNES (and sega genesis) had SRAMS . Those chips have 32 kB, but only 8 data pins. Data pins really seem to be a problem. Maybe if we look at old SRAM as used in the Commodore PET and VIC-20. 4kB chips. So for 16 bit addresses and program pointer we still want two of them. So 8kByte register file. The ALU would still be 8 bit or 4 ( Ben Eater uses 4-bit chips ). Atari JRISC is an ISA, but the only implementation has a timing which can be explained by the latches in front of the ALU. Just like 6502 and Ben Eater SAP-1 the contents of the register file is first transferred into latches. Then like on Z80 you could use a multiplexer to let your 4 bit ALU go over the data. In all those cycles you can load the next instruction ( pipeline ), so that it does not hurt to fetch multiple bytes into the instruction register. The decoder should wait when a branch opcode is detected. So like on Z80, every first byte fetch is followed by a pause where the memory 8bit bus can be used for something else. I know this is not very MIPS like. With MIPS the ALU is fed directly from the registers because we need the result with minimal latency because every instruction needs the ALU. For load store it does the addressing mode. For branch it first checks for the condition and then calculates the branch. But economic multi-port register files are very much a specialty of the a real microprocessor where ALU and file sit on the same chip. You could order prototype chips for 300$ . Just ALU and file. Keep the control logic outside to be able to tinker with it. I don’t see the problem with multiple cycles. Loops can be coded in microcode. So yeah, need a micro instruction pointer and a counter.

[@phodopus42]

Thanks for commenting and offering ideas 👍 SRAM is definitely the best solution for the system memory, agreed. (DRAM would be faster but is a pain with the refresh cycles. It was used on, for example, the BBC Micro because 32KB of 4MHz RAM back then really needed DRAM.) However, my question was about the storage of registers in the register file. Modern CPUs have many registers (over 100 in typical x86-64 designs, even if only 16 are exposed to the ISA), and will use multi-port SRAM, that is, something that supports reading multiple addresses registers at once (i.e. concurrent dispatch of multiple instructions accessing registers), and even writing the same register as it is being written. This kind of setup is not possible with "ordinary" SRAM -- set an address, wait ~55ns, and you have a value on the outputs. I certainly can't read and write a single value in one "clock" of SRAM (although SRAM strictly speaking doesn't have clock cycles). I went with 74x574 octal latches because I can do precisely this: I can read and write on the same clock because they are edge-triggered. I only need 8 chips, so it's not too bad. You are right about the 6502 -- the zero page is *almost* like a set of 256 registers. Accessing and updating still takes multiple cycles, though. I wanted something that's a) built without microcode, and b) can retire 1 instruction per cycle (in the optimistic case). Variable-byte instruction decoding will be painful, I think. Of course, on an FPGA (or real silicon), it becomes less painful. But this is discrete chips, and wiring 100 connections and finding the 1 single wire that's made a bad connection is starting to drive me nuts 😆 Thanks again for commenting... you've made me have a good think about the design. Sorry if I've misunderstood anything you've explained. I might warm up to the idea of a fixed 2-byte instruction width 🙂 Anyway, I've probably said this before: I am kinda working this out as I go along. I'm definitely no expert in any of this (which should be pretty clear). I wanted to turn my "oh, I wonder if this would work?" into "wow, this circuit actually does something!" I'm slightly surprised anyone is even vaguely interested (!)

[@ArneChristianRosenfeldt]

@@phodopus42 oh, I guess I should recheck the single cycle per instruction thing of yours. Load and Store need two cycles as does immediate8. So from a single bit to a 4 bit counter it is not much more parts. My motivation for even a second pointer comes from all the bugs in the original 6502, which tried to do 16 bit without it. It seems that you have the hard facts about RAM and I only know theory. SRAM is used for cache because it is faster than DRAM. Consoles used SRAM and ran faster than Homecomputers with DRAM. I agree that SRAM lacks separate in and out ports. It is so weird that each cell resembles a latch, but to save transistors and increase capacity, the latch is connected to the data line via transfer gates. Reading uses a slow connect to neutralised lines not overwhelm the small transistors, followed by highZ read out. Write precharges the lines and stamps this charge into the cell. Yeah, many CPUs (says a book I own, but my only example is JRISC ) have 2 port register files, but none has 1 port. Old DRAM had separate input and output ports for read modify write. Why does google find me tons of dual port RAM where both ports can write at the same time, but none with dedicated read and dedicated write port. The specs and datasheets don’t hint at a multiplexer to assign external requests to the read or write port on an internal block of latches. This would explain why those chips are so slow. Even with serialisation on collision dedicated read and write lines would make the chip faster.