SECDA-DSE: FPGA Accelerator Exploration

• SECDA-DSE is a framework that integrates large language models into hardware/software co-design to automate FPGA accelerator exploration for AI workloads.
• It employs chain-of-thought prompting, retrieval-augmented generation, and LoRA-based fine-tuning to refine design candidates and reduce manual intervention.
• The system ensures end-to-end validation by coupling SystemC simulation, HLS synthesis, and FPGA execution to achieve reliable performance metrics.

SECDA-DSE is a framework for the design space exploration of FPGA-based accelerators that integrates LLMs into the SECDA hardware-software co-design ecosystem. In the recent FPGA literature, it is presented as a layer on top of SECDA that combines a structured generator of SECDA-compliant accelerator templates with reasoning-guided exploration, retrieval-augmented generation, chain-of-thought prompting, parameter-efficient fine-tuning, and an evaluation-and-feedback loop. Its stated purpose is to reduce the manual effort and domain expertise otherwise required to identify efficient accelerator configurations for modern artificial intelligence workloads, while preserving end-to-end validation through SystemC simulation, HLS synthesis, and FPGA execution (Sharma et al., 9 Jun 2026).

1. Origin within the SECDA methodology

SECDA-DSE is explicitly derived from SECDA, a hardware/software co-design methodology for FPGA-based DNN accelerators for edge inference. SECDA combines cost-effective SystemC simulation with hardware execution, and its original contribution was to streamline design space exploration and accelerator development by reducing design evaluation time. In its PYNQ-Z1 case study, SECDA explored a parameterized accelerator space over parallelism factors, loop-unrolling factors, tile sizes, on-chip memory allocation, and operating frequency; the paper states that this machinery allowed exploration of $O(10^5)$ design points in a matter of days rather than months, and that its final designs achieved an average performance speedup across models of up to $3.5\times$ with a $2.9\times$ reduction in energy consumption over CPU-only inference (Haris et al., 2021).

Against that background, SECDA-DSE addresses what the SECDA papers identify as the remaining manual bottleneck: SECDA/TFLite provides rapid SystemC simulation and HLS flows, but the selection of promising configurations still depends on designer intervention. The initial SECDA-DSE paper framed this as an LLM-driven design space exploration problem and demonstrated feasibility through an initial high-level synthesis based evaluation of a generated accelerator design that meets synthesis timing and resource constraints on a Zynq-7000 FPGA. The later extension broadened the evaluation to end-to-end FPGA execution across three kernels, thereby shifting the emphasis from proof-of-concept HLS feasibility to hardware-validated accelerator generation (Sharma et al., 7 May 2026).

2. Architectural organization

SECDA-DSE is organized around three tightly coupled components: a Structured DSE Explorer, an LLM Stack, and an Evaluation & Feedback Loop. The Structured DSE Explorer enumerates SECDA-compliant accelerator templates by permuting architectural parameters such as tiling factors, compute-unit dimensions, buffer sizes, and dataflow choices. Each candidate is instantiated into SystemC, simulated via SECDA’s SystemC simulator, synthesized via HLS, and—if it passes HLS—deployed on the target FPGA (Sharma et al., 9 Jun 2026).

The LLM Stack orchestrates which regions of the design space to explore or refine. Its retrieval-augmented generation layer dynamically retrieves relevant snippets of SECDA-TFLite code, API descriptions, prior accelerator templates, and previously collected hardware datapoints from a vectorized knowledge base. The paper specifies a graph-based retrieval using fuzzy comment matching so that only the most contextually relevant fragments are supplied to the model, with the stated purpose of keeping token costs manageable. The same stack uses chain-of-thought prompting to induce multi-step reasoning over workload characteristics, hardware constraints, and performance targets, and it applies parameter-efficient fine-tuning via LoRA on a small initial corpus of $$(\text{configuration} \rightarrow \text{hardware result})$$ datapoints (Sharma et al., 9 Jun 2026).

The evaluation component closes the loop. Each candidate accelerator is functionally simulated, synthesize-validated, and then executed on the FPGA. The resulting measurements—latency, resource utilizations, DMA transfer sizes and speeds, and hardware-counter cycles—are stored as new hardware datapoints. Successes reinforce subsequent proposals, while failures such as HLS errors or resource violations are fed back as negative examples. A plausible implication is that SECDA-DSE treats invalid configurations not merely as discarded trials but as supervision about parameter ranges and workload-specific trade-offs (Sharma et al., 9 Jun 2026).

3. Optimization problem and execution flow

At a high level, SECDA-DSE is described as solving

$\text{minimize } \mathrm{Latency}(\theta)$

subject to

