Merge branch 'develop'

docs/cache_subsystem.md

@@ -2,69 +2,26 @@
 
 The Vortex Cache Sub-system has the following main properties:
 
-- High-bandwidth with bank parallelism
-- Snoop protocol to flush data for CPU access
-- Generic design: Dcache, Icache, Shared Memory, L2 cache, L3 cache
+- High-bandwidth transfer with Multi-bank parallelism
+- Non-blocking pipelined architecture with local MSHR
+- Configurable design: Dcache, Icache, L2 cache, L3 cache
 
-### Cache Hierarchy 
+### Cache Microarchitecture 
 
-![Image of Cache Hierarchy](./assets/img/cache_hierarchy.png)
+![Image of Cache Hierarchy](./assets/img/cache_microarchitecture.png)
 
-- Cache can be configured to be any level in the hierarchy
-- Caches communicate via snooping
-- Cache flush from AFU is passed down the hierarchy​
+The Vortex cache is comprised of multiple parallel banks. It is comprised of the following modules:
+- **Bank request dispatch crossbar**: assign a bank to incoming requests and resolve collision using stalls.
+- **Bank response merge crossbar**: merge result from banks and forward to the core response.
+- **Memory request multiplexer**: arbitrate bank memory requests
+- **Memory response demultiplexer**: forward memory response to the corresponding bank.
+- **Flush Unit**: perform tag memory initialization.
 
-### VX_cache.v (Top Module)
+Incoming requests entering the cache are sent to a dispatch crossbar that select the corresponding bank for each request, resolving bank collisions with stalls. The result output of each bank is merge back into outgoing response port via merger crossbar. Each bank intergates a non-blocking pipeline with a local Miss Status Holding Register (MSHR) to reduce the miss rate. The bank pipeline consists of the following stages:
 
-VX.cache.v is the top module of the cache verilog code located in the `/hw/rtl/cache` directory.
+- **Schedule**: Selects the next request into the pipeline from the incoming core request, memory fill, or the MSHR entry, with priority given to the latter.
+- **Tag Access**: A single-port read/write access to the tag store.
+- **Data Access**: Single-port read/write access to the data store.
+- **Response Handling**: Core response back to the core.
 
-![Image of Vortex Cache](./assets/img/vortex_cache_top_module.png)
-
-- Configurable (Cache size, number of banks, bank line size, etc.)
-- I/O signals
-  - Core Request
-  - Core Rsp
-  - DRAM Req
-  - DRAM Rsp
-  - Snoop Rsp
-  - Snoop Rsp
-  - Snoop Forwarding Out
-  - Snoop Forwarding In
-- Bank Select
-  - Assigns valid and ready signals for each bank
-- Snoop Forwarder
-- DRAM Request Arbiter
-  - Prepares cache response for communication with DRAM
-- Snoop Response Arbiter
-  - Sends snoop response
-- Core Response Merge
-  - Cache accesses one line at a time. As a result, each request may not come back in the same response. This module tries to recombine the responses by thread ID. 
-
-### VX_cache_bank.v
-
-VX_cache_bank.v is the verilog code that handles cache bank functionality and is located in the `/hw/rtl/cache` directory.
-
-![Image of Vortex Cache Bank](./assets/img/vortex_bank.png)
-
-- Allows for high throughput​
-- Each bank contains queues to hold requests to the cache​
-- I/O signals
-  - Core request​
-  - Core Response​
-  - DRAM Fill Requests​
-  - DRAM Fill Response​
-  - DRAM WB Requests​
-  - Snp Request​
-  - Snp Response
-- Request Priority: DRAM fill, miss reserve, core request, snoop request​
-- Snoop Request Queue​
-- DRAM Fill Queue​
-- Core Req Arbiter​
-  - Requests to be processed by the bank
-- Tag Data Store​
-  - Registers for valid, dirty, dirtyb, tag, and data​
-  - Length of registers determined by lines in the bank​
-- Tag Data Access:​
-  - I/O: stall, snoop info, force request miss
-  - Writes to cache or sends read response; hit or miss determined here
-  - A missed request goes to the miss reserve if it is not a snoop request or DRAM fill 
+Deadlocks inside the cache can occur when the MSHR is full and a new request is already in the pipeline. It can also occur when the memory request queue is full, and there is an incoming memory response. The cache mitigates MSHR deadlocks by using an early full signal before a new request is issued and similarly mitigates memory deadlocks by ensuring that its request queue never fills up.

docs/microarchitecture.md

@@ -24,71 +24,57 @@ Vortex uses the SIMT (Single Instruction, Multiple Threads) execution model with
   - Control the number of warps to activate during execution
   - `WSPAWN` *count, addr*: activate count warps and jump to addr location
 - **Control-Flow Divergence**
