Verilog programming

I. Introduction and Goals This project involves the building of a simple, extremely streamlined CPU. It was designed in the interests of smooth implementation, rather than accuracy, so there are certain inherent design flaws in it, mostly related to high-speed timing; for our purposes, however, it works quite well. I highly recommend reading this document carefully. If I saw a need to spend time writing something, it’ll probably help you. With that said, there are many ways to implement a design project, some of which are objectively better than what’s been tested, so keep an open mind. I strongly advise you to write a testbench for each module, but the only ones which are strictly required will be listed in the deliverables section. You are going to need separate Block Designs for synthesis and simulation for the reasons described below in Simulation Considerations. Also, read section XI of this document please. Those aren’t binding instructions, but will help you quite a bit should you choose to follow them. The goals of this project are:

• Develop high-level design skills while working on a relatively modestly sized system

• Practice creating, simulating, and synthesizing Vivado Block Designs

Learn to use IP; both predefined Xilinx IP and your own packaged designs.

• Use Verilog to develop a register simulation

• Demonstrate the ability to perfect behavioral designs and multiplexing in Verilog (the meaning of this will become clear later in this document)

• Understand the function and implementation of basic CPU arithmetic instructions

• 7-Segment Display Control and Clock Division

• Button Denouncing and Input Filtering II. ISA When building a CPU, the first thing that must be decided is the number of bits the CPU controls and the Instruction Set Architecture, or ISA. The ISA can be loosely defined as “what do I want my CPU to do”, and normally includes arithmetic instructions (ADD, SUB, etc.), memory access instructions (LD, MOV from memory, etc.), IO instructions(IN, OUT, DDR, etc.) and control flow instructions (branch, jump etc.). For your sanity, we will only implement arithmetic instructions and extremely basic load functions; no external memory, IO, or control flow. Some examples of ISAs most of you know are x86 (the assembler in CMPE 310), AVR (311), and MIPS (certain 411 sections would have seen that). As you are aware, the register structure and command syntax is significantly different. This CPU is probably closest to AVR of the 3 of them. (Don’t stress about writing assembly – you aren’t going to) When assembly programs are compiled, they essentially are compiled to binary or hex files. Essentially, every command consists of various binary bits for opcodes, source/destination registers, immediate (that means raw integers, like ADD EAX, 13 in x86 for example), memory addresses, and other useful info. That is the format of the instructions your CPU will run. More on this later. This will essentially be a 16-bit CPU, which means the instruction size and register size are 16 bits. There are 16 available registers (just a convenient # for this format, not for any particular esoteric reason), which means every register address will be 4 bits (R0-R15 essentially) All arithmetic operations will be performed on the 16 bit values stored in the registers. The one thing to note is that due to running out of switches, you cannot directly load in numbers greater than 8 bits. Don’t worry too much about this. The required commands and format are listed in table 1 below. O means opcode, D is the destination register # (between 0 and 15), S is source register (same), I is 8-bit immediate (-128 to 127), and – means don’t care (doesn’t affect the instruction): Instruction Format Opcode(binary) Description MOV OOOO—-DDDDSSSS 0000 Moves Contents of RS into RD LDI OOOODDDDIIIIIIII 0001 Loads 8 bit # into RD ADD OOOO—-DDDDSSSS 0010 RD = RD + RS SUB OOOO—-DDDDSSSS 0011 RD = RD – RS MUL OOOO—-DDDDSSSS 0100 RD = RD * RS (careful) DIV OOOO—-DDDDSSSS 0101 RD = RD / RS MOD OOOO—-DDDDSSSS 0110 RD = RD % RS AND OOOO—-DDDDSSSS 0111 RD = RD & RS OR OOOO—-DDDDSSSS 1000 RD = RD | RS XOR OOOO—-DDDDSSSS 1001 RD = RD ^ RS Here’s an example. It loads 29 into R0 and 14 into R7 and adds them into R7, leaving R7 = 43 and R0 = 29: LDI R0, 29 => 0001 0000 00011101 LDI R7, 14 => 0001 0111 00001110 ADD R7, R0 => 0010 0000 0111 0000 III. Core Functions The functionality is as follows. The user will arrange the 16 Nexis switches into the positions matching the instruction they would like to execute. The instructions will NOT immediately be executed, as this would require somewhat complex timing factors such as locking the CPU until division is finished, which takes about 20 clock cycles. Rather, to deal with this problem, the instructions will be processed by pushing BTNC, the center button of the “joypad” of your FPGA. This will require denouncing modules, which will be provided for you. When the button is pressed, the CPU will “execute” the instructions. Since you cannot conceivably push the button less than about 100,000 clock cycles (~10 ms) a 20 clock cycle timing delay will not be much of an issue. As far as the 7 segment Displays are, the 7 segments will show the contents of the Destination and Source Registers read straight off the switches. Take the example above. When the ADD R7, R0 command is on the switches (BEFORE THE BUTTON PRESS) the 7-Segments will show 001C (29 in hex) on the rightmost 4 SSDs and 000E (14 in hex) on the left 4 SSDs. When the button is pressed the left 4 LEDs will show 2B (43 in hex) The one exception is that in the case of LDI (SW[15:12] = 0001), instead of a Source Register the right SSDs will show 2 0s then the 8-bit immediate instead of the source register value (since LDI has no source register). This is important, as it complicates the SSD design a bit. Your simulation, however, will not have the 7-Segment displays, as the outputs are not meaningful when examined in a sim. You may need to simulate them if they aren’t working however. You can find tutorials online to explain how SSD control on a Basys/Nexys works; feel free to base your work on those, but what you need to do is slightly more complex. Sections IV – IX describe the blocks involved in my ALU; you don’t have to do it this way, but it’s probably in your best interests to. A word about Block Diagrams – whenever you change your Verilog code for a block already in the BD, you need to go to the BD, right click on that module, and hit “Refresh Module”. Be very careful to do this; you’ll regret it if you aren’t. IV. ALU You will not be writing the ALU – signed Multiplication and Division algorithms are incredibly difficult, even for fully trained engineers. The ALU will be built using preexisting Xilinx IPs following a step-by-step tutorial provided outside this document. You will want to do this step first. You will need to add a block design and testbench for this part individually to make sure you got it correct, and it will give you a better understanding of the interconnecting parts here. V. Register File The register file will be extremely similar to the BRAM in HW2. It just has 2 read ports w/ read enables for RD and RS and 1 write port. The write register data and enable will be controlled by the Mixed output of the ALU. One caveat is the register file will need a valid output. Just always set valid to 1 for this project. The reason will be clear from the ALU – you need to hook it up to the division module. You are going to need to write a testbench for the register file by itself. This should be fairly similar to HW2 Q5, so you can adapt that one according to our specs. VI. ISA Decoding The 16 bit instruction will need to be decoded to find the ALU Operation and the Source/Destination Registers or Immediate. You will need to write a module to decide which alu op the ALU will write to the register and which register it will write to. VII. MUX The way the ALU is set up currently, for simplicity the result of any operation can be accessed at any time. This means that for ADD R1, R0, the outputs for MUL R1,R0, AND R1, R0, and all other R1,R0 instructions are available. You will use a MUX which will select the appropriate output to write to the register. This is quite like part of HW2 conceptually. VIII. SSD The overall function is described above. You’ll need to pull the RD and RS data by connecting 16 bit inputs to the Register Module above (it makes the most sense, trust me) and pull the Immediate from the instruction decoder most likely. You need to conditionally display RS or IMM as above. The one thing I will tell you, is that to display different numbers you need to set the Anode of the individual LED to 0 as such: AN <= 8’b01111111; //sets the leftmost LED on And the segments you would like on to 0 as such: 4’b0000: ssd <= 7’b0000001; (for 0, sets all segments to ON except the center one) You will need to switch LEDs on a slow enough clock to see the difference. You need to use a clock divider to obtain a clock between 60 Hz and 1 kHz (doesn’t matter too much as long as it’s in the range) and change the value of AN to the individual SSD to 0 and the rest to 1. IX. Debouncing The plan is to provide you with the modules for the button debouncing. It’s in your best interest to examine the modules, since you may see questions about debouncing and such on an exam or elsewhere and they are not complex. The 1 thing you need to do is that after putting Filter.v in the BD, right click and select block properties or double click it it and change the params listed to : Bound = 64000 Wd = 16 N = 65535 X. Deliverables 1. Vivado project (Copy the ENTIRE outer directory into a ZIP folder) 2. Report. Includes pictures of BDs, simulation waveforms from the required parts, and high-level description of each module you built. Also include anything that doesn’t work properly. If for some good reason your IO ports are not identical to that described in Section III above, describe that in detail. 3. Testbenches for ALU, Register Module, and whole design except SSDs and debouncing. XI. Friendly Advice If you’re a bit lost as to where to start, I would advise the following order: 1. Create the project and build the ALU as in the tutorial accompanying this document 2. Write a thorough testbench for ALL ALU ops, being mindful that division will take a lot of clock cycles (20 as per the tutorial, so you need a very long wait statement to account for that) and multiplication will take 4-5 clock cycles. Try to only multiply 8 bit #s, because otherwise the overflow makes the numbers really difficult to read. 3. Build the register file very similarly to the block RAM from HW2. Simply set the VALID output to 1 all the time (it seems weird, but it’s the easiest way) 4. Test the register file by itself, using the 2 read and 1 write enable and 2 read 1 write address and data ports 5. Hook the Register up to the ALU in a block diagram. You should hook RD and RS data up to A and B in the ALU (see tutorial), Write Data to the lowest 16 bits of the ALU output (you can only do MOD not DIV at this point, but don’t stress it). Control the addresses and enables manually by adding ports in the BD for them. 6. Write a testbench for the Registers and ALU to show they are connected properly. 7. Write and test the Instruction Decoder and the MUX (they’re heavily meshed with each other) 8. Hook up the MUX and Decoder to the Register file and ALU. You’ll want the 32-bit ALU output going into the MUX and a 16 bit output going out. 9. At this point, your simulation block diagram is done. All other modules will not really add much to this. Copy the BD (ctrl-A ctrl-C will work), create a new BD, and right click and paste. The 2nd BD will be the one you will be synthesizing. 10. Add ports for your inputs – a port to simulate the button, clock obviously, a 16-bit input to simulate the instruction switches, and RD, RS, and WRITE data outputs to see what’s in the registers. 11. Thoroughly test the simulation BD. You want that to simulate flawlessly before you start worrying about hardware issues. 12. In your hardware BD, stick the debouncing modules between the button input and the module they go into (hint: probably the instruction decoder). These mess up simulation timing, which is why you need separate BDs. 13. Design the SSD and figure out where to attach it 14. Run, fail, and figure out what’s wrong. The better your sims, the easier this will be to fix. 15. Write on resume you’ve implemented an FPGA CPU with a custom ISA using Xilinx IP Deliverables: Phase 1: – Design the ALU with all the IP blocks as explained in the Tutorial. – Write a testbench to test your ALU block – Write a report to explain your ALU and all the functions – In the report, explain what is your plan for the next phase. A Block Diagram of your initial proposed design is needed. Phase 2: – Submit the complete CPU design with all the modules – Write a testbench to test the CPU – Show the demo on FPGA – Write a report and explain your design with a block diagram and details, which parts are working or not working