$$\mathrm{DSP}(\theta) \le \mathrm{DSP}_{\max}, \quad \mathrm{LUT}(\theta) \le \mathrm{LUT}_{\max}, \quad \mathrm{BRAM}(\theta) \le \mathrm{BRAM}_{\max},$$

where $\theta$ denotes the vector of architectural parameters, including compute parallelism, tile sizes, and buffer depths. The same description defines

$$\mathrm{Throughput} = \mathrm{Ops}_{\text{total}} / \mathrm{Latency}(\theta)$$

and

$$\mathrm{MemTraffic} = \mathrm{DMA\_recv\_bytes}(\theta) + \mathrm{DMA\_send\_bytes}(\theta).$$

These quantities formalize the latency-resource-memory trade-off that SECDA-DSE explores (Sharma et al., 9 Jun 2026).

The operational workflow begins with the DSE Explorer generating an initial batch of $\theta$ candidates. For each candidate, SECDA-DSE generates SystemC/SECDA code, runs fast cycle-accurate simulation to check functional correctness, and extracts early hardware-counter estimates:

• $3.5\times$0 data-load wait cycles
• $3.5\times$1 computation cycles
• $3.5\times$2 write-back cycles

If simulation passes, the flow invokes Vivado HLS 2019.2, then logic synthesis and place-and-route on a Xilinx Zynq-7000 $3.5\times$3. On-board execution then measures latency in milliseconds, resource utilization $3.5\times$4, DMA speeds in MB/s, and wait times in milliseconds. These datapoints are added to the SECDA-DSE database and become the substrate for later retrieval and refinement (Sharma et al., 9 Jun 2026).

This execution flow inherits SECDA’s two-level evaluation philosophy. In SECDA proper, the fast SystemC loop was used for broad exploration and occasional FPGA evaluation for reality checks and model refinement; the FPGA loop included HLS generation, synthesis/place-and-route, deployment to PYNQ-Z1, and comparison between simulated and measured latency and energy. SECDA-DSE preserves that dependence on actual hardware validation, but inserts an LLM-mediated proposal-and-refinement stage between enumeration and evaluation. This suggests that the system is best understood as a learned controller over an existing co-design toolchain rather than as a replacement for that toolchain (Haris et al., 2021).

4. Retrieval, chain-of-thought, and reinforced refinement

The defining feature of SECDA-DSE is the use of LLM reasoning to rank and refine candidate accelerator configurations. The retrieval-augmented generation component retrieves the top-$3.5\times$5 relevant code or context snippets from a vector-indexed database of SECDA-TFLite code fragments, templates, prior designs, and performance logs. The retrieved snippets are combined with the workload and partial design to form the prompt. The stated purpose is to provide only the minimal necessary context rather than the entire SECDA codebase (Sharma et al., 7 May 2026).

Chain-of-thought prompting is then used to structure the search. The framework gives explicit prompt templates such as: “Step 1: Analyze the workload’s memory vs. compute intensity. Step 2: Identify if DSPs or BRAMs are likely to bottleneck. Step 3: Propose new tiling and compute-unit dimensions.” In the earlier SECDA-DSE description, a related template asks the model to list possible PE array dimensions, estimate resource usage qualitatively, select top candidates that balance utilization and latency, and output a refined parameter vector $3.5\times$6. In both versions, the LLM is not only generating code-adjacent artifacts but also performing workload-conditioned architectural reasoning (Sharma et al., 9 Jun 2026).

LoRA supplies parameter-efficient adaptation. The framework collects training pairs consisting of prompts, proposed configurations, and evaluation outcomes such as success, failure, and metrics. The update is described as modifying only small weight matrices within selected Transformer layers, and the earlier paper writes the LoRA update in reinforcement-learning style through a reward function that combines performance, resource usage, and synthesis success. The later paper emphasizes that LoRA is applied on a small initial corpus of hardware datapoints so that the model learns device- and workload-specific patterns without full-model retraining (Sharma et al., 7 May 2026).

The feedback loop gives these mechanisms operational significance. Failures are logged and fed back as negative examples. One example given in the paper is an HLS error caused because tile_x * tile_y exceeded available DSPs; that failure is then used to teach the model to avoid that combination in future chain-of-thought reasoning. For convolution, the same reasoning machinery may propose larger tile factors to increase data reuse and thereby reduce $3.5\times$7 and $3.5\times$8, even if DSP utilization rises slightly. This suggests that SECDA-DSE is intended to learn not only feasibility boundaries but also workload-specific resource-allocation heuristics (Sharma et al., 9 Jun 2026).

5. Evaluation results and workload-dependent trade-offs

