4-bit CPU in TinyFPGA Project

Rayslogic Home Propeller II Propeller I TinyFPGA TinyFPGA To P2Eval

Now that we have the TinyFPGA connected to P2 Eval board for input and output, we can move on to our project:
Implement a 4-bit CPU inside the TinyFPGA
- Why do this?
  - A while ago, I implemented a 4-bit CPU with the P1 microcontroller. It was fun to do.
  - Probably a couple years ago, I tried to learn FPGA, but didn't get very far, even with high end FPGA boards. But now, with TinyFPGA, thinking I'll have better luck starting from scratch with this bare board.
- Can this be done?
  - No idea...
- Do I have the skills to do this?
  - Not yet...
- But, it's already been done!
  - Yes, appears to be a port of the Nibbler to System Verilog here: GitHub - bchangip/NibblerCPU: 4-bit CPU written in SystemVerilog
  - System Verilog looks to be a superset of Verilog to include "system verification"
  - We may "borrow" from that as needed
Where to start work? --> 4-bit ALU
- This is the really the heart of the CPU
What to work on first? --> 2-bit adder then 4-bit adder
- Then 2-bit adder/subtractor, then 4-bit adder/subtractor
- Starting with 1-bit half adder
- Schematic or Verilog?
  - Seems we could do this either way, but experts seem to say Verilog is better, so we'll try that.
- This site seems to show a decent way: Half Adder in VHDL and Verilog (nandland.com)
  - Copying from there, added a halfadder verilog file module and then used it in the main module
  - Project files here (upper 6 bits of output are still the counter output, lower two bits are sum and carry output)
  - Interactive test works:
- Next step is 1-bit full adder
  - Ran into an issue! After adding the full adder as a seperate file, there was no output from FPGA!
  - Seems Diamond Lattice can get confused about which .v file is the top most file.
  - Had to go into Project-->Active Implementation-->Set Top Level Unit and pick the right one:
  - Step 2 files are here
- Next step is 4-bit ripple carry adder (still following nandland.com)
  - Diamond did not like the parameter not having an initial value, so added that
  - Instead of making registers for inputs, concontenating groups of 4 I/O inputs using braces (Just figured this out!)
  - Still using counter on upper output bits, but will remove that soon
  - Here's the files
  - Here's the test
Where to go next? Could do look-ahead adder. But, looking at some CPU verilog, people just seem to do simple math for their ALU. So, that 4-bit adder code can be replaced with just a couple lines of verilog with something like output = input1 + input 2.
- Ok, yes this works and is MUCH simpler. Here are the files. Note: You may need to add JustAdd.v back into the project for some reason, not sure what happened, but seems it was removed from project when zipped up.
- Next, we clean up the code by moving everything to main .v file, removing the counter, and deleting must unused lines. Files for Step5 here.
Next step is to implement the 74181 in Verilog.
- This has been done before, so there is code to borrow from.
- There are some design decisions though. Think we'll use active high logic (instead of the real ones active low). Maybe we'll implement all the functions, not just the ones used by Nibbler.
- Ok, going from some C source code on Github, have implemented the full 74181 in Verilog. It's really amazing how close Verilog is to C. Was able to use the P2 to verify that the C code and FPGA are giving the same output. The original code was using active low logic I/O, but was fairly easy to switch to active high (except for the carries).
  - Figured out that since this is all combination logic, we don't what the outputs to be registers, don't need an always block, and want to use blocking assignments (using "=") instead of "non-blocking assignments (using "<="), as is always the case for combinational logic. See here for more info.
