In the very first post on this project, I listed my design constraints. The most important of these came last:
- Working on it must make me happy
It turns out that writing VHDL testbeds does not make me happy. And the complete ALU needed a large and complicated testbed.
After a great deal of procrastination (including writing a transpiler for a language that was much more pleasant to work in than VHDL, but never got to the point of being able to create the testbed the ALU needed), I made myself sit down and just do it. After a lot more work, the ALU finally passed all of its tests.
The high-level structure from the previous post is still true. There are two main inputs, A and B. B is fed through the shifter (with its own 'shift amount' input), the inverter, and then both go into the adder. In addition to ADD, AND, OR, and EOR, the adder can also pass the B input directly to the output. Not shown are a collection of multiplexors to select a source for each of the inputs, and the large number of control signals to get it to perform the right operation.
There's also another block that wasn't shown on the diagram, but which turned out to be a fairly major chunk of logic. This takes the inputs, the adder output (including carry out), shifter carry output, and a collection of control lines, and generates values for the flags. It has to work on 8, 16, and 32 bit operations, and also handle the N and V flags for the BIT instruction. Here it is, squeezed into as few LUTs as I could manage
 |
| The 65020's ALU flags component |
With the ALU complete, all that was needed was to construct the rest of the CPU. That was a much simpler and quicker task: it took far less than the year of procrastination that the ALU did. I already had the structure of it worked out in the C++ simulator, so most of it was just a matter of turning those components into VHDL, with a bit of fixing up where things weren't a good fit for an FPGA.
And now... it's working. There was a lot of debugging, of course, but it didn't take too long to get it running its first instructions. Since that milestone it's been a pleasant process of writing software for it and working out why it doesn't work. As the fault can be in the software, the assembler, or the CPU itself (and sometimes in all three), that's been a lot of fun.
You'll be wanting a screenshot, of course. Here it is
 |
| The C640 computer running a variety of colourful tests |
Each new test uses some instructions that the others hadn't, and these occasionally throw up new bugs to be fixed. Fortunately these problems seem to be getting less frequent. It's almost looking like a computer.
The next step is getting the PS/2 keyboard interface working. It's close - the FPGA side appears to be good, but for some reason the software is sometimes dropping key presses.
