Xingyu’s Design Notebook
Week of 14 September 2026
Project Work
- First Design Notebook PR #560: Created my first design notebook and submitted a pull request.
This week, I set up my development environment by configuring Git, GitHub, and SSH authentication. I forked and cloned the official repository, created a working branch named xingyu-lab1, and added my first design notebook. I committed and pushed my changes to GitHub and opened PR #560.
During the setup, I initially entered the cd command incorrectly because I missed a space. I corrected the command and successfully navigated to the repository. I also verified that SSH authentication and Verilator were working correctly.
Lab 1: My First RTL Project
- My Onboarding Repository: Completed Lab 1.
I am not familiar with Git and SystemVerilog yet. For this lab, I mostly copied and pasted the example code from the lab manual. I created a simple AND gate and a testbench. I followed the instructions to use Verilator, and all four tests passed.
I learned some basic Git commands and how to run a simulation. I still don’t fully understand all the SystemVerilog code, especially the testbench. I also had some trouble using Terminal because I accidentally typed file names as commands. I hope to understand the code better in future labs.
Week of 27 September 2026
Lab 2: SystemVerilog RTL Fundamentals
This week, I completed Lab 2 and learned the basics of SystemVerilog RTL. I built an ALU using always_comb, a counter using always_ff, and a Moore FSM that detects 1011. I also learned the difference between blocking (=) and nonblocking (<=) assignments.
For most of this lab, I followed the lab instructions and copied and pasted much of the provided code, then modified the missing parts and ran the tests.
I had some trouble saving alu.sv in Pico because of an “Illegal byte sequence” error. I solved it by writing the file from Terminal using cat and EOF. I also had trouble understanding overlapping FSM transitions, but I learned that the FSM keeps partial matches instead of always returning to S0.
All ALU, counter, and sequence detector tests passed with Verilator.
Week of 5 October 2026
Lab 3: SystemVerilog Verification and FIFO Design
This week, I learned how to verify SystemVerilog designs using self-checking testbenches. I wrote directed and randomized tests for an accumulator and a FIFO.
For the FIFO, I tested reset, normal reads and writes, full and empty conditions, pointer wraparound, simultaneous read/write, and rejected operations when full or empty. The FIFO uses memory, read/write pointers, and a count to track how many entries are stored.
I also used randomized testing and a reference model. The reference queue kept track of the expected FIFO data, which made it easier to compare the DUT output with the correct result over many random cycles.
I had some trouble with Verilator width warnings and accidentally entered SystemVerilog code directly into the Terminal. I fixed the width issue by using a wider temporary random variable and then selecting the needed bits.
All accumulator and FIFO tests passed with Verilator.
Week of 12 October 2026
Processor Microarchitecture
This week, I looked at the processor schema and the Module Abstractions document. I am still new to computer architecture, so I focused on understanding the basic parts of the processor.
I learned that the register file stores values in registers, and the ALU is used to do operations such as addition and subtraction. I also learned that the processor uses different connections and control signals to decide where data should go. I am still not sure which module group I was assigned to after the groups were merged, so I have not started working on a specific module yet. I plan to confirm my group assignment and then learn more about the module I will be working on
Week of 19 October 2026
Instruction Immediate Module
This week, I started working on the Instruction Immediate module (instr_imm.sv) for the processor core. I was assigned to the implementation issue and followed the team’s Git workflow by forking the main repository, creating a feature branch, and working on the module there.
Before writing the module, I learned how the different RISC-V immediate formats work. I learned how to reconstruct I-type, S-type, B-type, U-type, and J-type immediates from different parts of the 32-bit instruction. I also learned how sign extension works and why branch and jump immediates have a zero as their least significant bit.
For the implementation, I used the opcode to determine the instruction type and funct3 to handle the special shift-immediate instructions. The module now generates the 32-bit immediate for the supported instruction types.
I used Verilator to check the module for syntax and lint errors, and it passed without warnings or errors. I then committed the changes, pushed them to my feature branch, and opened a pull request. The pull request is currently waiting for code-owner review.
I am still getting used to remembering the exact bit positions for each immediate format, especially B-type and J-type, but I understand the general process much better now. I have not started the Level 1 testbench yet because that will be part of next week’s verification work.
Week of 26 October 2026
Instruction Immediate Level 1 Verification
This week, I started working on Level 1 verification for the Instruction Immediate module. My instr_imm.sv implementation was merged into the main processor repository, so I moved on to the testbench issue for the same module.
I updated my local repository with the latest changes from the main repository and created a new feature branch called instr-imm-tb. I also looked through the Level 1 verification README and the provided SystemVerilog testbench template to understand how the testing macros work.
I created instr_imm_tb.sv from the provided template and connected the Instruction Immediate module as the DUT. I started with a simple I-type ADDI test where the immediate value is 5. I am also learning how to use the provided CHECK_EQ and TB_FINISH macros to automatically check the module output.
I have not finished all of the test cases yet. I still need to test negative I-type immediates, shift immediates, and the S-type, B-type, U-type, and J-type formats. I plan to continue adding these tests and then run the complete testbench to make sure the module behaves correctly.
Week of 1 November 2026
Completing Instruction Immediate Verification
This week, I finished the Level 1 verification for the Instruction Immediate module. I continued working on instr_imm_tb.sv and added tests for the main immediate formats supported by the module.
The testbench now checks positive and negative I-type immediates, shift immediates, LOAD and JALR, S-type, B-type, U-type, and J-type immediates. I also added a test for an unsupported opcode to make sure the module outputs zero by default.
I compiled and ran the complete testbench using Verilator. All of the tests passed. I also fixed formatting issues in the testbench and removed generated files such as the waveform file and obj_dir before pushing my changes.
This verification work helped me better understand how the immediate values are reconstructed from an instruction and how a testbench can check each case automatically using expected outputs.
Week of 2 November 2026
Introduction to Microcontrollers
This week, I started learning about microcontrollers and how they are different from just a processor core. A microcontroller includes a CPU, memory, and different hardware peripherals that allow it to communicate with external devices.
I also learned about embedded systems. An embedded system is designed for a specific task, such as reading sensors, controlling motors, or operating a display. Microcontrollers are commonly used inside embedded systems because they can process data and also interact with hardware.
I learned that peripherals are hardware modules that help the CPU perform specific tasks. For example, GPIO is used for basic digital input and output. A button can be connected as a GPIO input, while an LED can be controlled using a GPIO output.
I also learned the basics of UART, I2C, and SPI. UART uses TX and RX lines for communication between two devices. I2C uses SDA and SCL and allows multiple devices to share the same bus using different addresses. SPI usually uses SCLK, MOSI, MISO, and CS, and the CS signal is used to select which device the microcontroller communicates with.
This helped me understand how the processor core we worked on can eventually become part of a complete microcontroller by adding memory and hardware peripherals for communicating with sensors and other devices.