Next step is to figure out how to the 74173 4-bit register chips.
- One issue is that, apparently, you don't do tristate inside of FPGA, just at the I/O pins. So, need to use a 4-bit multiplexer to say which chip is driving the bus.
Implemented 74163 counter in Verilog
- Got ideas from here: Microsoft PowerPoint - L5- Sequential Verilog (mit.edu)
Implemented the Program ROM as SRAM
- Notes on how to do ROM are here: Ch01-P369527.indd (umbc.edu)
- Here's the Verilog project files that address from 4 fixed bits and 8 I/O and then puts the ROM output on
- It gives some warnings about the ROM not being driven and not having an input port, but I think that's because it's actual SRAM instead of ROM
Trouble combining Program ROM output together with Fetch to form 12-bit bus
- Lattice Diamond gave a program error when doing this...
- Instead made Program ROM output registered and driven by FPGA clock and other virtual chips driven by a slowed down version of the FPGA clock.
- For the ROM files, converted to hex using srecord-1.63-win32 like this: srec_cat microcode_1.bin -binary -o microcode_1.hex -Ascii_Hex
  - Had to manually delete the first line of the output file to make that work
Next problem is the 74244 bus driver... Don't see any way to do that in FPGA...
- Think way to do this is with a multiplexor.
- Same end result, but will have the control signals pick which set of 4 wires is applied to the Data bus
For the RAM, first tried this way RAM Verilog from here: Implementing Inferred RAM (Verilog HDL) (intel.com)
- That ran us out of resources and wouldn't compile with 4K of RAM
- Instead, trying the IP RAM. Seems to compile, but gives a warning about not finding ram, so not sure if it's working....
When ran out of resources (due to RAM I think) converted one of the microcode ROMs into IP ROM
- Used srec_cat with a different option to create the .mem file
- Had to manually delete the comments at the top of the .mem file to make it work.
- Also deleted all the 0's past line #128 as only using 7 address bits, it fails otherwise...
It's Working! At least partially. Haven't tested RAM and there's no I/O yet.
- Here's an at least partially working 4-bit CPU project running a simple test code
- Used the Nibbler assembler to create the binary program (added test code to Guess the Number example) and used srec_cat to create the hex.
Took a peek at a FPGA Nibbler in github.
- It's interesting how they did things. I like the microcode implementation for being asyncronous, but it's not really a ROM, right?
- The ALU is very simple and doesn't do all the possible functions, like ours does.
Got RAM working! Just had to fix the else if () statement that applied RAM output to the data bus.
- Noticing that the # of slices used depends on the the program
  - For the test program based on the "guess the number", we're at 97% usage
  - For the memory test program, it's only ~20%
  - Going to make the other microcode ROM EBR too. But, might not save much as is mostly 0's.
  - Hopefully, that will be enough to complete this.
Think it's fully working now! Project Files Here.
- While getting the OUT ports to work, found an error in the 74173 code regarding the gate enable.
- Figured out that the progrom code is eating up a lot of the slices. Could put it in EBR, but that's a pain as have to create a .mem file and associated .v file for each program then... The Guess The Number program just barely fits with 98% of LUTs used...
  - Probably easier than erasing and writing to EEPROM like the real thing though...
- Using P2 microcontroller to do interactive test where it reads a nibble in the IN port and then writes it to OUT0 port, applied to 4 pins where I have LEDs to monitor.
- This test assembly code is placed at the beginning of the Guess the Number code, see test1.asm to see it. It counts up, then counts down. Then, endless loop of showing 5 then A then the input.
- Next, need to do a more comprehensive test... Maybe we can do a fake LCD in the Microcontroller and have it show the screen over serial connection.
Now at full speed, ~2 MHz. Project Files Here.
- Mastermind and Guess the Number examples work. Waltz plays music, but display is wrong. Frogger doesn't seem to work, display is wrong.
- Had to move Program ROM into IP memory and reduce RAM to make it fit as other programs were to big.
  - Changing program files isn't so hard when you include the .ipx file instead of the .v file for the Program ROM. Adding as a .ipx file is an option when creating the IP memory.
- Not sure why Waltz and Frogger are giving me trouble... Think it might be crosstalk between pins, but not sure.
  - Maybe because these ones have a lot of audio...
  - Prop2 is seeing extra nibbles (value zero) on incoming display input, which get interpreted as end of line chars I think.
  - Could break out the oscilloscope and try to figure out what's going on, but think will just move on for now...