-  - Control threads to activate when a branch diverges
-    - `SPLIT` *predicate*: apply 'taken' predicate thread mask adn save 'not-taken' into IPDOM stack
-    - `JOIN`: restore 'not-taken' thread mask
+  - Control threads activation when a branch diverges
+    - `SPLIT` *taken, predicate*: apply predicate thread mask and save current state into IPDOM stack
+    - `JOIN`: pop IPDOM stack to restore thread mask
+    - `PRED` *predicate, restore_mask*: thread predicate instruction
 - **Warp Synchronization**
   - `BAR` *id, count*: stall warps entering barrier *id* until count is reached
 
 ### Vortex Pipeline/Datapath
 
-![Image of Vortex Microarchitecture](./assets/img/vortex_microarchitecture_v2.png)
+![Image of Vortex Microarchitecture](./assets/img/vortex_microarchitecture.png)
 
-Vortex has a 5-stage pipeline: FI | ID | Issue | EX | WB.
+Vortex has a 6-stage pipeline:
+
+- **Schedule**
+  - Warp Scheduler
+    - Schedule the next PC into the pipeline
+    - Track stalled, active warps
+  - IPDOM Stack
+    - Save split/join states for divergent threads
+  - Inflight Tracker
+    - Track in-flight instructions
 
 - **Fetch**
-  - Warp Scheduler
-    - Track stalled & active warps, resolve branches and barriers, maintain split/join IPDOM stack
-  - Instruction Cache
-    - Retrieve instruction from cache, issue I-cache requests/responses
+  - Retrieve instructions from memory
+  - Handle I-cache requests/responses
 - **Decode**
-  - Decode fetched instructions, notify warp scheduler when the following instructions are decoded:
-    - Branch, tmc, split/join, wspawn
-  - Precompute used_regs mask (needed for Issue stage)
+  - Decode fetched instructions
+  - Notify warp scheduler on control instructions
 - **Issue**
-  - Scheduling
-    - In-order issue (operands/execute unit ready), out-of-order commit
   - IBuffer
-    - Store fetched instructions, separate queues per-warp, selects next warp through round-robin scheduling
+    - Store decoded instructions in separate per-warp queues
   - Scoreboard
     - Track in-use registers
-  - GPRs (General-Purpose Registers) stage
-    - Fetch issued instruction operands and send operands to execute unit
+    - Check register use for decoded instructions
+  - Operands Collector
+    - Fetch the operands for issued instructions from the register file
 - **Execute**
   - ALU Unit
-    - Single-cycle operations (+,-,>>,<<,&,|,^), Branch instructions (Share ALU resources)
-  - MULDIV Unit
-    - Multiplier - done in 2 cycles
-    - Divider - division and remainder, done in 32 cycles
-      - Implements serial alogrithm (Stalls the pipeline)
+    - Handle arithmetic and branch operations
   - FPU Unit
-    - Multi-cycle operations, uses `FPnew` Library on ASIC, uses hard DSPs on FPGA
-  - CSR Unit
-    - Store constant status registers - device caps, FPU status flags, performance counters
-    - Handle external CSR requests (requests from host CPU)
+    - Handle floating-point operations
   - LSU Unit
-    - Handle load/store operations, issue D-cache requests, handle D-cache responses
-    - Commit load responses - saves storage, Scoreboard tracks completion
-  - GPGPU Unit
-    - Handle GPGPU instructions
-      - TMC, WSPAWN, SPLIT, BAR
-    - JOIN is handled by Warp Scheduler (upon SPLIT response)
+    - Handle load/store operations
+  - SFU Unit
+    - Handle warp control operations
+    - Handle Control Status Registers (CSRs) operations
 - **Commit**
-  - Commit
-    - Update CSR flags, update performance counters
-  - Writeback
-    - Write result back to GPRs, notify Scoreboard (release in-use register), select candidate instruction (ALU unit has highest priority)
-- **Clustering**
-  - Group mulitple cores into clusters (optionally share L2 cache)
-  - Group multiple clusters (optionally share L3 cache)
-  - Configurable at build time
-  - Default configuration:
-    - #Clusters = 1
-    - #Cores = 4
-    - #Warps = 4
-    - #Threads = 4
-- **FPGA AFU Interface**
-  - Manage CPU-GPU comunication
-    - Query devices caps, load kernel instructions and resource buffers, start kernel execution, read destination buffers
-  - Local Memory - GPU access to local DRAM
-  - Reserved I/O addresses - redirect to host CPU, console output
+  - Write result back to the register file and update the Scoreboard.
+
+### Vortex clustering architecture
+- Sockets
+  - Grouping multiple cores sharing L1 cache
+- Clusters
+  - Grouping of sockets sharing L2 cache