Ghala’s Design Notebook: Processor Design VIP

Week1: 09/08/25 - 09/14/25

  • Attended the first meeting of the semester.
  • Created this notebook.
  • Read “Design Notebooks and Git” and “Development Environment”.
  • Completed necessary downloads (Homebrew,CMake, Verilator). Didn’t download VirtualBox because it says in the guide I don’t need it if I have a macOS.
  • Downloaded VSCode and suggested add-ons.
  • Made a profile in HDLBits and completed “Getting Started” and “Verilog Language Basics”.

Week2: 09/15/25 - 09/21/25

  • Met with partner Lucy Zheng to work on the RiSC-16 module Program Counter.
  • Solved the Vectors practice on HDLBits.

RiSC-16 Project repository - New file: program_counter.v

My partner and I had different approach to write the PC module but very similar logic. However I am not sure how correct it is since there is no way to test it. We faced some difficulty with figuring out the logic of the module because it is unclear what are the given inputs and which operations should the PC do or not do.

Week3: 09/22/25 - 09/28/25

  • Matched my program counter code to the testbench provided to us.
  • Created the ALU for the RiSC-16 processor.

RiSC-16 Project repository - New file: alu.v

Changes done to pc:

  1. I had the opCode as an input, now I’m using MUX_output which decides which operation for the pc to do in upstream logic. That made it simpler because I removed opcode decoding inside PC.
  2. Removed RegB port and old beq equality logic, now I’m using alu_out directly.
  3. sign-extension of imm so it can be summed with pc.
  4. reset is now active-low to match the testbench.

Discuss ALU: My implementation of the ALU is similar to the implementation uploaded by Noah. However, I used mux using the conditional operator instead of an always block. I’m not familiar with how to use the always block for mux and the differences.

Week4: 09/29/25 - 10/05/25

  • Created the register file.

RiSC-16 Project repository - New file: register_file.v

Discussion: I thought it was easier than creating the ALU, the logic was straightforward. I learned how to do a for loop at compile time, which I did not know was possible. At first I didn’t initiate the registers to zero so I got some errors when I ran the testbench, then I corrected the mistake.

Week5: 10/06/25 - 10/12/25

  • Met with Noah and my partner Lucy to discuss our progress.

Discussion: I had some issues previously with the PRs and my previous PRs weren’t accepted so I wasn’t able to push my recent updates to the design notebook.

Week6: 10/13/25 - 10/19/25

  • Created a testbench to test

RiSC-16 Project repository - New file: data_memory_tb.v

Discussion: I took so long writing this tb and used past TBs Noah provided us with as well as the internet to help me write it. The tb I designed consists of 4 tests. They test for

  1. Initial value.
  2. write and read
  3. Read when write enable is low
  4. overwrite

The hardest part is figuring out how to set up the testbench and write the first test, but then it got easier.

Week7: 10/20/25 - 10/26/25

  • started writing Instruction Memory module but didn’t finish because it was exams week. I communicated my excuse to Noah and let my partner know that I might not be able to finish my work this week.

Week8: 10/27/25 - 11/02/25

  • Wrote Instruction Memory module and the Control module.

RiSC-16 Project repository - New files: instruction_mem.v, control.v

Discussion: The instruction memory was easier than I thought. I took so long because I was overthinking it. The control file was easy to write since it’s based off the files we wrote earlier. It just took some time to write because I had to go back and forth to check what each case should be assigned as. This week when I looked at the design sheets for the processor I feel like I am starting to understand completely. Writing the control file made me put together all parts of the processor which gave me a more complete understanding of the design.

Week9: 11/03/25 - 11/09/25

  • Completed labs 1 from Onboarding Labs.
  • Started on lab 2.

Processor-Design VIP Project repository - New folders: Lab1_Ghala, Lab2_Ghala

Discussion Lab 1: CMake

Answer the following:

  1. The paths used by target_sources and target_include_directories are relative, not absolute. What file or folder are they relative to?

To parent directory that contains CMakeLists.txt. In my case it’s “Lab1_Ghala”.

  1. What are some differences between cmake and ninja?

CMake reads CMakeLists.txt and generates files that build the system. Ninja executed the generated build.

  1. Why is it important to run cmake in its own directory?

Keeps the mess out of the src directory.

Discussion Lab 2: I had no major difficulty with writing the RTL files but I couldn’t build the simulations using CMake/Ninja. I keep getting error CMake Error at CMakeLists.txt:8 (nyu_link_sv): Unknown CMake command "nyu_link_sv". and I am unsure of how to solve this.

Confusions: I still don’t quiet get the differences between Ninja and CMake and I don’t get the full purpose of them and why we’re running them this way instead of directly from the src file. It says we are building a system, where is this system located and where is it running in the hardware?

Week10: 11/10/25 - 11/16/25

  • Completed lab 2 from onboarding labs

Processor-Design VIP Project repository - updated folder: Lab2_Ghala

Discussion: After experimenting more with CMake and Ninja, I have more understanding of how to use them. This is my first time using SystemVerilog, but it’s not that much different. I still need to familiarize myself with the differences.