Last updated 1/8 1:30pm
Due: Jan 21nd -- check up. It is not due then, but please meet with the TA's by this time and talk about your progress. This checkup is MANDATORY.
Fully due Jan 28th.
The primary purpose of this part is to make sure all of the pieces of your tool chain are working for you. Start by downloading the "starter.tar" file from the course webpage. This bundle contains several files of note:
top.v This is the top level Verilog module for the chip cpu.v This is where you put your CPU design debug_console.py This is the debug console. Run by typing "python ./debug_console.py" after Your design has been downloaded to the board. Each time you download a design to your board you will need to run this console program again. And be sure to exit from this script *before* downloading a new design. usb/ This directory contains all of the USB interfacing code. You shouldn't need to edit anything here. SConstruct This is a "scons" file (equivalent to a Makefile). pins.pcf This defines where pins on the FPGA go. You shouldn't need to edit this. apio.ini This is just a configuration file for the build tool (apio).
NOTE: You can expect that throughout this quarter there will be posted updates to the files in usb/ and to top.v. For this reason be prepared to download these files and over right the files in these directories. I will try and distribute these updates without a corresponding cpu.v file, so if you put all of your work in there and other files, then the update will not destroy your work. However, each time you download an update and apply it, please, please, please backup your own work first.
To get started please look at work through the TinyFPGA BX tutorial here. In particular you need all of the associate tools (apio, scons, icestorm, iverilog, and tinyprog). For good measure, it is also useful to have verilator installed.
After working through the BX tutorial, reset your board by hitting the button on it. Then go to the directory where you unpacked the starter.tar files. Type
apio build apio upload python ./debug_console.pyIf it works you should see it print out 4 hex numbers continuously. If it does not work, try starting the debug console again. Sometimes it takes USB a bit to connect and run the software stack on your computer. If it doesn't work, contact Mark or the TA's for help.
1. inst = code_memory[pc] 2. pc = pc + 4 3. if (inst == branch) 4. pc = compute_target(pc, inst) 5. r1 = register_file(rm(inst)); 6. r2 = register_file(rn(inst)); 7. const = constant(inst);
To decode the above code snippet lines 1-4 represent the instruction fetch and 5-6 represent register read. Line 1 represents fetching the current instruction from instruction memory using the current value of PC. Then lines 2-4 represent updating PC either by PC + 4 or by PC + branch_value at the next positive edge of the clock depending on whether the current instruction is a branch or not. Lines 5-6 represents reading out two values from the register file (which values are readout depends on the instruction). Finally line 7 represents sending useful data back to your computer through the USB connection to your hardware.
To demonstrate that your Verilog works use the debug ports to output useful information. For example, you can fill the register file with useful information using an initial block and program the code memory with instructions that read various registers. You can then pipe bits from the register file to the debug ports. Similarly, you can decode the constant that is contained in the instruction and then pipe bits of this constant to the debug ports. Remember it is incumbent on you to ensure your design works and to be able to demonstrate that it works with sufficient tests that you can show to the instructors.
As previously stated, I encourage you to use "behaviorial synthesis". But follow a trust but verify model. Write clean Verilog, but look at what is getting synthesized. In particular pay close attention to LUT and BRAM usage. You will want to periodically run the P&R tool manually like this:
~/.apio/packages/toolchain-icestorm/bin/arachne-pnr -d 8k -P cm81 -p pins.pcf -o hardware.asc hardware.blifAnd study the output. In particular the output right near the top where it says "After packing". Look at LC usage and BRAM usage. When you add the register file to your design you want it to use BRAMs and not LCs. So watch these counts before/after adding that part of your design.