The extended evaluation used three kernels selected to stress different regions of the design space: element-wise vector multiplication, described as arithmetically intensive and highly parallelizable; 2D convolution, described as compute with spatial data reuse; and matrix transpose, described as memory-movement dominated. For each kernel, a natural-language specification is passed to SECDA-DSE, the RAG and CoT modules produce an initial accelerator template in SystemC plus SECDA integration files, human operators trigger the SECDA validation flow, and functional correctness is checked by comparing FPGA outputs element-by-element with a CPU reference (Sharma et al., 9 Jun 2026).

The paper reports the following hardware measurements for the three generated designs:

Metric	2D Conv	VMUL	Transpose
Latency (ms)	163	135	238
HWC cycles (1/2/3)	1251/76/1250	52/26/51	393/311/387
DMA recv size (B)	256	64	512
DMA send size (B)	268	136	524
DMA recv speed (MB/s)	17.07	4.57	13.47
DMA send speed (MB/s)	38.29	19.43	30.82
BRAM util (%)	2.50	3.57	2.86
DSP util (%)	1.36	21.82	5.45
LUT util (%)	6.64	8.23	8.85
FF util (%)	4.30	6.02	5.84

The interpretation supplied by the paper is kernel-specific. The VMUL design leverages heavy parallelism, achieving only 51 compute cycles $3.5\times$9 but using $2.9\times$0 of DSPs. The 2D convolution design, despite modest DSP use $2.9\times$1, incurs high buffering overhead $2.9\times$2 and $2.9\times$3, reflecting complex data reuse patterns. The transpose kernel is dominated by memory movement, with the largest DMA transfers and the highest LUT usage $2.9\times$4, which the paper attributes to streaming reorganization logic (Sharma et al., 9 Jun 2026).

Convergence behavior also differed by workload. The paper states that 2D convolution reached a valid FPGA-executable design in 1 LLM cycle, VMUL took 4 cycles of CoT-guided refinement, and transpose required 9 cycles, 7 of which tackled downstream synthesis or timing closure issues. The same evaluation reports that, despite only fine-tuning on two simple datapoints—matrix addition and multiplication—TinyLlama with 1.1 B parameters generalized to all three kernels. The discovered patterns are summarized in the paper as follows: VMUL should maximize parallelism (P=L) subject to $2.9\times$5; 2D convolution benefits more from tiling to exploit BRAM caches and reduce off-chip bandwidth; transpose needs wider streaming engines to overlap load/store with the small compute core (Sharma et al., 9 Jun 2026).

6. Interpretation, limits, and future development

The central claim made for SECDA-DSE is that it constitutes a promising step toward autonomous FPGA accelerator design. That claim is grounded in three demonstrated properties: generation of SECDA-compliant accelerator designs from natural-language specifications, successful synthesis and execution on FPGA hardware, and adaptation of architectural configurations across diverse workloads by capturing trade-offs between compute parallelism and data movement (Sharma et al., 9 Jun 2026).

At the same time, the present system is not fully autonomous. The evaluation methodology explicitly includes human operators who trigger the SECDA validation flow from SystemC simulation through bitstream generation and on-board execution. The authors therefore identify full automation of the validation loop as future work, specifically by integrating SECDA as a “Model Context Protocol” (MCP) server and removing the current human-in-the-loop steps. Other future directions named in the papers include scaling evaluation across additional LLM sizes, FPGA families, and more complex AI workloads; expanding the hardware-datapoint corpus; comparing multiple model families such as Llama, Qwen, and GPT variants; and incorporating advanced multi-objective optimization or formal timing analysis (Sharma et al., 9 Jun 2026).

The papers also identify limitations that qualify the current results. Computational cost remains high for large search spaces and deep HLS flows. Proposal quality depends on the representativeness of the accumulated hardware datapoints. There is also a risk of LLM “mode collapse” to safe but suboptimal designs, which the earlier paper says can be mitigated via diversity sampling. These caveats indicate that SECDA-DSE should be read not as a replacement for synthesis-validated hardware methodology, but as an attempt to compress expert-guided exploration into a smaller number of higher-quality iterations (Sharma et al., 7 May 2026).

Compared with manual SECDA design-space exploration, the papers argue that SECDA-DSE reduces exploration from what might require dozens of engineer-weeks to a handful of LLM-driven iterations. This suggests a shift in the role of the designer: from manually navigating parameter sweeps and rule-of-thumb trade-offs to supervising a system that retrieves prior knowledge, proposes SECDA-compliant architectures, and refines them against measured hardware outcomes. Within the SECDA lineage, that shift is the distinctive contribution associated with the name SECDA-DSE (Sharma et al., 9 Jun 2026).