# `operand_requester` Module Documentation

## Overview

The `operand_requester` module orchestrates operand fetches from the Vector Register File (VRF) and delivers them to operand queues. It supports:

- **VRF access arbitration** across multiple operand queues and functional units
- **Hazard tracking** to prevent data hazards between instructions
- **Per-bank grant handling** for load/store, ALU, mask, slide units, etc.
- **VRF write-backs** from functional units
- **Exception flushing** for store-related hazards

---

## Interface Description

### Inputs

- `clk_i`, `rst_ni`: Clock and active-low reset.
- `global_hazard_table_i`: Tracks instruction dependencies across vector instructions.
- `operand_request_i`, `operand_request_valid_i`: Requests from operand queues.
- `lsu_ex_flush_i`: Flush signal for store exceptions.
- `operand_queue_ready_i`: Queue ready status for issued operands.
- Functional unit write-back inputs (`*_result_*_i`): ALU, MFPU, Mask, Slide, Load.

### Outputs

- `operand_request_ready_o`: Ready to accept new requests.
- `lsu_ex_flush_o`: Acknowledge exception flush.
- `vrf_*_o`: Outputs for accessing the VRF (read/write).
- `operand_queue_*_o`: Commands and valid signals for operand queues.
- Functional unit grant outputs (`*_result_*_gnt_o`, `*_result_final_gnt_o`)

---

## Internal Mechanisms

### Stream Registers

For results written back from VLDU, Slide, and Mask units, **stream registers** are used to buffer incoming data and synchronize write-backs. These wrap ID, address, data, and byte-enable.

Each stream register:
- Buffers a result from a VFU
- Issues a valid signal
- Acknowledges with a grant signal

Final grants are issued when data is truly committed to VRF to avoid releasing hazards prematurely.

---

### Hazard Management

- Each operand requester tracks hazards using `requester_metadata_t`.
- Hazards are checked against a global hazard table.
- Stalls are inserted if a dependency is not resolved.

Hazards specifically handled:
- **Write-after-read (WAR)** and **write-after-write (WAW)**
- **Widening operations** (doubling vector width) use toggling counters to synchronize requests.

---

### Operand Fetch State Machine

Each operand requester has a **2-state FSM**:
- `IDLE`: Wait for a new request.
- `REQUESTING`: Issue operand accesses to the VRF.

On receiving a valid request:
- VRF address is computed
- Metadata is initialized
- Commands are sent to the operand queue
- Transition to `REQUESTING`

In `REQUESTING`:
- Stall if hazard unresolved
- Issue bank-aligned requests
- Update address and element counters
- Transition to `IDLE` once all elements are read

---

### Arbitration

Each VRF bank instantiates:

1. **High-Priority Arbiter**:
   - ALU
   - MFPU
   - Mask Unit

2. **Low-Priority Arbiter**:
   - Slide Address Generator
   - Load Unit
   - Store-Related Operand Queues

3. **Top-Level Arbiter**:
   - Selects between high and low priority
   - Drives VRF signals: `vrf_req_o`, `vrf_addr_o`, `vrf_wen_o`, etc.

---

## Exception Flushing

On store-related exceptions (`lsu_ex_flush_i`), operand requests associated with:
- `StA` (Store Address)
- `SlideAddrGenA`
- `MaskM`

are **aborted** immediately. Metadata is reset, and the FSM transitions back to `IDLE`.