Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 48 additions & 1 deletion src/design_notebooks/2025fall/lz3007.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,4 +25,51 @@ We consulted Noah about the inputs and outputs of the PC. From my interpretation

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 ([Mine](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/program_counter_2.v) and [My Partner's](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/program_counter.v)).

**Remaining Questions/Notes:** We are unable to test our PC implementations, so we are not sure if either of them are correct. Since we are both taking Computer Architecture this semester, we are not yet sure how the ALU, PC, instruction memory, etc. work together.
**Remaining Questions/Notes:** We are unable to test our PC implementations, so we are not sure if either of them are correct. Since we are both taking Computer Architecture this semester, we are not yet sure how the ALU, PC, instruction memory, etc. work together.

## Week 3: 09/22/2025 - 09/29/2025

* 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 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

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: [Mine](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/alu2.v) and [My Partner's](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/alu.v).

**Remaining Question:** When fixing the PC, I was confused on why the reset input is negative and why the immediate value is inputted as 7-bit, not 16-bit.
When working on the ALU, I had the following questions: When do you decide to make an input/output a register? When do you use a clock and when do you not (depending on if it iterates?).

## Week 4: 09/30/2025 - 10/05/2025

* 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.

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.

### 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
* 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
* The register file only updates if:
1) WE_rf bit is on
2) source register is not register 0

[Link to the Code](https://github.com/Ghqlq/Processor-Design-Projects/blob/main/register2.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.