--- title: 'COPIFTv2: Dual-Issue RISC-V Enhancement' url: https://www.emergentmind.com/topics/copiftv2 type: topic --- # COPIFTv2: Dual-Issue RISC-V Enhancement COPIFTv2 is an architectural and programming refinement for lightweight RISC-V cores, designed to maximize the efficiency and programmability of dual-issue execution under stringent area and energy constraints. Building upon the limitations of the earlier COPIFT approach, COPIFTv2 introduces a hardware-based, queue-centric mechanism for synchronizing and transferring data between integer and floating-point (FP) threads. This enables near-peak dual-issue performance in tiny in-order processors such as Snitch, with substantially reduced software complexity and overhead, directly addressing scalability requirements in large-scale machine learning accelerators [2601.17940]. ## 1. Historical Context and Motivation Original COPIFT (2015–2025) sought to exploit the decoupled integer/FP execution in lightweight RISC-V designs by orchestrating batches of work between two threads (I-thread and F-thread), using software pipelining and memory buffers for synchronization. Despite achieving up to 1.75× instructions per cycle (IPC) on mixed workloads, COPIFT suffered from multiple intrinsic bottlenecks: - **Complex code transformations:** Required multi-buffer tiling, explicit software pipelining, and batch-size tuning. - **High software overheads:** Relied on frequent spill/reload of synchronization data to memory, increasing latency and power. - **Limited fine-grain communication:** Dependencies could only resolve at batch boundaries, delaying critical-path dataflow. The target architecture—Snitch core—features a single-issue, in-order RISC-V microarchitecture, with a Tiny Floating-Point Subsystem (FPSS). It implements pseudo–dual-issue by dispatching all instructions through the integer pipeline, offloading FP operations to the FPSS. Core design constraints enforce area budgets below 0.1 mm² and power below 1 mW at 1 GHz, precluding out-of-order logic or complex renaming [2601.17940]. ## 2. Architectural Innovations COPIFTv2 eliminates software-centric synchronization by embedding two lightweight, hardware-based first-in/first-out (FIFO) queues within the core, facilitating direct, order-preserving communication and synchronization between integer and FP threads: - **Queue Configuration:** - Two queues per core: I2F (integer-to-FP) and F2I (FP-to-integer) - Each queue: 8-entry depth (configurable), 32/64 bits width, SCM-based - Control logic: head/tail pointers, full/empty flags, modulo-$N$ counter - **Operation Semantics:** - Enqueue ("push") into the queue is blocked if full; dequeue ("pop") blocks if empty, enforcing natural producer-consumer synchronization. - Integer (I) thread and FP (F) thread communicate exclusively via these queues (no indirect memory buffers required). - At pipeline integration points: - Integer pipeline write-back: writing to $x31$ with queue-CSR enabled triggers I2F push. - FPSS write-back: "virtual" rd=$x31$ writes push onto F2I. - Decoding: reading rs=$x31$ pops from the corresponding queue. This minimal hardware extension introduces area overhead of ≲1%, minimally disrupts timing (no impact on 1 GHz critical path), and requires only trivial handshake logic [2601.17940]. ## 3. Programming Model COPIFTv2 replaces the original's complex, transformation-heavy software approach with a simplified model based on API-driven thread management and intra-iteration parallelization: - **Model Simplification:** - Eliminates multi-buffer tiling and inter-batch software pipelining. - No inter-iteration scheduling or explicit modulo scheduling. - **Algorithmic Steps:** 1. Construct the data-flow graph (DFG) of interleaved integer and FP ops. 2. Partition into I-only and F-only subgraphs. 3. Independently schedule for maximum overlap. 4. Replace inter-thread dependencies with explicit queue push/pops (via $x31$). 5. Enclose FP subgraph within the hardware FREP loop. - **API and Synchronization:** - Thread launch/join library calls: - `int launch_fp_thread(void *entry_point);` - `void join_fp_thread();` - Launch configures the relevant CSR, initializes queue addresses, and forks FP execution. - Synchronization is managed implicitly by draining the corresponding queue at join. - **Pseudocode Example:** ```c // Integer thread (producer) enable_copift_queues(); launch_fp_thread(fp_worker); for (i=0; i