Source-linked AI summary
A State Augmented Approach to Paralle Modeling in High-Level Synthesis
Nicholas Kovacs, Hao Zheng
TL;DR
Feedback-coupled designs need explicit state boundaries and hazard rules because HLS schedules only concurrency permitted by the input description. The paper models these rules with synchronous processes and reports a CPI-optimized RV32I design at 1.221 aggregate CPI, compared with 4.000 for the baseline and 1.575 for Ibex.
Problem
For feedback-coupled designs, a sequential behavioral model can obscure architectural state boundaries and the forwarding, stall, and redirection rules needed for overlap.
Source: §1 · p. 1Method
The method represents persistent state, communication, and feedback control with synchronous sequential processes, leaving detailed scheduling and resource binding to HLS.
Source: §3.1 · p. 3Results
The CPI-optimized design achieves 1.221 aggregate CPI versus 4.000 for the baseline and 1.575 for Ibex.
Source: §4.2 · p. 5Takeaways & Limitations
The study separates designer-controlled architectural and hazard decisions from HLS-controlled scheduling and binding in its RV32I case study.
Source: §1 · p. 1, §5 · p. 7The evaluation uses fixed-latency on-chip memory; the external-memory implementation reaches II=169, and a proposed separate-process configuration remains unbuilt and unmeasured.
Source: §3.3 · p. 4
Abstract
from arXiv · showhide
High-level synthesis (HLS) can schedule only the concurrency made legal by its input description. For feedback-coupled designs, a sequential behavioral model can obscure the architectural state boundaries and hazard resolution needed for efficient overlap. We develop an explicit architectural modeling methodology based on synchronous sequential processes that start in lockstep and synchronize completion before repeating. Persistent state, communication, and feedback control are represented in C++, while HLS schedules and binds operations within that structure. A five-stage RV32I processor illustrates three consequential modeling decisions: which version of a value a consumer reads, when it consumes that value, and how architectural memory actions map to port operations. On a Kintex UltraScale+ FPGA, the CPI-optimized configuration achieves 1.221 cycles per instruction at 220 MHz, compared with 4.000 for an algorithmic HLS baseline and 1.575 at 242 MHz for an Ibex reference. An area-optimized configuration reduces LUTs by 65\% and registers by 47\%, with 9.7\% more benchmark cycles and a 250 MHz achieved clock. These results demonstrate a separation between designer-controlled architecture and tool-controlled scheduling.
1 Introduction
Feedback-coupled designs require explicit rules for forwarding, stalls, and redirection because HLS schedules only concurrency permitted by the source description. The paper models those architectural rules in synchronous processes while leaving detailed scheduling and binding to HLS.
1 Introduction
- For feedback-coupled designs, efficient overlap requires explicit forwarding, stall, and redirection rules that scheduling directives alone do not specify.The next computation depends on evolving shared state, unlike regular array computations where loop pipelining, unrolling, and task decomposition can expose concurrency.Source: §1 · p. 1
- The instruction-set-simulator-style baseline achieves an initiation interval of four, and a more aggressive schedule fails the clock target.Runtime register indices and branch outcomes require a microarchitecture that handles value dependencies and control changes.Source: §1 · p. 1
- The proposed C++ model uses synchronous processes that compute concurrently and synchronize before committing selected state and repeating.The designer specifies communication and consumption timing; HLS schedules and binds operations within those semantics.Source: §1 · p. 1
- A five-stage RV32I case study examines how communication, consumption timing, and memory operations affect II, frequency, and area.The evaluation compares an algorithmic HLS baseline, an Ibex reference, and CPI- and area-optimized configurations; its results are specific to this processor family and tool flow.Source: §1 · p. 1
2 Background and Positioning
The background distinguishes loop pipelining from feedback-aware architectural modeling and positions the work alongside processor-description and HLS-optimization approaches. It builds on explicit-state precedent while studying how modeling choices affect measured performance and area.
2.1 Scheduling, State, and Directives
- Loop pipelining overlaps iterations subject to recurrences, timing, and resource limits, while a reported stream-based processor formulation was merged by Vitis because of feedback and then failed synthesis.The failed synthesis concerns that formulation and tool flow; it does not establish that channel-based designs cannot express feedback.Source: §2.1 · pp. 1–2
2.2 Processor Descriptions and HLS Cores
- Processor descriptions range from configurable RTL and generators to compact multi-cycle designs, and Ibex is an implementation reference rather than an iso-microarchitecture baseline.Other HLS processor efforts motivate construction and validation; this work emphasizes the link between explicit source architecture, legal scheduling, and measured tradeoffs.Source: §2.2 · p. 2
- Comet provides explicit inter-stage state and current-state/next-state updates; this study examines the performance and area consequences of choices made within that structure.Comet reports II=1 but Dhrystone CPI=1.9, illustrating that static scheduling throughput and runtime stall cost differ.Source: §2.2 · p. 2
- The area-optimized configuration uses 1,980 LUTs versus Ibex’s 1,940 and 1,595 registers versus 702, while completing the kernel suite in 0.82 times Ibex’s time.The source serves both as a host-compiled executable model and as synthesis input, but modeled iterations correspond to hardware cycles only at II=1 with fixed memory latency.Source: §2.2 · p. 2
2.3 Directive Search and Structural Transformation
- Directive search and structural-transformation approaches complement explicit architectural modeling, with reviewed evaluations focused on regular accelerator computations rather than runtime-indexed, feedback-coupled processor state.The paper positions its formulation as complementary and does not claim automated restructuring is generally impossible.Source: §2.3 · p. 2
3 Explicit Architectural Modeling
The method models persistent state and communication through synchronous processes that compute concurrently and synchronize before advancing. The RV32I example makes stage boundaries, hazard feedback, operand timing, and memory-port requirements explicit so HLS can schedule operations within those rules.
3.1 Synchronous Sequential Process Model
- The modeled process boundaries, communication, and synchronized update rules define architectural state, while HLS schedules operations and binds resources subject to them.A modeled iteration may take multiple hardware cycles; II=1 is a measured outcome, not an assumption of the model.Source: §3.1 · p. 3
3.2 RISC-V Example: Five Synchronized Processes
- Five synchronous processes map fetch, decode, execute, memory, and writeback to pipeline stages that work on different in-flight instructions before synchronizing.The figure’s list denotes phases and concurrent work, not a serial hardware schedule.Source: §3.2 · p. 3, Figure 1 · p. 3
3.3 Feedback, Hazards, and Communication Timing
- Forwarding selects the youngest available older producer, while a load-use interlock holds the front end and inserts a bubble until the needed value becomes available.A redirect from an older instruction supersedes younger candidate work, and validity gates architectural side effects.Source: §3.3 · pp. 3–4
- The reported external-memory implementation reaches II=169 because its variable-latency response is awaited inside the modeled iteration; a separate memory process is proposed but unmeasured.The authors identify the external-memory path as the clearest limitation of the evaluation.Source: §3.3 · p. 4
3.4 Consumption Timing and Memory Operations
- Moving branch and jump resolution to execute lets the register-file read cross a stage boundary, making the same storage-binding request compatible with II=1.This trades for a later redirect and increased branch penalty; the CPI-optimized design also uses four independently addressed byte lanes to avoid a read-modify-write store.Source: §3.4 · p. 4
- Deferring host-interface acknowledgement makes two otherwise competing stores mutually exclusive, changing the scheduled port operations rather than suppressing a real conflict.The area-optimized design instead carries a byte-write strobe with a single-port write.Source: §3.4 · p. 4
4 Experimental Evaluation
The evaluation compares four configurations on identical binaries and reports throughput, execution time, resource use, and workload-dependent results. The CPI- and area-optimized designs show different trade-offs in cycles, frequency, and area, within the tested processor and memory settings.
4.1 Setup and Validation
- Identical binaries ran on a KCU116 with equal-latency 256 KB storage, while an external hardware counter measured whole-program cycles.The HLS systems used separate instruction/data memories and Ibex used unified memory; those system-memory costs are excluded from the core-resource table. Validation includes directed tests, eight kernels, CoreMark CRC checks, RTL simulation, and board execution, but is not exhaustive proof of ISA or trap correctness.Source: §4.1 · pp. 4–5
4.2 Does Explicit Structure Improve the Behavioral Baseline?
- The CPI-optimized design reaches 1.221 aggregate CPI versus 4.000 for the baseline and 1.575 for Ibex; at each design’s maximum clock, execution time is 0.85× Ibex for CPI optimization and 0.82× for area optimization.The area-optimized design has the shorter absolute runtime of the two HLS configurations.Source: Table 1 · p. 5, §4.2 · p. 5, Table 2 · p. 6
- The algorithmic baseline reaches II=4 after register-file partitioning; a forced aggressive schedule has a 7.34 ns critical path against a 4 ns target.The measured II is specific to this description and configuration, not a universal lower bound for behavioral HLS.Source: §4.2 · p. 5
4.3 What Remains Necessary to Reach II=1?
- Explicit state initially yields II=5; deferring acknowledgement, removing registered stage-function boundaries, and eliminating sub-word-store read-modify-write successively reduce II to one.Five other attempted changes did not change II.Source: §4.3 · p. 5
4.4 How Do Structural Choices Change Area?
- Relaxing the scheduling target from 8 ns to 10 ns removes 452 registers without changing II or measured cycles, while achieved frequency falls from 246 to 208 MHz.Source consolidation and other structural changes reduce LUT use, but counter narrowing limits equivalence to the tested operating range.Source: §4.4 · p. 5
- Four byte lanes remove sub-word-store read-modify-write, halving cycles on every benchmark, but the restructuring makes the net execution-time gain 34% rather than 2×.The clock request also affects scheduling storage and performance; targets of 6 ns or tighter lose II=1.Source: Table 3 · p. 6, §4.4 · p. 6
- The final area-optimized configuration uses 1,980 LUTs and 1,595 registers, reducing LUTs by 65% and registers by 47% at the cost of 9.7% more kernel cycles.An 8 ns build uses 2,226 LUTs and 1,736 registers and reaches 256 MHz; hardware cycle counts match full-system RTL simulation on the measured kernels.Source: Table 4 · p. 6, §4.4 · p. 6
4.5 Workload Dependence and Limits
- CoreMark results diverge by metric: CPI optimization leads Ibex in CoreMark/MHz (0.971 versus 0.915) but trails in iterations/s (213.7 versus 221.3).The evaluation covers eight kernels and CoreMark, not caches, external-memory stalls, or broader application mixes; non-processor evaluation and a matched RTL architecture remain future work.Source: Table 5 · p. 6, §4.5 · p. 6
5 Conclusion
Explicit architectural modeling separates designer-controlled state, communication, and hazard decisions from HLS-controlled scheduling and binding. The RV32I case study shows how modeling choices shape II and performance–area tradeoffs, while broader applications remain unevaluated.
5 Conclusion
- Explicit architectural modeling separates state, communication, and hazard decisions from the scheduling and binding decisions HLS can optimize.The formulation specifies which version of a shared value a consumer reads, when it consumes that value, and which ports it requires.Source: §5 · pp. 6–7
- In the RV32I example, communication paths, consumption timing, and memory-operation structure determine II and performance–area tradeoffs.Source: §5 · p. 7
- The state-transition formulation also applies to arbitration- or allocation-dependent designs, but the switch arbiter, cryptographic round, and cache-controller examples were not evaluated.Source: §5 · p. 7