docs(dn): Lucy Zheng 11/16/2025 (#433)

* docs(dn): Lucy Zheng 11/16/2025

* docs(dn): Lucy Zheng 11/16/2025

---------

Co-authored-by: Lucy Zheng <[email protected]>

Author: Tyjihn

src/design_notebooks/2025fall/lz3007.md

@@ -21,7 +21,7 @@ We read the documentations on the [instruction set](https://user.eng.umd.edu/~bl
 1. One idea was that the 16-bit instruction set in machine code is passed into the module, but that idea was discarded because there was no way of obtaining the addresses of the registers and immediate value through the machine code. 
 2. Another idea was that the opcode, registers, and immediate values are passed into the module as inputs and we would use the opcode to decide on what the output address would be. But, we were unsure on how the incrementation of the PC would work and how the address would be chosen, given two 3-bit registers (A and B).
 
-We consulted Noah about the inputs and outputs of the PC. From my interpretation, he explained that there are 3 possible jumps for the output address: incrementing of 1, jumping to register B (JALR instruction), and jumping to the immediate value (BEQ instruction). For all 3 possible jumps, there should be an input with the 16-bit address. A multiplexer, given an input from another module, is used to choose which address would be the one the PC would actually point to.
+We consulted Noah about the inputs and outputs of the PC. From my interpretation, he explained that there are 3 possible jumps for the output address: incrementing of 1, jumping to register B (```JALR``` instruction), and jumping to the immediate value (```BEQ``` instruction). For all 3 possible jumps, there should be an input with the 16-bit address. A multiplexer, given an input from another module, is used to choose which address would be the one the PC would actually point to.
 
 My partner and I had some differences in our interpretations, so we decided to write our code in separate files and push both versions to the repository ([My PC](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/pc2.v) and [My Partner's PC](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/program_counter.v)).
 
@@ -32,18 +32,18 @@ My partner and I had some differences in our interpretations, so we decided to w
 * Fixed PC to pass all testbench tests
 * Completed ALU and passed the testbench tests
 
-The [sequential implementation document](https://user.eng.umd.edu/~blj/risc/RiSC-seq.pdf) was reviewed to understand how the inputs (given in the slides) were manipulated to be passed into the multiplexers. Since there are four possible operations to choose from—add, bitwise nand, passing src1, and setting EQ if equal—the input FUNC_alu is 2-bits. 
+The [sequential implementation document](https://user.eng.umd.edu/~blj/risc/RiSC-seq.pdf) was reviewed to understand how the inputs (given in the slides) were manipulated to be passed into the multiplexers. Since there are four possible operations to choose from—```add```, bitwise ```nand```, passing ```src1```, and setting ```EQ``` if equal—the input ```FUNC_alu``` is 2-bits. 
 
-The multiplexers inputs are 1-bit signals that choose whether the left-shifted immediate value or the source1 input [MUX_alu1] and the whether the sign-extended immediate value or the source2 input [MUX_alu2] are used as the source inputs for the internal multiplexer of the ALU that operates on the two inputs.
+The multiplexers inputs are 1-bit signals that choose whether the left-shifted immediate value or the source1 input ```MUX_alu1``` and the whether the sign-extended immediate value or the source2 input ```MUX_alu2``` are used as the source inputs for the internal multiplexer of the ALU that operates on the two inputs.
 
 The outputs, EQ (1-bit) and alu_out (16-bit), are selected based on the following operations:
-- **default:** alu_out = 16'b0, EQ = 1'b0
-- **add:** alu_out = src1 + src2
-- **bitwise nand:** alu_out = ~(src1 & src2)
-- **passing src1 unchanged:** alu_out = src1
-- **setting EQ:** alu_out = 16'b0
+- **default:** ```alu_out = 16'b0```, ```EQ = 1'b0```
+- **add:** ```alu_out = src1 + src2```
+- **bitwise nand:** ```alu_out = ~(src1 & src2)```
+- **passing src1 unchanged:** ```alu_out = src1```
+- **setting EQ:** ```alu_out = 16'b0```
 
-EQ is always being set to (src1 == src2) for every operation.
+```EQ``` is always being set to ```src1 == src2``` for every operation.
 
 For this week's project, my partner and I worked separately, meeting once to check each other's progress. Therefore, we worked on separate alu files: [My ALU](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/alu2.v) and [My Partner's ALU](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/alu.v).
 
@@ -55,32 +55,32 @@ When working on the ALU, I had the following questions: When do you decide to ma
 * Completed the Register File
 * Fixed Register File to pass all test cases in the testbench
 
-The [Instruction Set Architecture](https://user.eng.umd.edu/~blj/risc/RiSC-isa.pdf) was reviewed. The 16-bit instruction input was separated into different variables: opCode, rA, rB, rC, signed_imm, and imm. An array of eight 16-bit registers was created. 
+The [Instruction Set Architecture](https://user.eng.umd.edu/~blj/risc/RiSC-isa.pdf) was reviewed. The 16-bit instruction input was separated into different variables: ```opCode```, ```rA```, ```rB```, ```rC```, ```signed_imm```, and ```imm```. An array of eight 16-bit registers was created. 
 
-At first, I thought the opcode would be used to assign the results (rB + rC, rB nand rC, etc) to rA. But, I realized that the calculations are done in the ALU, so the register value should be updated with the values inputted to the register file (alu_out, mem_out, pc). 
+At first, I thought the opcode would be used to assign the results (```rB + rC```, ```rB nand rC```, etc) to ```rA```. But, I realized that the calculations are done in the ALU, so the register value should be updated with the values inputted to the register file (```alu_out```, ```mem_out```, ```pc```). 
 
-Looking at the diagram in the Instruction Set Architecture, I think the MUX_tgt is used to determine what value the destination register is updated with, if the WE bit is turned on. The outputs for the register file are determined on the opcode of the inputted instruction.
+Looking at the diagram in the Instruction Set Architecture, I think the ```MUX_tgt``` is used to determine what value the destination register is updated with, if the ```WE``` bit is turned on. The outputs for the register file are determined on the opcode of the inputted instruction.
 
 ### Testing code with Testbench
 There were many syntax and logic errors while testing my code with the testbench. Below are the things I realized and fixed.
-* MUX_rf: used to determine if reg_out2 is rA or rC
+* MUX_rf: used to determine if ```reg_out2``` is ```rA``` or ```rC```
 * The default case is to output 16'b0 for both outputs
-* Need to extend the signed_imm and the 10-bit imm for reg_out2
+* Need to extend the signed_imm and the 10-bit imm for ```reg_out2```
 * The register file only updates if:
-    1) WE_rf bit is on
+    1) ```WE_rf``` bit is on
     2) source register is not register 0
 
 [GitHub: Register File Code](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/register_file2.v)
 
-**Notes:** As I am writing this week's design notebook, I realize that it doesn't make sense to update the register using the value of the current instruction's rA. So, I am unsure as to why my current code (which does the above) passes all the test cases.
+**Notes:** As I am writing this week's design notebook, I realize that it doesn't make sense to update the register using the value of the current instruction's ```rA```. So, I am unsure as to why my current code (which does the above) passes all the test cases.
 
 ## Week 5: 10/06/2025 - 10/12/2025
 
 * Fixed register file using the updated testbench, passed all tests
 
 #### There was no new assignment for this week. 
 
-The previous testbench was incorrect because the Register File should not take the instruction, only the registers (rA, rB, rC). While fixing my Register File code using the fixed testbench, I realized the following about my code:
+The previous testbench was incorrect because the Register File should not take the instruction, only the registers (```rA```, ```rB```, ```rC```). While fixing my Register File code using the fixed testbench, I realized the following about my code:
 1. The Register File should NOT sign-extend or left shift the immediate value; in fact, the register does not take the immediate value as an input at all.
 2. The opcode should not be an input for any of the modules, only the signals from the Control Unit and the outputs from other modules are inputs.
 
@@ -90,7 +90,7 @@ The previous testbench was incorrect because the Register File should not take t
 
 * Completed testbench for the Data Memory module
 
-At the start, I created different test cases, like the verfication of the initial values in the memory, testing if the reg_out value was written to the address (alu_out) if WE_dmem = 0 (should not write), and overwriting previously modified memory data. One problem I had was that I was checking all 65536 memory locations, which is very inefficient. So, I changed the tests cases to only check the few memory addresses that were being tested. 
+At the start, I created different test cases, like the verfication of the initial values in the memory, testing if the ```reg_out``` value was written to the address ```alu_out``` if ```WE_dmem = 0``` (should not write), and overwriting previously modified memory data. One problem I had was that I was checking all 65536 memory locations, which is very inefficient. So, I changed the tests cases to only check the few memory addresses that were being tested. 
 
 The biggest problem that I encountered while writing the testbench was the verilog syntax and logic. Within an initial block, declaring an integer after an executable statements would cause errors and displaying text right after one another would also cause errors. However, all these errors would point to the $finish line at the very end of the code, so it was difficult to know which lines were actually causing errors.
 
@@ -103,7 +103,7 @@ The biggest problem that I encountered while writing the testbench was the veril
 * Completed Control and Data Memory modules
 * Passed all testcases for the Control module, using the provided testbench
 
-The Control module selects the value of the output signals: WErf, WEdmem, MUXalu1, MUXalu2, MUXrf, MUXtgt, FUNCalu, and MUXpc, based on the opcode input and the EQ signal (only for MUXpc). The first step was to find the corrosponding opcodes to the instructions using the [instruction set](https://user.eng.umd.edu/~blj/risc/RiSC-isa.pdf). The output signals were found by looking at the "Instruction Dataflow" diagrams for each instruction found in the [sequential implementation document](https://user.eng.umd.edu/~blj/risc/RiSC-seq.pdf). Another useful part of the document was the "Putting it all together" section that shows which modules the signals are sent to and describes what the signals are used for in the modules.
+The Control module selects the value of the output signals: ```WErf```, ```WEdmem```, ```MUXalu1```, ```MUXalu2```, ```MUXrf```, ```MUXtgt```, ```FUNCalu```, and ```MUXpc```, based on the opcode input and the ```EQ``` signal (only for ```MUXpc```). The first step was to find the corrosponding opcodes to the instructions using the [instruction set](https://user.eng.umd.edu/~blj/risc/RiSC-isa.pdf). The output signals were found by looking at the "Instruction Dataflow" diagrams for each instruction found in the [sequential implementation document](https://user.eng.umd.edu/~blj/risc/RiSC-seq.pdf). Another useful part of the document was the "Putting it all together" section that shows which modules the signals are sent to and describes what the signals are used for in the modules.
 
 [GitHub: Control Module Code](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/control2.v)
 
@@ -116,6 +116,26 @@ The Control module selects the value of the output signals: WErf, WEdmem, MUXalu
 
 No tasks were assigned this week.
 
-## Week 9: 10/03/2025 - 10/09/2025
+## Week 9: 11/03/2025 - 11/09/2025
 
-Did not work on onboarding labs this week.
+Did not work on onboarding labs this week.
+
+## Week 10: 11/10/2025 - 11/16/2025
+* Completed Onboarding Labs 1 and 2
+
+### Onboarding Lab 1
+[GitHub: Onboarding Lab 1](https://github.com/Ghqlq/Processor-Design-Projects/tree/main/Lab1_Lucy)
+
+The coding was not a problem, but the commands and all the generated files were confusing. Running ```cmake``` generates a lot files that were unfamiliar.
+
+**Remaining Questions/Notes**
+* I am still confused when to use ```ninja``` or ```cmake```. What is the difference with how you use them?
+* What does the ```make hello.o``` and ```make hello.i``` do? What are those build files used for?
+
+### Onboarding Lab2
+
+[GitHub: Onboarding Lab 2](https://github.com/Ghqlq/Processor-Design-Projects/tree/main/Lab2_Lucy)
+
+I was a little confused with where to write my code and what files I should be looking at for the exercises. The coding was not very difficult.
+
+Another issue I had trouble with was pushing the forked repo's work to the repo that I share with my groupmate. When I pushed the folder for the first time, the folder was pushed as a Git submodule(?). I had to delete the Git metadata to push the folder normally ```rm onboarding-lab-2/.git```.