Hardware Modification Guide

One of the major benefits of a soft processor is that it's easily modifiable: if you need it to take up even less space, you can start cutting out chunks, and if you need a custom "linear regression" instruction, well, you can feel free to add it in. This document will try and give you an overview of what's in the supersmall processor, so that you can find your way around within the source code.

NOTE: it is highly recommended that you at least have the "simulate" scripts working properly, so that you can validate whether or not your changes break the processor, before making any extensive modifications.

defines.v

The absolutely easiest way to make changes is within defines.v. Simply comment or uncomment the preprocessor macros within defines.v to enable or disable support for exceptions and debugging. A few notes:

system.v

The top-level module for the entire supersmall processor. What you're going to modify here are inputs and outputs: this module is where to look when you're figuring out how to connect this processor into your existing FPGA design, and if you make any changes in the connectivity of the individual modules, you're probably going to have to do some routing in system.v. In particular, this is where you would connect any memory-mapped I/O devices that you may wish to have the processor access.

control.v

The brain of the processor. If you're planning on adding any new logic (i.e., new instructions), this is the file you're going to have to modify. I recommend looking at the State Machine Diagram and the State Machine Reference before making any modifications.

Warning: the state machine uses a continously-running cycle counter to determine how long to remain in each state. Make sure, if you add states, that you reset the cycle counter before exiting the state. Otherwise, your processor will develop undefined behavior.

datapath.v

Where all the hardware is kept. Notice in particular the multiplexers section, where you're probably going to be making changes. My warning to you is, if you want to keep things small, ensure that any multiplexing you do is only 1-bit. The easiest way to use ALUTs fast is to put in 32-bit multiplexers.

constants.v and isa.v

If you've been looking through control.v and datapath.v, you'll notice that there's a large number of NAMED_CONSTANTS. This is where they're defined: isa.v holds anything to do with mips instruction decoding, while constants.v has everything else, including multiplexer codes. Although you might not need it for a quick hack, I recommend continuing the use of NAMED_CONSTANTS, if only for your own sanity.

cop0serial.v, bru.v, alu.v

These specialized modules are unlikely to be worth modifying: they're all highly-optimized pieces of verilog that do their job (moving coprocessor registers, checking branch conditions, or performing arithmetic respectively) and little else. The only one you might be interested in delving into is cop0serial if there are additional pieces of control logic that you need implementing, but otherwise, I recommend you treat them as black boxes and concentrate your efforts elsewhere.

shiftreg.v, upcounter.v

Boilerplate verilog code. Not even worth discussing.

imem.v, regfile.v, dmem.v

Altera-specific megawizard-generated files. If you're planning on implementing the supersmall soft processor on anything other than an Altera Stratix III, these are the files you're likely going to have to change. If porting to another Altera architecture, it should be fairly straightforward: open them up in Quartus' megawizard plugin-manager and edit them accordingly. If porting to a completely different FPGA architecture, then these are going to be your main problems. In particular, make sure that whatever replacement you have for dmem.v has byte-enables, or it won't work properly.