ai-research-survey

scan.json (31616B)

---

 {
   "paper": {
     "title": "LAAFD: LLM-based Agents for Accelerated FPGA Design",
     "authors": [
       "Maxim Moraru",
       "Kamalavasan Kamalakkannan",
       "Jered Dominguez-Trujillo",
       "Patrick Diehl",
       "Atanu Barai",
       "Julien Loiseau",
       "Zachary Kent Baker",
       "Howard Pritchard",
       "Galen M. Shipman"
     ],
     "year": 2026,
     "venue": "arXiv",
     "arxiv_id": "2602.06085"
   },
   "scan_version": 2,
   "active_modules": ["experimental_rigor", "data_leakage"],
   "methodology_tags": ["benchmark-eval"],
   "key_findings": "LAAFD, an agentic workflow using LLMs (GPT-5, o4-mini, GPT-5-nano), translates C++ kernels into optimized Vitis HLS code for FPGAs. On 15 HPC kernels, the best runs achieve 99.9% geomean performance vs hand-tuned baselines. For stencil workloads, LAAFD matches SODA (a domain-specific HLS generator) while producing 8.3x fewer lines of code. However, results are reported as best-of-multiple-runs, and only GPT-5 achieves high performance across all kernels—o4-mini and GPT-5-nano perform poorly on complex kernels (52.5% and 32.7% geomean respectively).",
   "checklist": {
     "artifacts": {
       "code_released": {
         "applies": true,
         "answer": false,
         "justification": "No repository URL, code archive, or supplementary material link is provided anywhere in the paper. The LAAFD system, agent prompts, and kernel benchmarks are not released."
       },
       "data_released": {
         "applies": true,
         "answer": false,
         "justification": "The C++ kernels, test benches, HLS reports, and generated code are not released. No download links or data archives are mentioned."
       },
       "environment_specified": {
         "applies": true,
         "answer": false,
         "justification": "Table III specifies the HLS tool (Vitis 2022.2), FPGA target (xcu250-figd2104-2L-e), and target frequency (200 MHz). However, the software environment for the agentic workflow (Python version, API client versions, orchestration framework) is not specified."
       },
       "reproduction_instructions": {
         "applies": true,
         "answer": false,
         "justification": "No reproduction instructions, scripts, or step-by-step guides are provided. The workflow is described at a high level but not with enough detail to reproduce."
       }
     },
     "statistical_methodology": {
       "confidence_intervals_or_error_bars": {
         "applies": true,
         "answer": false,
         "justification": "Tables I and IV report single point estimates (cycle counts) with no confidence intervals, error bars, or uncertainty measures, despite the authors acknowledging stochastic variation across runs in Section V.E."
       },
       "significance_tests": {
         "applies": true,
         "answer": false,
         "justification": "No statistical significance tests are used. Claims such as '99.9% geomean performance' and comparisons between models are based on raw numbers without any hypothesis testing."
       },
       "effect_sizes_reported": {
         "applies": true,
         "answer": true,
         "justification": "Effect sizes are reported as percentage of ideal/baseline performance: '99.9% geomean' for GPT-5, '52.5%' for o4-mini, '32.7%' for GPT-5-nano (Section V.D). Tables I and IV provide absolute cycle counts alongside ideal minimums, giving full context for the magnitude of differences."
       },
       "sample_size_justified": {
         "applies": true,
         "answer": false,
         "justification": "The paper evaluates 15 kernels plus 7 SODA kernels but provides no justification for why this number is sufficient to support claims about FPGA design automation broadly. No power analysis or sample size rationale is given."
       },
       "variance_reported": {
         "applies": true,
         "answer": false,
         "justification": "Section V.E acknowledges stochastic variation: 'different runs may yield different results even under identical settings.' Yet only the best results are reported with no standard deviation, range, or distribution across runs. For SODA kernels, 'only one or two [of ten] runs produced HLS code deemed optimal' but no variance is quantified."
       }
     },
     "evaluation_design": {
       "baselines_included": {
         "applies": true,
         "answer": true,
         "justification": "Two baselines are included: manually optimized HLS kernels (Table I) and SODA-generated kernels (Table IV). Both represent reasonable comparison points."
       },
       "baselines_contemporary": {
         "applies": true,
         "answer": true,
         "justification": "The paper justifies SODA (2018) as 'state-of-the-art DSL-based HLS code generator for stencil solvers' in Section III. The manually tuned baselines are custom implementations, not stale prior work. Recent related tools (HLSPilot, C2HLSC) are discussed but differ in scope."
       },
       "ablation_study": {
         "applies": true,
         "answer": false,
         "justification": "The system has multiple components (translator, compile fixer, runtime fixer, judge, optimizer) but no ablation study removes individual components to measure their contribution. The LLM comparison (GPT-5 vs o4-mini vs GPT-5-nano) tests model capability, not workflow component importance."
       },
       "multiple_metrics": {
         "applies": true,
         "answer": true,
         "justification": "Multiple metrics are reported: execution cycles/latency (Tables I, IV), FPGA resource utilization—LUT, FF, DSP, BRAM (Tables IV, V), lines of code (Tables IV, V), and cyclomatic complexity (Table VI)."
       },
       "human_evaluation": {
         "applies": true,
         "answer": false,
         "justification": "No human evaluation is conducted. The paper claims LAAFD produces 'more readable kernels' and 'high quality, readable, and less complex' code (Section V.C) but uses only automated proxies (LoC, cyclomatic complexity) without human readability assessment."
       },
       "held_out_test_set": {
         "applies": true,
         "answer": false,
         "justification": "No separation between development and evaluation sets. The same 15 kernels were presumably used to develop and tune the agentic workflow prompts, and then to report final results. No held-out evaluation is described."
       },
       "per_category_breakdown": {
         "applies": true,
         "answer": true,
         "justification": "Tables I and IV provide per-kernel cycle counts. Table II maps optimizations per kernel. Table V provides per-kernel resource utilization. Table VI provides per-kernel complexity. Figure 9 shows per-kernel model comparison."
       },
       "failure_cases_discussed": {
         "applies": true,
         "answer": true,
         "justification": "Section V.E discusses failures: 'Only one or two runs produced HLS code deemed optimal...the remaining runs produced functionally correct but suboptimal designs.' Context size limits for larger kernels are also discussed. Section V.D reports GPT-5-nano and o4-mini struggling on complex stencil kernels."
       },
       "negative_results_reported": {
         "applies": true,
         "answer": true,
         "justification": "GPT-5-nano (32.7% geomean) and o4-mini (52.5% geomean) perform poorly on complex kernels. LAAFD uses more FPGA resources than manual baselines (Section V.B). Scalability limitations with large kernels are reported (Section V.E). Stochastic failures requiring multiple runs are documented."
       }
     },
     "claims_and_evidence": {
       "abstract_claims_supported": {
         "applies": true,
         "answer": true,
         "justification": "Abstract claims are supported: '99.9% geomean performance' is in Table I; 'matches the performance of SODA' is in Table IV; 'more readable kernels' is supported by LoC/complexity comparisons in Tables IV and VI. The abstract appropriately hedges with 'suggest' for the expertise barrier claim."
       },
       "causal_claims_justified": {
         "applies": true,
         "answer": false,
         "justification": "The paper claims LAAFD 'substantially lowers the expertise barrier to FPGA acceleration' (abstract) and that the workflow 'enables' optimization. These are causal claims but no study of actual developer experience or expertise requirements is conducted. The evidence shows cycle-count parity, not expertise barrier reduction."
       },
       "generalization_bounded": {
         "applies": true,
         "answer": false,
         "justification": "The title claims 'Accelerated FPGA Design' broadly, but results cover only 15 HPC kernels on a single FPGA (xcu250) with one tool (Vitis 2022.2). Section V.E notes 'effectiveness depends on kernel complexity' and the Outlook mentions extending to full applications, but the abstract's framing extends beyond what was tested."
       },
       "alternative_explanations_discussed": {
         "applies": true,
         "answer": false,
         "justification": "No alternative explanations are considered. For example, the near-ideal performance could partly reflect the structured nature of the benchmark kernels rather than general optimization capability. The paper does not discuss whether simpler approaches (template matching, DSL transformation) could achieve similar results."
       },
       "proxy_outcome_distinction": {
         "applies": true,
         "answer": false,
         "justification": "The paper measures cycle counts and code complexity but claims to 'lower the expertise barrier to FPGA acceleration.' The gap between the proxy (cycle count parity) and the outcome (reduced expertise requirement) is not acknowledged. No actual user study measures expertise barrier reduction."
       }
     },
     "setup_transparency": {
       "model_versions_specified": {
         "applies": true,
         "answer": false,
         "justification": "Table III lists 'gpt-5, o4-mini, gpt5-nano' without API versions, snapshot dates, or model IDs. These are marketing names that do not uniquely identify the model behavior."
       },
       "prompts_provided": {
         "applies": true,
         "answer": false,
         "justification": "Agent roles are described in natural language (Section IV.A) and example feedback is shown (Figs. 6, 8), but the actual system prompts, judge prompts, and optimizer prompts used in the agentic workflow are not provided. The 'list of possible HLS optimizations' given to the judge is mentioned but not shown."
       },
       "hyperparameters_reported": {
         "applies": true,
         "answer": false,
         "justification": "No LLM hyperparameters (temperature, top-p, max tokens) are reported. The iteration limit ('25 optimization iterations') is mentioned for SODA kernels but not for the full suite. No other hyperparameters are documented."
       },
       "scaffolding_described": {
         "applies": true,
         "answer": true,
         "justification": "The agentic workflow is described in detail in Section IV.A with a workflow diagram (Fig. 2). Roles of each agent (translator, compile fixer, runtime fixer, judge, optimizer) are explained. Independent context sessions, iteration limits, and the judge-optimizer feedback loop are documented. An illustrative example walks through the full pipeline (Section IV.A.4)."
       },
       "data_preprocessing_documented": {
         "applies": true,
         "answer": true,
         "justification": "Section IV.B describes kernel design and selection. Input C++ kernels are documented (e.g., Fig. 3). The translation constraints (preserve parameter count, allow type modifications) are specified. SODA kernel origins are cited. Table II maps optimizations per kernel."
       }
     },
     "limitations_and_scope": {
       "limitations_section_present": {
         "applies": true,
         "answer": true,
         "justification": "Section V.E 'Discussions' serves as a substantive limitations section. It discusses stochastic variation across runs, best-of-N reporting methodology, context size limitations for large kernels, and scalability challenges."
       },
       "threats_to_validity_specific": {
         "applies": true,
         "answer": true,
         "justification": "Section V.E raises study-specific threats: stochastic results requiring multiple runs ('Only one or two [of ten] runs produced optimal code'), context size exceeded for SODA kernels requiring report summarization, and dependence on kernel complexity. These are specific to this work, not boilerplate."
       },
       "scope_boundaries_stated": {
         "applies": true,
         "answer": true,
         "justification": "The paper states scope boundaries: 'This study focused on kernels; however, an important next step is to extend the methodology to full applications' (Outlook). Section V.E: 'effectiveness depends on kernel complexity, semantic correctness, and context limitations.' Resource optimization was explicitly excluded: 'the workflow was not instrumented to optimize resource utilization at any stage' (Section V.B)."
       }
     },
     "data_integrity": {
       "raw_data_available": {
         "applies": true,
         "answer": false,
         "justification": "No raw data is released: no generated HLS code, no HLS synthesis reports, no workflow logs, no intermediate outputs. Only summarized cycle counts and resource numbers in tables are provided."
       },
       "data_collection_described": {
         "applies": true,
         "answer": true,
         "justification": "Kernel selection is described in Section IV.B. Each kernel's purpose, dimension, and required optimizations are documented in Tables I and II. SODA kernels are sourced from Chi et al. [1] with equivalent C++ golden models written by the authors."
       },
       "recruitment_methods_described": {
         "applies": true,
         "answer": true,
         "justification": "The kernel selection rationale is described: 'a set of kernels with varying levels of complexity, ranging from simple single-loop structures to deeply nested loops involving multiple memory access operations' (Section IV.B). SODA kernels are explicitly sourced from prior work [1]."
       },
       "data_pipeline_documented": {
         "applies": true,
         "answer": false,
         "justification": "The workflow pipeline is described (Fig. 2), but the data pipeline from experiment execution to reported numbers is not fully documented. How many total runs were executed, how results were aggregated, and what happened with failed runs beyond 'we ran 10 times' for SODA kernels is not specified for the full kernel suite."
       }
     },
     "conflicts_of_interest": {
       "funding_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "The Acknowledgment section states release under LA-UR-26-20594 and identifies Los Alamos National Laboratory, operated by Triad National Security for the National Nuclear Security Administration (DOE contract 89233218CNA000001)."
       },
       "affiliations_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "All nine authors are listed as affiliated with Los Alamos National Laboratory. They evaluate OpenAI models (GPT-5, o4-mini, GPT-5-nano), not their own products, so no product-affiliation conflict exists."
       },
       "funder_independent_of_outcome": {
         "applies": true,
         "answer": true,
         "justification": "The funder (DOE/NNSA via LANL) has no financial interest in the performance of OpenAI's models or FPGA design tools. The funding is for national laboratory research, independent of the evaluated products."
       },
       "financial_interests_declared": {
         "applies": true,
         "answer": false,
         "justification": "No competing interests statement is included in the paper. While no obvious financial conflicts are apparent, the absence of a formal declaration does not constitute a declaration of no conflicts."
       }
     },
     "contamination": {
       "training_cutoff_stated": {
         "applies": true,
         "answer": false,
         "justification": "No training data cutoff dates are stated for GPT-5, o4-mini, or GPT-5-nano. The paper evaluates these models' ability to generate HLS code but does not address when their training data was collected."
       },
       "train_test_overlap_discussed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether the LLMs' training data included similar HLS code patterns. Section VI notes 'the relatively small amount of FPGA-related source code available on GitHub, which likely influenced LLM training' but this tangentially acknowledges limited training data rather than analyzing overlap."
       },
       "benchmark_contamination_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The custom kernels likely reduce contamination risk, but this is not explicitly discussed as a design choice. No contamination analysis is performed. SODA's published DSL code and prior HLS literature could be in training data."
       }
     },
     "human_studies": {
       "pre_registered": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in this study. The evaluation is entirely automated using HLS tools and cycle count comparisons."
       },
       "irb_or_ethics_approval": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. The study evaluates LLM-generated hardware code."
       },
       "demographics_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in the study."
       },
       "inclusion_exclusion_criteria": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in the study."
       },
       "randomization_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in the study."
       },
       "blinding_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in the study."
       },
       "attrition_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in the study."
       }
     },
     "cost_and_practicality": {
       "inference_cost_reported": {
         "applies": true,
         "answer": true,
         "justification": "Section VI: 'the cost of approximately US$50 to translate and optimize all 15 kernels highlights the feasibility of this approach, though server infrastructure costs are not included.' API costs are reported, though server-side HLS synthesis costs are excluded."
       },
       "compute_budget_stated": {
         "applies": true,
         "answer": false,
         "justification": "The $50 API cost is mentioned but total compute budget is not quantified. HLS synthesis time, number of co-simulations, total wall-clock time, and server compute costs are not reported. For SODA kernels, '10 runs × 25 iterations' is stated but compute time is not."
       }
     },
     "experimental_rigor": {
       "seed_sensitivity_reported": {
         "applies": true,
         "answer": false,
         "justification": "Section V.E acknowledges stochastic variation: 'different runs may yield different results even under identical settings.' However, only the best results are reported. No seed sensitivity analysis or distribution of outcomes across runs is provided."
       },
       "number_of_runs_stated": {
         "applies": true,
         "answer": true,
         "justification": "Section V.E: 'For the more complex SODA kernels, we ran the workflow ten times per kernel with 25 optimization iterations each.' For simpler kernels, 'sometimes even when using a smaller model' suggests fewer runs, though exact counts are not given for all kernels."
       },
       "hyperparameter_search_budget": {
         "applies": true,
         "answer": false,
         "justification": "No hyperparameter search is described. The workflow parameters (iteration limits, agent configurations) appear fixed without justification. The 25-iteration limit for SODA kernels is mentioned but not justified."
       },
       "best_config_selection_justified": {
         "applies": true,
         "answer": false,
         "justification": "Section V.E explicitly states: 'we report for each kernel the best HLS design obtained across multiple executions.' This is best-of-N cherry-picking without reporting the distribution of outcomes. The selection criterion is 'deemed optimal by the judge agent' but this inflates reported performance."
       },
       "multiple_comparison_correction": {
         "applies": false,
         "answer": false,
         "justification": "No statistical tests are performed at all, so multiple comparison correction does not arise. All comparisons are raw number differences."
       },
       "self_comparison_bias_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The manually tuned baselines (Table I) are the authors' own implementations, yet no acknowledgment of self-comparison bias is made. The optimality of the hand-tuned baselines is assumed without independent verification."
       },
       "compute_budget_vs_performance": {
         "applies": true,
         "answer": false,
         "justification": "No performance-vs-compute analysis. GPT-5 (99.9%) costs more than o4-mini (52.5%) and GPT-5-nano (32.7%), but no cost-performance tradeoff curves are presented. The $50 total cost is not broken down by model or kernel."
       },
       "benchmark_construct_validity": {
         "applies": true,
         "answer": false,
         "justification": "The paper claims the 15 kernels represent 'common compute patterns in HPC' but does not validate this claim. No discussion of whether these kernels adequately represent the breadth of FPGA design challenges, or whether cycle count parity captures meaningful design quality."
       },
       "scaffold_confound_addressed": {
         "applies": true,
         "answer": true,
         "justification": "All three LLMs (GPT-5, o4-mini, GPT-5-nano) are evaluated within the same LAAFD scaffold, isolating model differences from scaffold differences. The comparison in Section V.D and Figure 9 uses identical workflow across models."
       }
     },
     "data_leakage": {
       "temporal_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of temporal leakage. The models could have been trained on HLS examples, SODA papers, or similar kernel implementations without any analysis of this risk."
       },
       "feature_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether the evaluation setup leaks information. The agents receive HLS reports and error messages as feedback, which is by design, but no analysis of whether this constitutes information leakage vs. legitimate feedback."
       },
       "non_independence_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of independence between training data and test kernels. The kernels could share patterns with HLS examples in the models' training data."
       },
       "leakage_detection_method": {
         "applies": true,
         "answer": false,
         "justification": "No leakage detection or prevention methods are used. No analysis of whether the models have memorized HLS patterns from training."
       }
     }
   },
   "claims": [
     {
       "claim": "LAAFD achieves 99.9% geomean performance compared to hand-tuned HLS baselines across 15 HPC kernels using GPT-5.",
       "evidence": "Table I shows per-kernel cycle counts for LAAFD vs manual baselines and ideal minimums. Section V.A computes the geomean. However, Section V.E reveals these are best-of-multiple-runs results.",
       "supported": "moderate"
     },
     {
       "claim": "LAAFD matches the performance of SODA, a state-of-the-art stencil HLS code generator, on 7 stencil kernels.",
       "evidence": "Table IV compares LAAFD-generated vs SODA-generated kernel latencies against ideal. LAAFD achieves comparable or slightly better cycle counts. Best-of-10 runs selection (Section V.E).",
       "supported": "moderate"
     },
     {
       "claim": "LAAFD generates more readable and less complex code than SODA (8.3x fewer LoC, 2.27x less cyclomatic complexity on average).",
       "evidence": "Table IV reports lines of code (LAAFD vs SODA), Table VI reports cyclomatic complexity ratios. These are objective metrics directly measured from the generated code.",
       "supported": "strong"
     },
     {
       "claim": "GPT-5 substantially outperforms o4-mini (52.5% geomean) and GPT-5-nano (32.7% geomean) for HLS optimization within LAAFD.",
       "evidence": "Section V.D and Figure 9 compare per-kernel performance across three models. GPT-5-nano and o4-mini fail on complex stencil kernels requiring advanced optimizations like perfect data reuse and shift buffers.",
       "supported": "moderate"
     },
     {
       "claim": "The total cost to translate and optimize all 15 kernels is approximately US$50.",
       "evidence": "Section VI states this cost figure but provides no breakdown by model, kernel, or run. Server infrastructure costs are explicitly excluded.",
       "supported": "weak"
     },
     {
       "claim": "LAAFD substantially lowers the expertise barrier to FPGA acceleration.",
       "evidence": "Inferred from cycle-count parity with hand-tuned baselines (Table I) and automated workflow description (Section IV). No direct measurement of expertise requirements or developer experience.",
       "supported": "weak"
     }
   ],
   "red_flags": [
     {
       "flag": "Best-of-N reporting inflates performance",
       "detail": "Section V.E explicitly states: 'we report for each kernel the best HLS design obtained across multiple executions.' For SODA kernels, only 1-2 of 10 runs produced optimal code. The 99.9% geomean headline represents cherry-picked best cases, not expected performance. No distribution or expected-case performance is reported."
     },
     {
       "flag": "No error bars despite acknowledged stochasticity",
       "detail": "The authors acknowledge 'different runs may yield different results even under identical settings' (Section V.E) yet report only single point estimates. The variance across runs could be large given that most runs produce 'functionally correct but suboptimal designs.'"
     },
     {
       "flag": "Custom baselines without independent verification",
       "detail": "The manually optimized baselines in Table I are the authors' own implementations. Their optimality is assumed but not independently verified. If the baselines are suboptimal, matching them is less impressive."
     },
     {
       "flag": "Readability claim without human evaluation",
       "detail": "The paper claims 'more readable kernels' and 'high quality, readable, and less complex' code based only on LoC and cyclomatic complexity metrics. No human readability assessment is conducted. Fewer lines does not necessarily mean more readable."
     },
     {
       "flag": "No code or data release",
       "detail": "The LAAFD system, agent prompts, kernels, test benches, and generated HLS code are not released, making independent verification impossible."
     },
     {
       "flag": "Resource overhead downplayed",
       "detail": "LAAFD uses substantially more FPGA resources than baselines (e.g., S3D: 584 BRAM vs 122 manual, S2D2: 90 BRAM vs 28 manual). This is noted but framed as secondary since the workflow 'was not instrumented to optimize resource utilization.' In practice, FPGA resource constraints are critical design considerations."
     }
   ],
   "cited_papers": [
     {
       "title": "A Review on Code Generation with LLMs: Application and Evaluation",
       "authors": ["J. Wang", "Y. Chen"],
       "year": 2023,
       "relevance": "Survey of LLM-based code generation covering application areas and evaluation methods."
     },
     {
       "title": "Test-Driven Development and LLM-based Code Generation",
       "authors": ["N. S. Mathews", "M. Nagappan"],
       "year": 2024,
       "doi": "10.1145/3691620.3695527",
       "relevance": "Evaluates test-driven approaches to LLM code generation, relevant to understanding feedback-based code improvement."
     },
     {
       "title": "LLM-Based Test-Driven Interactive Code Generation: User Study and Empirical Evaluation",
       "authors": ["S. Fakhoury", "A. Naik", "G. Sakkas", "S. Chakraborty", "S. K. Lahiri"],
       "year": 2024,
       "relevance": "Empirical evaluation of interactive LLM code generation with user studies, relevant to understanding agentic code workflows."
     },
     {
       "title": "A Survey on Code Generation with LLM-based Agents",
       "authors": ["Y. Dong", "X. Jiang", "J. Qian", "T. Wang", "K. Zhang", "Z. Jin", "G. Li"],
       "year": 2025,
       "arxiv_id": "2508.00083",
       "relevance": "Survey specifically covering agentic LLM code generation, directly relevant to LAAFD's approach."
     },
     {
       "title": "VeriGen: A Large Language Model for Verilog Code Generation",
       "authors": ["S. Thakur"],
       "year": 2024,
       "doi": "10.1145/3643681",
       "relevance": "Demonstrates fine-tuned LLMs for hardware description language generation, foundational work for LLM-based hardware design."
     },
     {
       "title": "RTLCoder: Fully Open-Source and Efficient LLM-Assisted RTL Code Generation Technique",
       "authors": ["S. Liu"],
       "year": 2025,
       "relevance": "Open-source LLM for RTL code generation that outperforms GPT-4, relevant as a baseline approach for hardware code generation."
     },
     {
       "title": "AutoChip: Automating HDL Generation Using LLM Feedback",
       "authors": ["S. Thakur", "J. Blocklove", "H. Pearce", "B. Tan", "S. Garg", "R. Karri"],
       "year": 2024,
       "arxiv_id": "2311.04887",
       "relevance": "Iterative LLM-based HDL generation using compilation feedback, a precursor to LAAFD's feedback-driven approach."
     },
     {
       "title": "VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planning and Abstract Syntax Tree (AST)-based Waveform Tracing Tool",
       "authors": ["C.-T. Ho", "H. Ren", "B. Khailany"],
       "year": 2025,
       "arxiv_id": "2408.08927",
       "relevance": "Multi-agent system for Verilog generation achieving 94.2% pass rate, demonstrating agentic approaches for hardware code."
     },
     {
       "title": "HLSPilot: LLM-based High-Level Synthesis",
       "authors": ["C. Xiong", "C. Liu", "H. Li", "X. Li"],
       "year": 2025,
       "doi": "10.1145/3676536.3676781",
       "relevance": "Most directly comparable prior work: LLM-based HLS optimization. LAAFD claims to go further in optimization depth and kernel complexity."
     },
     {
       "title": "C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap",
       "authors": ["L. Collini", "S. Garg", "R. Karri"],
       "year": 2025,
       "doi": "10.1145/3734524",
       "relevance": "C-to-HLS translation using LLMs with HLS report feedback, closest related work to LAAFD's methodology."
     },
     {
       "title": "Are LLMs Any Good for High-Level Synthesis?",
       "authors": ["Y. Liao", "T. Adegbija", "R. Lysecky"],
       "year": 2025,
       "doi": "10.1145/3676536.3699507",
       "relevance": "Survey of LLM capabilities for HLS, providing context for the challenges LAAFD addresses."
     }
   ]
 }