diff --git a/.gitignore b/.gitignore index 8586c55..9014664 100644 --- a/.gitignore +++ b/.gitignore @@ -5,4 +5,10 @@ test/logs/* gds/**/*.gltf .DS_Store -results.xml \ No newline at end of file +results.xml +docs/*.md + +sv2v-Windows/ +sv2v-Windows.zip +*.ps1 +*_out.txt \ No newline at end of file diff --git a/README.md b/README.md index c20afc4..1628105 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,14 @@ -# tiny-gpu +# Mini GPU Architecture -A minimal GPU implementation in Verilog optimized for learning about how GPUs work from the ground up. +A minimal GPU implementation in SystemVerilog designed for educational exploration of hardware-level parallelism and GPGPU architectures. -Built with <15 files of fully documented Verilog, complete documentation on architecture & ISA, working matrix addition/multiplication kernels, and full support for kernel simulation & execution traces. +[![SystemVerilog](https://img.shields.io/badge/SystemVerilog-007ACC?logo=verilog&logoColor=white)](https://en.wikipedia.org/wiki/SystemVerilog) +[![Python](https://img.shields.io/badge/Python-3776AB?logo=python&logoColor=white)](https://www.python.org/) +[![Cocotb](https://img.shields.io/badge/Cocotb-333333?logo=python&logoColor=white)](https://www.cocotb.org/) +[![Icarus Verilog](https://img.shields.io/badge/Icarus_Verilog-005A9C?logo=linux&logoColor=white)](http://iverilog.icarus.com/) +[![sv2v](https://img.shields.io/badge/sv2v-444444?logo=github&logoColor=white)](https://github.com/zachjs/sv2v) + +This repository contains a documented SystemVerilog implementation of a GPU, featuring an ISA, architecture specifications, and matrix operation kernels supported by a simulation framework. ### Table of Contents @@ -24,35 +30,27 @@ Built with <15 files of fully documented Verilog, complete documentation on arch # Overview -If you want to learn how a CPU works all the way from architecture to control signals, there are many resources online to help you. - -GPUs are not the same. - -Because the GPU market is so competitive, low-level technical details for all modern architectures remain proprietary. - -While there are lots of resources to learn about GPU programming, there's almost nothing available to learn about how GPU's work at a hardware level. +Understanding the internal architecture of modern Graphics Processing Units (GPUs) is often hindered by the proprietary nature of commercial hardware. While high-level GPU programming resources are abundant, low-level hardware implementation details are scarce. -The best option is to go through open-source GPU implementations like [Miaow](https://github.com/VerticalResearchGroup/miaow) and [VeriGPU](https://github.com/hughperkins/VeriGPU/tree/main) and try to figure out what's going on. This is challenging since these projects aim at being feature complete and functional, so they're quite complex. +`mini-gpu` provides a minimal, documented GPU implementation designed to bridge this gap, focusing on architectural fundamentals rather than production complexity. -This is why I built `tiny-gpu`! - -## What is tiny-gpu? +## Project Scope > [!IMPORTANT] > -> **tiny-gpu** is a minimal GPU implementation optimized for learning about how GPUs work from the ground up. +> **mini-gpu** is a minimal GPU implementation optimized for learning about how GPUs work from the ground up. > -> Specifically, with the trend toward general-purpose GPUs (GPGPUs) and ML-accelerators like Google's TPU, tiny-gpu focuses on highlighting the general principles of all of these architectures, rather than on the details of graphics-specific hardware. +> Specifically, with the trend toward general-purpose GPUs (GPGPUs) and ML-accelerators like Google's TPU, mini-gpu focuses on highlighting the general principles of all of these architectures, rather than on the details of graphics-specific hardware. With this motivation in mind, we can simplify GPUs by cutting out the majority of complexity involved with building a production-grade graphics card, and focus on the core elements that are critical to all of these modern hardware accelerators. This project is primarily focused on exploring: -1. **Architecture** - What does the architecture of a GPU look like? What are the most important elements? -2. **Parallelization** - How is the SIMD progamming model implemented in hardware? -3. **Memory** - How does a GPU work around the constraints of limited memory bandwidth? +1. **Hardware Architecture**: Decomposition of GPU units, including dispatchers, compute cores, and memory controllers. +2. **Parallel Execution Models**: Hardware implementation of the Single Instruction, Multiple Data (SIMD) paradigm. +3. **Memory Hierarchy**: Managing memory bandwidth constraints through caching and controlled memory access. -After understanding the fundamentals laid out in this project, you can checkout the [advanced functionality section](#advanced-functionality) to understand some of the most important optimizations made in production grade GPUs (that are more challenging to implement) which improve performance. +Detailed discussions on advanced optimizations used in production-grade GPUs are available in the [Advanced Functionality](#advanced-functionality) section. # Architecture @@ -63,7 +61,7 @@ After understanding the fundamentals laid out in this project, you can checkout ## GPU -tiny-gpu is built to execute a single kernel at a time. +mini-gpu is built to execute a single kernel at a time. In order to launch a kernel, we need to do the following: @@ -100,12 +98,12 @@ The GPU is built to interface with an external global memory. Here, data memory ### Global Memory -tiny-gpu data memory has the following specifications: +mini-gpu data memory has the following specifications: - 8 bit addressability (256 total rows of data memory) - 8 bit data (stores values of <256 for each row) -tiny-gpu program memory has the following specifications: +mini-gpu program memory has the following specifications: - 8 bit addressability (256 rows of program memory) - 16 bit data (each instruction is 16 bits as specified by the ISA) @@ -134,7 +132,7 @@ In this simplified GPU, each core processed one **block** at a time, and for eac Each core has a single scheduler that manages the execution of threads. -The tiny-gpu scheduler executes instructions for a single block to completion before picking up a new block, and it executes instructions for all threads in-sync and sequentially. +The mini-gpu scheduler executes instructions for a single block to completion before picking up a new block, and it executes instructions for all threads in-sync and sequentially. In more advanced schedulers, techniques like **pipelining** are used to stream the execution of multiple instructions subsequent instructions to maximize resource utilization before previous instructions are fully complete. Additionally, **warp scheduling** can be use to execute multiple batches of threads within a block in parallel. @@ -174,7 +172,7 @@ By default, the PC increments by 1 after every instruction. With the `BRnzp` instruction, the NZP register checks to see if the NZP register (set by a previous `CMP` instruction) matches some case - and if it does, it will branch to a specific line of program memory. _This is how loops and conditionals are implemented._ -Since threads are processed in parallel, tiny-gpu assumes that all threads "converge" to the same program counter after each instruction - which is a naive assumption for the sake of simplicity. +Since threads are processed in parallel, mini-gpu assumes that all threads "converge" to the same program counter after each instruction - which is a naive assumption for the sake of simplicity. In real GPUs, individual threads can branch to different PCs, causing **branch divergence** where a group of threads threads initially being processed together has to split out into separate execution. @@ -182,7 +180,7 @@ In real GPUs, individual threads can branch to different PCs, causing **branch d ![ISA](/docs/images/isa.png) -tiny-gpu implements a simple 11 instruction ISA built to enable simple kernels for proof-of-concept like matrix addition & matrix multiplication (implementation further down on this page). +mini-gpu implements a simple 11 instruction ISA built to enable simple kernels for proof-of-concept like matrix addition & matrix multiplication (implementation further down on this page). For these purposes, it supports the following instructions: @@ -261,7 +259,7 @@ RET ; end of kernel ### Matrix Multiplication -The matrix multiplication kernel multiplies two 2x2 matrices. It performs element wise calculation of the dot product of the relevant row and column and uses the `CMP` and `BRnzp` instructions to demonstrate branching within the threads (notably, all branches converge so this kernel works on the current tiny-gpu implementation). +The matrix multiplication kernel multiplies two 2x2 matrices. It performs element wise calculation of the dot product of the relevant row and column and uses the `CMP` and `BRnzp` instructions to demonstrate branching within the threads (notably, all branches converge so this kernel works on the current mini-gpu implementation). `matmul.asm` @@ -311,33 +309,54 @@ STR R9, R8 ; store C[i] in global memory RET ; end of kernel ``` -# Simulation +# Simulation and Verification -tiny-gpu is setup to simulate the execution of both of the above kernels. Before simulating, you'll need to install [iverilog](https://steveicarus.github.io/iverilog/usage/installation.html) and [cocotb](https://docs.cocotb.org/en/stable/install.html): +`mini-gpu` includes a comprehensive simulation environment for verifying kernel execution. -- Install Verilog compilers with `brew install icarus-verilog` and `pip3 install cocotb` -- Download the latest version of sv2v from https://github.com/zachjs/sv2v/releases, unzip it and put the binary in $PATH. -- Run `mkdir build` in the root directory of this repository. +## Prerequisites -Once you've installed the pre-requisites, you can run the kernel simulations with `make test_matadd` and `make test_matmul`. +The following tools are required for simulation: -Executing the simulations will output a log file in `test/logs` with the initial data memory state, complete execution trace of the kernel, and final data memory state. +- **Icarus Verilog**: Hardware simulation and synthesis tool. +- **Python 3.x**: Required for the `cocotb` verification framework. +- **cocotb**: Coroutine-based cosimulation framework. +- **sv2v**: SystemVerilog to Verilog conversion tool. -If you look at the initial data memory state logged at the start of the logfile for each, you should see the two start matrices for the calculation, and in the final data memory at the end of the file you should also see the resultant matrix. +### Installation -Below is a sample of the execution traces, showing on each cycle the execution of every thread within every core, including the current instruction, PC, register values, states, etc. +1. Install the Verilog compiler and cocotb: + - macOS: `brew install icarus-verilog` + - Python: `pip install cocotb` +2. Download the `sv2v` binary from the [official releases](https://github.com/zachjs/sv2v/releases) and ensure it is in your system `PATH`. +3. Create a build directory in the root: `mkdir build`. -![execution trace](docs/images/trace.png) +## Running Simulations + +Execute the pre-defined kernel simulations using the provided Makefile: + +```bash +make test_matadd +make test_matmul +``` + +Simulations generate comprehensive log files in `test/logs`, including: +- Initial and final data memory states. +- Cycle-accurate execution traces. +- Register and PC status for every thread and core. + +### Execution Trace Analysis + +The generated traces provide visibility into the execution of every thread, facilitating detailed analysis of the pipeline and memory operations. -**For anyone trying to run the simulation or play with this repo, please feel free to DM me on [twitter](https://twitter.com/majmudaradam) if you run into any issues - I want you to get this running!** +![execution trace](docs/images/trace.png) # Advanced Functionality -For the sake of simplicity, there were many additional features implemented in modern GPUs that heavily improve performance & functionality that tiny-gpu omits. We'll discuss some of those most critical features in this section. +For the sake of simplicity, there were many additional features implemented in modern GPUs that heavily improve performance & functionality that mini-gpu omits. We'll discuss some of those most critical features in this section. ### Multi-layered Cache & Shared Memory -In modern GPUs, multiple different levels of caches are used to minimize the amount of data that needs to get accessed from global memory. tiny-gpu implements only one cache layer between individual compute units requesting memory and the memory controllers which stores recent cached data. +In modern GPUs, multiple different levels of caches are used to minimize the amount of data that needs to get accessed from global memory. mini-gpu implements only one cache layer between individual compute units requesting memory and the memory controllers which stores recent cached data. Implementing multi-layered caches allows frequently accessed data to be cached more locally to where it's being used (with some caches within individual compute cores), minimizing load times for this data. @@ -353,7 +372,7 @@ Memory coalescing is used to analyzing queued memory requests and combine neighb ### Pipelining -In the control flow for tiny-gpu, cores wait for one instruction to be executed on a group of threads before starting execution of the next instruction. +In the control flow for mini-gpu, cores wait for one instruction to be executed on a group of threads before starting execution of the next instruction. Modern GPUs use **pipelining** to stream execution of multiple sequential instructions at once while ensuring that instructions with dependencies on each other still get executed sequentially. @@ -367,7 +386,7 @@ Multiple warps can be executed on a single core simultaneously by executing inst ### Branch Divergence -tiny-gpu assumes that all threads in a single batch end up on the same PC after each instruction, meaning that threads can be executed in parallel for their entire lifetime. +mini-gpu assumes that all threads in a single batch end up on the same PC after each instruction, meaning that threads can be executed in parallel for their entire lifetime. In reality, individual threads could diverge from each other and branch to different lines based on their data. With different PCs, these threads would need to split into separate lines of execution, which requires managing diverging threads & paying attention to when threads converge again. @@ -377,16 +396,22 @@ Another core functionality of modern GPUs is the ability to set **barriers** so This is useful for cases where threads need to exchange shared data with each other so they can ensure that the data has been fully processed. -# Next Steps +# Roadmap and Future Work + +Current development objectives include: + +- [ ] Instruction cache implementation. +- [ ] Integration with Tiny Tapeout 7. +- [ ] Support for branch divergence management. +- [ ] Implementation of memory coalescing. +- [ ] Pipeline optimization. +- [ ] Control flow and register allocation enhancements. +- [ ] Graphics-specific hardware modules and kernels. + +## Contributions -Updates I want to make in the future to improve the design, anyone else is welcome to contribute as well: +Contributions aimed at improving the architectural fidelity or performance of `mini-gpu` are welcome. Please submit a Pull Request or open an issue to discuss proposed changes. -- [ ] Add a simple cache for instructions -- [ ] Build an adapter to use GPU with Tiny Tapeout 7 -- [ ] Add basic branch divergence -- [ ] Add basic memory coalescing -- [ ] Add basic pipelining -- [ ] Optimize control flow and use of registers to improve cycle time -- [ ] Write a basic graphics kernel or add simple graphics hardware to demonstrate graphics functionality +--- -**For anyone curious to play around or make a contribution, feel free to put up a PR with any improvements you'd like to add 😄** +**Author:** [Rickarya Das](https://github.com/ridash2005) diff --git a/src/controller.sv b/src/controller.sv index eeedef2..158e316 100644 --- a/src/controller.sv +++ b/src/controller.sv @@ -64,14 +64,18 @@ module controller #( channel_serving_consumer = 0; end else begin + // Local variable to handle arbitration updates within the same cycle + reg [NUM_CONSUMERS-1:0] next_channel_serving_consumer; + next_channel_serving_consumer = channel_serving_consumer; + // For each channel, we handle processing concurrently for (int i = 0; i < NUM_CHANNELS; i = i + 1) begin case (controller_state[i]) IDLE: begin // While this channel is idle, cycle through consumers looking for one with a pending request for (int j = 0; j < NUM_CONSUMERS; j = j + 1) begin - if (consumer_read_valid[j] && !channel_serving_consumer[j]) begin - channel_serving_consumer[j] = 1; + if (consumer_read_valid[j] && !next_channel_serving_consumer[j]) begin + next_channel_serving_consumer[j] = 1; current_consumer[i] <= j; mem_read_valid[i] <= 1; @@ -80,8 +84,8 @@ module controller #( // Once we find a pending request, pick it up with this channel and stop looking for requests break; - end else if (consumer_write_valid[j] && !channel_serving_consumer[j]) begin - channel_serving_consumer[j] = 1; + end else if (consumer_write_valid[j] && !next_channel_serving_consumer[j]) begin + next_channel_serving_consumer[j] = 1; current_consumer[i] <= j; mem_write_valid[i] <= 1; @@ -114,20 +118,23 @@ module controller #( // Wait until consumer acknowledges it received response, then reset READ_RELAYING: begin if (!consumer_read_valid[current_consumer[i]]) begin - channel_serving_consumer[current_consumer[i]] = 0; + next_channel_serving_consumer[current_consumer[i]] = 0; consumer_read_ready[current_consumer[i]] <= 0; controller_state[i] <= IDLE; end end WRITE_RELAYING: begin if (!consumer_write_valid[current_consumer[i]]) begin - channel_serving_consumer[current_consumer[i]] = 0; + next_channel_serving_consumer[current_consumer[i]] = 0; consumer_write_ready[current_consumer[i]] <= 0; controller_state[i] <= IDLE; end end endcase end + + // Update the state register + channel_serving_consumer <= next_channel_serving_consumer; end end endmodule diff --git a/src/core.sv b/src/core.sv index 80a0b00..ecdeb1c 100644 --- a/src/core.sv +++ b/src/core.sv @@ -24,52 +24,53 @@ module core #( input wire [$clog2(THREADS_PER_BLOCK):0] thread_count, // Program Memory - output reg program_mem_read_valid, - output reg [PROGRAM_MEM_ADDR_BITS-1:0] program_mem_read_address, + // Program Memory + output wire program_mem_read_valid, + output wire [PROGRAM_MEM_ADDR_BITS-1:0] program_mem_read_address, input reg program_mem_read_ready, input reg [PROGRAM_MEM_DATA_BITS-1:0] program_mem_read_data, // Data Memory - output reg [THREADS_PER_BLOCK-1:0] data_mem_read_valid, - output reg [DATA_MEM_ADDR_BITS-1:0] data_mem_read_address [THREADS_PER_BLOCK-1:0], + output wire [THREADS_PER_BLOCK-1:0] data_mem_read_valid, + output wire [DATA_MEM_ADDR_BITS-1:0] data_mem_read_address [THREADS_PER_BLOCK-1:0], input reg [THREADS_PER_BLOCK-1:0] data_mem_read_ready, input reg [DATA_MEM_DATA_BITS-1:0] data_mem_read_data [THREADS_PER_BLOCK-1:0], - output reg [THREADS_PER_BLOCK-1:0] data_mem_write_valid, - output reg [DATA_MEM_ADDR_BITS-1:0] data_mem_write_address [THREADS_PER_BLOCK-1:0], - output reg [DATA_MEM_DATA_BITS-1:0] data_mem_write_data [THREADS_PER_BLOCK-1:0], + output wire [THREADS_PER_BLOCK-1:0] data_mem_write_valid, + output wire [DATA_MEM_ADDR_BITS-1:0] data_mem_write_address [THREADS_PER_BLOCK-1:0], + output wire [DATA_MEM_DATA_BITS-1:0] data_mem_write_data [THREADS_PER_BLOCK-1:0], input reg [THREADS_PER_BLOCK-1:0] data_mem_write_ready ); // State - reg [2:0] core_state; - reg [2:0] fetcher_state; - reg [15:0] instruction; + wire [2:0] core_state; + wire [2:0] fetcher_state; + wire [15:0] instruction; // Intermediate Signals - reg [7:0] current_pc; + wire [7:0] current_pc; wire [7:0] next_pc[THREADS_PER_BLOCK-1:0]; - reg [7:0] rs[THREADS_PER_BLOCK-1:0]; - reg [7:0] rt[THREADS_PER_BLOCK-1:0]; - reg [1:0] lsu_state[THREADS_PER_BLOCK-1:0]; - reg [7:0] lsu_out[THREADS_PER_BLOCK-1:0]; + wire [7:0] rs[THREADS_PER_BLOCK-1:0]; + wire [7:0] rt[THREADS_PER_BLOCK-1:0]; + wire [1:0] lsu_state[THREADS_PER_BLOCK-1:0]; + wire [7:0] lsu_out[THREADS_PER_BLOCK-1:0]; wire [7:0] alu_out[THREADS_PER_BLOCK-1:0]; // Decoded Instruction Signals - reg [3:0] decoded_rd_address; - reg [3:0] decoded_rs_address; - reg [3:0] decoded_rt_address; - reg [2:0] decoded_nzp; - reg [7:0] decoded_immediate; + wire [3:0] decoded_rd_address; + wire [3:0] decoded_rs_address; + wire [3:0] decoded_rt_address; + wire [2:0] decoded_nzp; + wire [7:0] decoded_immediate; // Decoded Control Signals - reg decoded_reg_write_enable; // Enable writing to a register - reg decoded_mem_read_enable; // Enable reading from memory - reg decoded_mem_write_enable; // Enable writing to memory - reg decoded_nzp_write_enable; // Enable writing to NZP register - reg [1:0] decoded_reg_input_mux; // Select input to register - reg [1:0] decoded_alu_arithmetic_mux; // Select arithmetic operation - reg decoded_alu_output_mux; // Select operation in ALU - reg decoded_pc_mux; // Select source of next PC - reg decoded_ret; + wire decoded_reg_write_enable; // Enable writing to a register + wire decoded_mem_read_enable; // Enable reading from memory + wire decoded_mem_write_enable; // Enable writing to memory + wire decoded_nzp_write_enable; // Enable writing to NZP register + wire [1:0] decoded_reg_input_mux; // Select input to register + wire [1:0] decoded_alu_arithmetic_mux; // Select arithmetic operation + wire decoded_alu_output_mux; // Select operation in ALU + wire decoded_pc_mux; // Select source of next PC + wire decoded_ret; // Fetcher fetcher #( diff --git a/src/dcr.sv b/src/dcr.sv index 97c0b41..8561698 100644 --- a/src/dcr.sv +++ b/src/dcr.sv @@ -10,18 +10,18 @@ module dcr ( input wire device_control_write_enable, input wire [7:0] device_control_data, - output wire [7:0] thread_count, + output wire [7:0] thread_count ); // Store device control data in dedicated register - reg [7:0] device_conrol_register; - assign thread_count = device_conrol_register[7:0]; + reg [7:0] device_control_register; + assign thread_count = device_control_register[7:0]; always @(posedge clk) begin if (reset) begin - device_conrol_register <= 8'b0; + device_control_register <= 8'b0; end else begin if (device_control_write_enable) begin - device_conrol_register <= device_control_data; + device_control_register <= device_control_data; end end end diff --git a/src/dispatch.sv b/src/dispatch.sv index f1d5d55..0c7f9d2 100644 --- a/src/dispatch.sv +++ b/src/dispatch.sv @@ -38,8 +38,8 @@ module dispatch #( always @(posedge clk) begin if (reset) begin done <= 0; - blocks_dispatched = 0; - blocks_done = 0; + blocks_dispatched <= 0; + blocks_done <= 0; start_execution <= 0; for (int i = 0; i < NUM_CORES; i++) begin @@ -50,6 +50,7 @@ module dispatch #( end end else if (start) begin // EDA: Indirect way to get @(posedge start) without driving from 2 different clocks + reg [7:0] next_blocks_dispatched; if (!start_execution) begin start_execution <= 1; for (int i = 0; i < NUM_CORES; i++) begin @@ -62,29 +63,32 @@ module dispatch #( done <= 1; end + next_blocks_dispatched = blocks_dispatched; + for (int i = 0; i < NUM_CORES; i++) begin if (core_reset[i]) begin core_reset[i] <= 0; // If this core was just reset, check if there are more blocks to be dispatched - if (blocks_dispatched < total_blocks) begin + if (next_blocks_dispatched < total_blocks) begin core_start[i] <= 1; - core_block_id[i] <= blocks_dispatched; - core_thread_count[i] <= (blocks_dispatched == total_blocks - 1) - ? thread_count - (blocks_dispatched * THREADS_PER_BLOCK) + core_block_id[i] <= next_blocks_dispatched; + core_thread_count[i] <= (next_blocks_dispatched == total_blocks - 1) + ? thread_count - (next_blocks_dispatched * THREADS_PER_BLOCK) : THREADS_PER_BLOCK; - blocks_dispatched = blocks_dispatched + 1; + next_blocks_dispatched = next_blocks_dispatched + 1; end end end + blocks_dispatched <= next_blocks_dispatched; for (int i = 0; i < NUM_CORES; i++) begin if (core_start[i] && core_done[i]) begin // If a core just finished executing it's current block, reset it core_reset[i] <= 1; core_start[i] <= 0; - blocks_done = blocks_done + 1; + blocks_done <= blocks_done + 1; end end end diff --git a/src/fetcher.sv b/src/fetcher.sv index 53ef2de..69a98a8 100644 --- a/src/fetcher.sv +++ b/src/fetcher.sv @@ -23,7 +23,7 @@ module fetcher #( // Fetcher Output output reg [2:0] fetcher_state, - output reg [PROGRAM_MEM_DATA_BITS-1:0] instruction, + output reg [PROGRAM_MEM_DATA_BITS-1:0] instruction ); localparam IDLE = 3'b000, FETCHING = 3'b001, diff --git a/src/gpu.sv b/src/gpu.sv index e3d8fcd..4d137e3 100644 --- a/src/gpu.sv +++ b/src/gpu.sv @@ -130,7 +130,7 @@ module gpu #( .mem_read_valid(program_mem_read_valid), .mem_read_address(program_mem_read_address), .mem_read_ready(program_mem_read_ready), - .mem_read_data(program_mem_read_data), + .mem_read_data(program_mem_read_data) ); // Dispatcher @@ -156,13 +156,13 @@ module gpu #( for (i = 0; i < NUM_CORES; i = i + 1) begin : cores // EDA: We create separate signals here to pass to cores because of a requirement // by the OpenLane EDA flow (uses Verilog 2005) that prevents slicing the top-level signals - reg [THREADS_PER_BLOCK-1:0] core_lsu_read_valid; - reg [DATA_MEM_ADDR_BITS-1:0] core_lsu_read_address [THREADS_PER_BLOCK-1:0]; + wire [THREADS_PER_BLOCK-1:0] core_lsu_read_valid; + wire [DATA_MEM_ADDR_BITS-1:0] core_lsu_read_address [THREADS_PER_BLOCK-1:0]; reg [THREADS_PER_BLOCK-1:0] core_lsu_read_ready; reg [DATA_MEM_DATA_BITS-1:0] core_lsu_read_data [THREADS_PER_BLOCK-1:0]; - reg [THREADS_PER_BLOCK-1:0] core_lsu_write_valid; - reg [DATA_MEM_ADDR_BITS-1:0] core_lsu_write_address [THREADS_PER_BLOCK-1:0]; - reg [DATA_MEM_DATA_BITS-1:0] core_lsu_write_data [THREADS_PER_BLOCK-1:0]; + wire [THREADS_PER_BLOCK-1:0] core_lsu_write_valid; + wire [DATA_MEM_ADDR_BITS-1:0] core_lsu_write_address [THREADS_PER_BLOCK-1:0]; + wire [DATA_MEM_DATA_BITS-1:0] core_lsu_write_data [THREADS_PER_BLOCK-1:0]; reg [THREADS_PER_BLOCK-1:0] core_lsu_write_ready; // Pass through signals between LSUs and data memory controller @@ -189,7 +189,7 @@ module gpu #( .DATA_MEM_DATA_BITS(DATA_MEM_DATA_BITS), .PROGRAM_MEM_ADDR_BITS(PROGRAM_MEM_ADDR_BITS), .PROGRAM_MEM_DATA_BITS(PROGRAM_MEM_DATA_BITS), - .THREADS_PER_BLOCK(THREADS_PER_BLOCK), + .THREADS_PER_BLOCK(THREADS_PER_BLOCK) ) core_instance ( .clk(clk), .reset(core_reset[i]), diff --git a/src/scheduler.sv b/src/scheduler.sv index 6838f91..6dc69d6 100644 --- a/src/scheduler.sv +++ b/src/scheduler.sv @@ -14,7 +14,7 @@ // > Technically, different instructions can branch to different PCs, requiring "branch divergence." In // this minimal implementation, we assume no branch divergence (naive approach for simplicity) module scheduler #( - parameter THREADS_PER_BLOCK = 4, + parameter THREADS_PER_BLOCK = 4 ) ( input wire clk, input wire reset, @@ -76,7 +76,9 @@ module scheduler #( end WAIT: begin // Wait for all LSUs to finish their request before continuing - reg any_lsu_waiting = 1'b0; + logic any_lsu_waiting; + any_lsu_waiting = 1'b0; + for (int i = 0; i < THREADS_PER_BLOCK; i++) begin // Make sure no lsu_state = REQUESTING or WAITING if (lsu_state[i] == 2'b01 || lsu_state[i] == 2'b10) begin @@ -101,7 +103,8 @@ module scheduler #( core_state <= DONE; end else begin // TODO: Branch divergence. For now assume all next_pc converge - current_pc <= next_pc[THREADS_PER_BLOCK-1]; + // Use Thread 0's PC since it is guaranteed to be active if the block is active + current_pc <= next_pc[0]; // Update is synchronous so we move on after one cycle core_state <= FETCH; diff --git a/test/helpers/format.py b/test/helpers/format.py index 109130b..5c591c6 100644 --- a/test/helpers/format.py +++ b/test/helpers/format.py @@ -99,7 +99,7 @@ def format_cycle(dut, cycle_id: int, thread_id: Optional[int] = None): for core in dut.cores: # Not exactly accurate, but good enough for now - if int(str(dut.thread_count.value), 2) <= core.i.value * dut.THREADS_PER_BLOCK.value: + if int(dut.thread_count.value) <= int(core.i.value) * int(dut.THREADS_PER_BLOCK.value): continue logger.debug(f"\n+--------------------- Core {core.i.value} ---------------------+") @@ -107,9 +107,9 @@ def format_cycle(dut, cycle_id: int, thread_id: Optional[int] = None): instruction = str(core.core_instance.instruction.value) for thread in core.core_instance.threads: if int(thread.i.value) < int(str(core.core_instance.thread_count.value), 2): # if enabled - block_idx = core.core_instance.block_id.value - block_dim = int(core.core_instance.THREADS_PER_BLOCK) - thread_idx = thread.register_instance.THREAD_ID.value + block_idx = int(core.core_instance.block_id.value) + block_dim = int(core.core_instance.THREADS_PER_BLOCK.value) + thread_idx = int(thread.register_instance.THREAD_ID.value) idx = block_idx * block_dim + thread_idx rs = int(str(thread.register_instance.rs.value), 2) diff --git a/test/helpers/setup.py b/test/helpers/setup.py index 5370eb2..4dbc023 100644 --- a/test/helpers/setup.py +++ b/test/helpers/setup.py @@ -13,7 +13,7 @@ async def setup( threads: int ): # Setup Clock - clock = Clock(dut.clk, 25, units="us") + clock = Clock(dut.clk, 25, unit="us") cocotb.start_soon(clock.start()) # Reset