Pith. sign in

REVIEW 4 major objections 7 minor 2 cited by

TrojanGYM: A Detector-in-the-Loop LLM for Adaptive RTL Hardware Trojan Insertion

T0 review · 4 major / 7 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that closing the detection loop—feeding GNN verdicts back into an LLM that re-inserts hardware Trojans—systematically produces diverse, functionally correct Trojans that evade modern GNN detectors up to 83.33% of the time,

desk verdict Closed-loop HT generation is a real idea, but the 'functionally correct' claim rests on compile checks only, and the 83.33% evasion number is an oracle-selected upper bound. read the letter →

arxiv 2601.17178 v2 pith:P6JDLBXR submitted 2026-01-23 cs.CR cs.AIcs.AR

Saideep Sreekumar , Zeng Wang , Akashdeep Saha , Weihua Xiao , Minghao Shao , Muhammad Shafique , Ozgur Sinanoglu , Ramesh Karri
show 1 more author
Johann Knechtel
This is my paper · ORCID
classification cs.CRcs.AIcs.AR
keywords hardwareTrojanLLMRTLGNNdetectoradversarialrefinementbenchmarkgenerationsecurityevasion
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper aims to show that hardware Trojans are best understood as a moving target: rather than generating a fixed set of malicious circuits and testing detectors once, an attacker can use an LLM to propose, compile, and refine Trojans in a loop, guided by a GNN-based detector that says 'detected' or 'clean'. The authors claim this detector-in-the-loop process produces diverse, functionally correct Trojans that reach up to 83.33% evasion against modern GNN detectors, revealing robustness gaps that static TrustHub-style benchmarks hide. They also introduce an improved detector, Robust-GNN4TJ, that lifts detection rates from 0% to 60% on the hardest generated benchmarks. A sympathetic reader would care because it reframes benchmarking: attack and defense should co-evolve rather than be measured in isolation.

What carries the argument

The machinery is a gated feedback loop: given high-level Trojan specifications, LLM agents analyze the target RTL, select insertion points, generate modified Verilog, then pass through a compile-and-repair smoke test; surviving designs are scored by a GNN-based detector, and detected designs are returned to the LLM with instructions to minimize changes to the data-flow graph and syntax tree. The loop runs up to four refinement iterations per Trojan. The paper also introduces Robust-GNN4TJ, an ensemble of four graph-neural-network detectors—one per Trojan type—trained on 884 clean designs and 3,536 LLM-generated infected designs, which replaces fragile parsing with a lightweight parser and st

What would settle it

Run cycle-accurate simulation or formal equivalence checking on the generated Trojan-infected RTL against the golden design under normal inputs; finding any output mismatch outside the trigger condition would falsify the functionality-preservation claim, and a sharp drop in evasion when a detector with temporal or functional features is used would show the gap is structural-GNN-specific.

Watch

Extended reading notes

Core claim

The central claim is that closing the loop between HT generation and detection—feeding detection results back into an LLM that re-inserts the Trojan—makes evasion easier and more systematic than one-shot generation. On SRAM, AES-128, and UART designs with GPT-4, Gemini-2.5Pro, and LLaMA-3.3-70B, the authors report an aggregate 61.11% evasion rate across 36 insertion combinations, rising to 83.33% with optimal per-design model selection. The improved detector Robust-GNN4TJ—which uses a lightweight parser, a larger training set, a learning-rate scheduler, and a four-model ensemble—raises detection from 0% to 60% on the most challenging generated benchmarks, yet still leaves a large evasion spa

Load-bearing premise

The claim that generated Trojans preserve normal functionality rests on compile-success and prompt-level constraints rather than on simulation, formal equivalence, or testbench-based verification.

Editorial extensions

If this is right

  • If a detector's feedback is part of the attack loop, static benchmark evaluation overestimates detector robustness; detection results must be reported under adaptive attack.
  • Generated benchmarks like the 36-design corpus can serve as stress tests for next-generation detectors, with metadata on refinement history and detector scores.
  • The failure of joint training versus per-HT-type ensemble suggests that detectors should be built per attack class rather than one model for all Trojans.
  • Evasion success depends on Trojan type: performance-degradation Trojans evade more often because they can be realized as auxiliary logic with minimal interference, while information-leakage and denial-of-service Trojans alter control paths and are more detectable.
  • The 'optimal' 83.33% evasion across models indicates that multiple LLMs have complementary strengths; an attacker with access to a portfolio of LLMs is stronger than any single model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Implicitly, the framework treats compilation as the only correctness gate; if functional simulation or formal equivalence checking were added, many 'functionally correct' claims might shrink, especially for subtle functional-perturbation Trojans.
  • The robustness gap may be detector-specific: a detector that uses temporal or functional features (e.g., activation rarity or simulation traces) rather than static graph structure could catch these Trojans, so the 83.33% evasion should not be read as a general claim about all detection approaches.
  • The use of synthetic training data from LLM-generated Trojans (3,536 samples) raises a distribution question: detectors trained on LLM-generated attacks may overfit to LLM stylistic patterns, so continued co-evolution is needed to avoid a new form of benchmark overfitting.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper introduces TrojanGYM, an agentic LLM-based framework that automatically generates RTL hardware Trojans in a closed loop with a GNN-based detector. Three LLMs (GPT-4, Gemini-2.5Pro, LLaMA-3.3-70B) propose and iteratively refine Verilog modifications based on syntactic compile errors and detector feedback. The authors also propose Robust-GNN4TJ, a re-implementation of GNN4TJ with improved graph extraction, a larger training set, and an ensemble of four HT-type-specific models. They evaluate on SRAM, AES-128, and UART, reporting that Robust-GNN4TJ detects up to 60% of GHOST-generated HTs, and that TrojanGYM-generated HTs achieve up to 83.33% evasion against Robust-GNN4TJ. The paper claims the generated HTs are diverse and functionally correct.

Significance. The paper addresses an important problem: benchmarking hardware Trojan detectors with adaptively generated, LLM-produced Trojans. The detector-in-the-loop idea is timely, and the construction of a larger and more diverse training dataset for GNN-based HT detection is a useful contribution. If the functional-correctness claim can be substantiated and the evaluation made less circular, the framework would provide a valuable stress-test for HT detectors. The paper is relatively candid about the oracle-style selection for the headline evasion number and promises artifact release. However, the central validation gap—the absence of functional equivalence checking—currently limits the conclusions that can be drawn from the reported results.

major comments (4)
  1. [Section IV-C, IV-E, VII] The claim that generated HTs are 'functionally correct' is not supported by the methodology. Section IV-C describes only compilation smoke tests and up to four LLM repair iterations; no simulation, formal equivalence, or testbench-based functional checks are described. Section IV-E defines a successful run as one that 'passes syntactic checks,' and Section VII's assertion of a 'gated validation loop enforces constraint-aware equivalence' is not backed by any concrete method. Compilation success does not imply preservation of normal functionality: subtle changes to control logic, state initialization, or combinational paths can alter behavior even when the trigger is inactive. This is load-bearing because the 83.33% evasion rate may partly reflect detectors failing on malformed designs rather than on stealthy, functionally correct Trojans. The authors must add simulation/formal equivalenc
  2. [Section VI-B] The headline 83.33% evasion rate is an oracle-selected upper bound: it is obtained by 'selecting the best-performing model per design' across the three LLMs (Section VI-B). This is a post-hoc optimum, not the performance of a single adversary or of TrojanGYM with a fixed configuration. The abstract's 'up to' phrasing is technically correct, but presenting this number as the central result without clearly separating it from the per-LLM 61.11% average is misleading. The authors should either restructure the claims around the non-oracle numbers or explicitly justify why oracle selection is a meaningful metric for the paper's stated contribution of 'systematically' producing evasive HTs.
  3. [Section IV-D and VI-B] The evaluation is partly circular: Robust-GNN4TJ is used both as the feedback mechanism inside the generation loop (Section IV-D) and as the benchmark on which the final HTs are evaluated (Section VI-B). The reported evasion rates therefore measure the adversary's ability to exploit oracle access to that specific detector, not an independent estimate of detector robustness. The paper does frame this as an adaptive co-evolution, which is legitimate, but the conclusion that the results 'reveal robustness gaps' in modern GNN detectors should be supported by an evaluation against a held-out detector not used during generation (e.g., the original GNN4TJ, or another GNN trained independently). At minimum, the limitation must be discussed explicitly in the conclusion and abstract.
  4. [Section V and VI] All reported results appear to come from single runs. LLM-generated RTL is stochastic, and the outcomes in Table III (detected/evaded/syntax error) are likely to vary across independent runs with the same configuration. The quantitative claims (61.11% and 83.33% evasion, detection trends in Fig. 4) are presented without error bars, confidence intervals, or multiple-seed experiments. The authors should repeat the pipeline several times per (LLM, design, HT type) configuration and report the distribution of outcomes, or otherwise justify why a single run per cell is representative.
minor comments (7)
  1. [Section IV-D] The sentence 'The below list contains representative prompts that help illustrate the process of syntactic checking and feedback to the LLM in case of an error.' appears twice, once before and once after the prompt list. Remove the duplicate.
  2. [Section V] In the 'Robust-GNN4TJ Setup' paragraph, 'we introduceRobust-GNN4TJ' is missing a space after 'introduce'.
  3. [Table III] The legend for Table III is confusing: 'N/A : No further attempt (Evaded); Evade; Non-evade.' The symbols ✓ and × are used in the table body; please use a cleaner legend, e.g., '✓: detected, ×: evaded, SE: syntax error, N/A: no further attempt (already evaded).'
  4. [Fig. 5] The heatmaps use 'NA' to indicate missing variants (e.g., absent A4), but this is only clear from the caption's parenthetical remark. Add an explicit note in the figure itself or the caption that 'NA' denotes non-existent refinement iteration.
  5. [Abstract and Section I] The line 'Index Terms—hardware Trojans, hardware security, large language models, design automation, cybersecurity.' appears inside the abstract in the full text. Move it to a proper index-term section below the abstract.
  6. [References] References [15] and [36] are the same paper (VeriGen). Consolidate to a single reference to avoid duplication.
  7. [Section VI-A] The computation of 'overall detection accuracy of 50%' and 'up to 60%' in the ensemble setting is not fully specified. State the denominator (e.g., across which designs and HT types) and clarify whether the 'excluding HT1' result excludes all HT1 samples from both training and evaluation.

Circularity Check

1 steps flagged · score 4.0 of 10

The headline evasion metric is an adaptive-fit statistic because the same detector is both the generation oracle and the evaluation benchmark; functional-correctness is asserted from syntax-only checks, but no formal derivation is circular.

  1. fitted input called prediction [Section IV-D (GNN-based Detection and Adversarial Refinement) and Section VI-B (Iterative LLM-Based Trojan Generation under Detector Feedback)]
    "For each candidate, the detector outputs HT probability. Designs with scores below the threshold are considered stealthy with respect to the current detector and are included in the final corpus. Designs above the threshold are classified as detected and trigger an adversarial refinement loop:"

    Stealthiness/evasion is defined by the same detector that provides feedback during generation. The reported 'evasion' rate is the fraction of refinement loops that found a below-threshold design, i.e., a fit-success statistic with respect to the very model being used to steer the LLM. Section VI-B then treats the resulting decrease in detection accuracy as an empirical finding about detector robustness, but this decrease is by construction: the loop is explicitly instructed to minimize DFG/AST changes and evade HW2VEC. The 83.33% figure is further amplified by oracle-style selection over three LLMs, making it an upper bound of an adaptive attack, not an independent estimate of detector weakness.

full rationale

TrojanGYM's formal derivation chain is not circular in the usual sense: there are no equations derived from their own outputs, no load-bearing self-citation chain, and the Robust-GNN4TJ improvement is partly validated on GHOST-generated, feedback-free HTs, which provides independent grounding. The main circularity-adjacent element is that the same detector is embedded in the generation loop and then used as the benchmark; the reported evasion rates are therefore adaptive-attack outcomes rather than independent robustness measurements. The paper discloses this design in Section IV-D, but the abstract's phrasing ('evasion rates against modern GNN-based detectors') overstates the independence of the metric. Separately, the claim that generated HTs are 'functionally correct' is not established: Section IV-C describes only compilation smoke tests and repair rounds, with no simulation, formal equivalence, or testbench-based functional check, and Section VII's reference to a 'gated validation loop enforces constraint-aware equivalence' is not backed by any described equivalence method. That is an unvalidated premise and a correctness risk, but it is not itself a circularity. Overall, the core generation framework has independent content, but the headline evasion number partially reduces to the loop's own acceptance criterion, warranting a moderate score of 4.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The central claims rest on engineering choices (iteration caps, ensemble size, training set, threshold) and on three unproven domain assumptions: compilation implies correctness, LLM prompts preserve functionality, and graph embeddings capture maliciousness. There are no new physical or mathematical entities.

free parameters (4)
  • Maximum refinement iterations = 4
    Both syntax repair and adversarial refinement allow up to four LLM attempts (Section IV-C, IV-D); evasion rates and 'N/A' outcomes depend on this cap.
  • Detector ensemble size and fusion rule = 4 models, OR fusion
    Robust-GNN4TJ uses four HT-type-specific GNN models and flags a design if any predicts Trojan (Section V). This choice was made after observing single-model failures, and it directly sets the detection/evasion numbers.
  • Training data size = 884 clean VeriGen designs + 3,536 Trojan designs
    Expanded training set was selected to improve generalization (Section V); the sample size and random selection procedure affect detector performance but are not justified or varied.
  • Detection threshold = not stated (implicitly 0.5)
    The detector's clean/Trojan decision boundary is never specified; all evasion/detection outcomes depend on it.
assumptions (6)
  • ad hoc to paper Syntactic compilation success is a sufficient gate for functional correctness
    Section IV-C validates only Verilog compilation; the paper's claims of 'functionally correct' HTs and 'constraint-aware equivalence' (Section VII) rely on this unverified proxy.
  • domain assumption LLMs can implement HT plans in synthesizable RTL while preserving intended behavior
    Section IV-B assumes the LLM agent will follow design guidelines (reset logic, no initial blocks, proper else cases) and produce functionally preserving Trojans; no proof or systematic test is given.
  • domain assumption Graph structure and t-SNE separability capture Trojan detectability
    The framework uses DFG-level GNN embeddings and t-SNE visual inspection (Section VI-A) as the basis for detection and for explaining HT1's low detectability.
  • domain assumption Detector feedback in the form of logs can be interpreted by LLMs to produce stealthier modifications
    Section IV-D feeds detection logs to the LLM and assumes it can minimize changes to DFG/AST while keeping the Trojan functional.
  • domain assumption Attacker has read-write access to RTL after design
    Section III defines the threat model; it is standard but not externally validated.
  • domain assumption LLM outputs are diverse and non-deterministic enough to represent an attack distribution
    The evaluation treats one generation per configuration as representative (Tables II, III), though no seeds or repeats are reported.

how reviews work

0 comments
Cite this review

Pith. "Pith review of TrojanGYM: A Detector-in-the-Loop LLM for Adaptive RTL Hardware Trojan Insertion." pith.science (2026). https://pith.science/paper/P6JDLBXR

@misc{pith2026260117178,
  author       = {Pith},
  title        = {Pith review of: TrojanGYM: A Detector-in-the-Loop LLM for Adaptive RTL Hardware Trojan Insertion},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/P6JDLBXR}},
  note         = {Machine review of arXiv:2601.17178}
}
read the original abstract

Hardware Trojans (HTs) remain a critical threat because learning-based detectors often overfit to narrow trigger/payload patterns and small, stylized benchmarks. We introduce TrojanGYM, an agentic, LLM-driven framework that automatically curates HT insertions to expose detector blind spots while preserving design correctness. Given high-level HT specifications, a suite of cooperating LLM agents (instantiated with GPT-4, LLaMA-3.3-70B, and Gemini-2.5Pro) proposes and refines RTL modifications that realize diverse triggers and payloads without impacting normal functionality. TrojanGYM implements a feedback-driven benchmark generation loop co-designed with HT detectors, in which constraint-aware syntactic checking and GNN-based HT detectors provide feedback that iteratively refines HT specifications and insertion strategies to better surface detector blind spots. We further propose Robust-GNN4TJ, a new implementation of the GNN4TJ with improved graph extraction, training robustness, and prediction reliability, especially on LLM-generated HT designs. On the most challenging TrojanGYM-generated benchmarks, Robust-GNN4TJ raises HT detection rates from 0% to 60% relative to a prior GNN-based detector. We instantiate TrojanGYM on SRAM, AES-128, and UART designs at RTL level, and show that it systematically produces diverse, functionally correct HTs that reach up to 83.33% evasion rates against modern GNN-based detectors, revealing robustness gaps that are not apparent when these detectors are evaluated solely on existing TrustHub-style benchmarks. Post peer-review, we will release all codes and artifacts.

Figures

Figures reproduced from arXiv: 2601.17178 by the authors.

Figure 1
Figure 1. The HT insertion framework. their evolution. It explicitly embeds both compilation tooling and an HT detector within the generation loop. The LLM therefore operates in an environment that provides structured, tool-driven feedback on syntactic validity and detectability, and is required to refine its designs iteratively. The pipeline comprises four main stages: (i) provision of the target RTL design and HT property s… view at source ↗
Figure 2
Figure 2. t-SNE visualization of graph embeddings learned by Robust-GNN4TJ [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. t-SNE visualization of graph embeddings learned by Robust-GNN4TJ [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Detection and evasion performance of Robust-GNN4TJ under iterative, [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Edge-level structural similarity heatmaps between the original RTL design (ORI) and iteratively generated variants (A1–A4) across different LLMs [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Case study of HT1 inserted into the SRAM RTL design by LLaMA-3.3-70B [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. LLMs for Secure Hardware Design and Related Problems: Opportunities and Challenges

    cs.CR 2026-05 unverdicted novelty 3.0 of 10

    LLMs enable RTL code generation and vulnerability analysis in hardware design but introduce data contamination and adversarial risks that require red-teaming and dynamic benchmarking.

  2. Hardware Design and Security in the Era of Chiplets and LLMs

    cs.CR 2026-08 accept novelty 2.0 of 10

    A survey uniting chiplet-hardware security and LLM-driven EDA security that identifies a missing bridge: LLM-based security tools are not yet tailored to 2.5D/3D chiplet systems.

Reference graph

Works this paper leans on

36 extracted references · 1 canonical work pages · cited by 2 Pith papers

  1. [1]

    Hardware trojan detection using path delay fingerprint,

    Y . Jin and Y . Makris, “Hardware trojan detection using path delay fingerprint,” inProceedings of the IEEE International Workshop on Hardware-Oriented Security and Trust (HOST), 2008, pp. 51–57

    2008

  2. [2]

    Scalable detection of hardware trojans using ATPG-based activation of rare events,

    A. Jayasena and P. Mishra, “Scalable detection of hardware trojans using ATPG-based activation of rare events,”IEEE Transactions on Computer- Aided Design of Integrated Circuits and Systems, vol. 42, no. 12, pp. 4450–4462, 2023

    2023

  3. [3]

    Gnn4tj: Graph neural networks for hardware trojan detection at register transfer level,

    R. Yasaei, S.-Y . Yu, and M. A. Al Faruque, “Gnn4tj: Graph neural networks for hardware trojan detection at register transfer level,” in2021 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2021, pp. 1504–1509

    2021

  4. [4]

    HW2VEC: A graph learning tool for automating hardware security,

    S. Yu, R. Yasaei, Q. Zhou, T. Nguyen, and M. A. Al Faruque, “HW2VEC: A graph learning tool for automating hardware security,” in2021 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2021, pp. 13–23

    2021

  5. [5]

    Graph neural networks for integrated circuit design, reliability, and security: Survey and tool,

    Z. El Sayed, Z. Wang, H. Selmani, J. Knechtel, O. Sinanoglu, and L. Al- rahis, “Graph neural networks for integrated circuit design, reliability, and security: Survey and tool,”ACM Computing Surveys, vol. 58, no. 4, pp. 1–44, 2025

    2025

  6. [6]

    Trust-hub chip-level trojan benchmarks,

    “Trust-hub chip-level trojan benchmarks,” https://trust- hub.org/#/benchmarks/chip-level-trojan

  7. [7]

    Sand: A self-supervised and adaptive nas-driven framework for hardware trojan detection,

    Z. Pan, Z. Shu, L. Nguyen, and A. Alemayoh, “Sand: A self-supervised and adaptive nas-driven framework for hardware trojan detection,”arXiv preprint arXiv:2510.23643, 2025

    arXiv 2025

  8. [8]

    Attrition: Attacking static hardware trojan detection techniques using reinforcement learn- ing,

    V . Gohil, H. Guo, S. Patnaik, and J. Rajendran, “Attrition: Attacking static hardware trojan detection techniques using reinforcement learn- ing,” inProceedings of the 2022 ACM SIGSAC conference on computer and communications security, 2022, pp. 1275–1289

    2022

Show all 36 references
  1. [9]

    Trojanforge: Adversarial hardware trojan examples with reinforcement learning,

    A. Sarihi, P. Jamieson, A. Patooghy, and A. Badawy, “Trojanforge: Adversarial hardware trojan examples with reinforcement learning,” arXiv preprint arXiv:2405.15184, 2024

    2024 arXiv

  2. [10]

    Netdetox: Adversarial and efficient evasion of hardware- security gnns via rl-llm orchestration,

    Z. Wang, M. Shao, A. Saha, R. Karri, J. Knechtel, M. Shafique, and O. Sinanoglu, “Netdetox: Adversarial and efficient evasion of hardware- security gnns via rl-llm orchestration,”arXiv preprint arXiv:2512.00119, 2025

    2025

  3. [11]

    Auto- matic hardware trojan insertion using machine learning,

    J. Cruz, P. Gaikwad, A. Nair, P. Chakraborty, and S. Bhunia, “Auto- matic hardware trojan insertion using machine learning,”arXiv preprint arXiv:2204.08580, 2022

    2022 arXiv

  4. [12]

    An automated configurable trojan insertion framework for dynamic trust benchmarks,

    J. Cruz, Y . Huang, P. Mishra, and S. Bhunia, “An automated configurable trojan insertion framework for dynamic trust benchmarks,” in2018 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2018, pp. 1598–1603

    2018

  5. [13]

    Taint: Tool for automated insertion of trojans,

    V . Jyothi, P. Krishnamurthy, F. Khorrami, and R. Karri, “Taint: Tool for automated insertion of trojans,” in2017 IEEE International Conference on Computer Design (ICCD). IEEE, 2017, pp. 545–548

    2017

  6. [14]

    Feint: Automated framework for efficient insertion of templates/trojans into fpgas,

    V . R. Surabhi, R. Sadhukhan, M. Raz, H. Pearce, P. Krishnamurthy, J. Trujillo, R. Karri, and F. Khorrami, “Feint: Automated framework for efficient insertion of templates/trojans into fpgas,”Information, vol. 15, no. 7, p. 395, 2024

    2024

  7. [15]

    Verigen: A large language model for verilog code generation,

    S. Thakur, B. Ahmad, H. Pearce, B. Tan, B. Dolan-Gavitt, R. Karri, and S. Garg, “Verigen: A large language model for verilog code generation,” ACM Transactions on Design Automation of Electronic Systems, vol. 29, no. 3, pp. 1–31, 2024

    2024

  8. [16]

    Llms and the future of chip design: Unveiling security risks and building trust,

    Z. Wang, L. Alrahis, L. Mankali, J. Knechtel, and O. Sinanoglu, “Llms and the future of chip design: Unveiling security risks and building trust,” in2024 IEEE Computer Society Annual Symposium on VLSI (ISVLSI). IEEE, 2024, pp. 385–390

    2024

  9. [17]

    Lockforge: Automating paper-to-code for logic locking with multi- agent reasoning llms,

    A. Saha, Z. Wang, P. B. Roy, J. Knechtel, O. Sinanoglu, and R. Karri, “Lockforge: Automating paper-to-code for logic locking with multi- agent reasoning llms,”arXiv preprint arXiv:2511.18531, 2025

    2025

  10. [18]

    Chip-chat: Chal- lenges and opportunities in conversational hardware design,

    J. Blocklove, S. Garg, R. Karri, and H. Pearce, “Chip-chat: Chal- lenges and opportunities in conversational hardware design,” in2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD). IEEE, 2023, pp. 1–6

    2023

  11. [19]

    Deeprtl2: A versatile model for rtl-related tasks,

    Y . Liu, H. Zhang, Y . Zhou, Z. Shi, C. Xu, and Q. Xu, “Deeprtl2: A versatile model for rtl-related tasks,”arXiv preprint arXiv:2506.15697, 2025

    2025 arXiv

  12. [20]

    Vericontaminated: Assessing llm- driven verilog coding for data contamination,

    Z. Wang, M. Shao, J. Bhandari, L. Mankali, R. Karri, O. Sinanoglu, M. Shafique, and J. Knechtel, “Vericontaminated: Assessing llm- driven verilog coding for data contamination,”arXiv preprint arXiv:2503.13572, 2025

    2025 arXiv

  13. [21]

    Gllamor: Graph-based logic locking by large language models for enhanced robustness,

    A. Saha, P. B. Roy, J. Knechtel, R. Karri, O. Sinanoglu, and L. Alrahis, “Gllamor: Graph-based logic locking by large language models for enhanced robustness,” in2025 IEEE 43rd VLSI Test Symposium (VTS). IEEE, 2025, pp. 1–5

    2025

  14. [22]

    Verileaky: Navigating ip protection vs utility in fine-tuning for llm-driven verilog coding,

    Z. Wang, M. Shao, M. Nabeel, P. B. Roy, L. Mankali, J. Bhandari, R. Karri, O. Sinanoglu, M. Shafique, and J. Knechtel, “Verileaky: Navigating ip protection vs utility in fine-tuning for llm-driven verilog coding,”arXiv preprint arXiv:2503.13116, 2025

    2025 arXiv

  15. [23]

    SENTAUR: Security enhanced trojan assessment using LLMs against undesirable revisions,

    J. Bhandari, R. Sadhukhan, P. Krishnamurthy, F. Khorrami, and R. Karri, “SENTAUR: Security enhanced trojan assessment using LLMs against undesirable revisions,”CoRR, vol. abs/2407.12352, 2024. [Online]. Available: https://arxiv.org/abs/2407.12352

    2024 arXiv

  16. [24]

    Hardware trojan dataset of RISC-V and Web3 generated with ChatGPT-4,

    V . T. Hayashi and W. V . Ruggiero, “Hardware trojan dataset of RISC-V and Web3 generated with ChatGPT-4,”Data, vol. 9, no. 6, p. 82, 2024. [Online]. Available: https://doi.org/10.3390/data9060082

    2024 doi

  17. [25]

    Unleashing ghost: An llm-powered framework for automated hardware trojan design,

    M. O. Faruque, P. Jamieson, A. Patooghy, and A.-H. A. Badawy, “Unleashing ghost: An llm-powered framework for automated hardware trojan design,”Electronics, vol. 14, no. 23, p. 4745, 2025

    2025

  18. [26]

    Dtjrtl: A configurable framework for automated hardware trojan insertion at rtl,

    R. Dai, Z. Liu, O. Arias, X. Guo, and T. Yavuz, “Dtjrtl: A configurable framework for automated hardware trojan insertion at rtl,” inProceed- ings of the Great Lakes Symposium on VLSI 2024, 2024, pp. 465–470

    2024

  19. [27]

    Trojan playground: a reinforcement learning framework for hardware trojan insertion and detection,

    A. Sarihi, A. Patooghy, P. Jamieson, and A.-H. A. Badawy, “Trojan playground: a reinforcement learning framework for hardware trojan insertion and detection,”arXiv preprint arXiv:2305.09592, 2023

    2023 arXiv

  20. [28]

    {AttackGNN}:{Red-Teaming}{GNNs}in hardware security using reinforcement learning,

    V . Gohil, S. Patnaik, D. Kalathil, and J. Rajendran, “{AttackGNN}:{Red-Teaming}{GNNs}in hardware security using reinforcement learning,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 73–90

    2024

  21. [29]

    Trojansaint: Gate-level netlist sampling-based inductive learning for hardware trojan detection,

    H. Lashen, L. Alrahis, J. Knechtel, and O. Sinanoglu, “Trojansaint: Gate-level netlist sampling-based inductive learning for hardware trojan detection,” in2023 IEEE International Symposium on Circuits and Systems (ISCAS). IEEE, 2023, pp. 1–5

    2023

  22. [30]

    Rtl-breaker: Assessing the security of llms against backdoor attacks on hdl code generation,

    L. L. Mankali, J. Bhandari, M. Alam, R. Karri, M. Maniatakos, O. Sinanoglu, and J. Knechtel, “Rtl-breaker: Assessing the security of llms against backdoor attacks on hdl code generation,” in2025 Design, Automation & Test in Europe Conference (DATE). IEEE, 2025, pp. 1–7

    2025

  23. [31]

    Salad: Systematic as- sessment of machine unlearing on llm-aided hardware design,

    Z. Wang, M. Shao, R. Karn, J. Bhandari, L. Mankali, R. Karri, O. Sinanoglu, M. Shafique, and J. Knechtel, “Salad: Systematic as- sessment of machine unlearing on llm-aided hardware design,”arXiv preprint arXiv:2506.02089, 2025

    2025

  24. [32]

    Tro- janwhisper: Evaluating pre-trained llms to detect and localize hardware trojans,

    M. O. Faruque, P. Jamieson, A. Patooghy, and A.-H. A. Badawy, “Tro- janwhisper: Evaluating pre-trained llms to detect and localize hardware trojans,”arXiv preprint arXiv:2412.07636, 2024

    2024 arXiv

  25. [33]

    Netlam: An automated llm framework to generate and evaluate stealthy hardware trojans,

    T. S. Sarkar, K. Arya, S. Chowdhury, U. Mandal, S. Shukla, S. Bhat- tacharya, and D. Mukhopadhyay, “Netlam: An automated llm framework to generate and evaluate stealthy hardware trojans,” inInternational Conference on Applied Cryptography and Network Security. Springer, 2025, pp. 3–21

    2025

  26. [34]

    Latent: Leveraging automated test pattern generation for hardware trojan detection,

    S. Paria, P. Gaikwad, A. Dasgupta, and S. Bhunia, “Latent: Leveraging automated test pattern generation for hardware trojan detection,” in2024 IEEE 33rd Asian Test Symposium (ATS). IEEE, 2024, pp. 1–6

    2024

  27. [35]

    Trojanloc: Llm-based framework for rtl trojan localization,

    W. Xiao, Z. Wang, M. Shao, R. V . Hemadri, O. Sinanoglu, M. Shafique, J. Knechtel, S. Garg, and R. Karri, “Trojanloc: Llm-based framework for rtl trojan localization,”arXiv preprint arXiv:2512.00591, 2025

    2025

  28. [36]

    Verigen: A large language model for verilog code generation,

    S. Thakur, B. Ahmad, H. Pearce, B. Tan, B. Dolan-Gavitt, R. Karri, and S. Garg, “Verigen: A large language model for verilog code generation,”ACM Trans. Des. Autom. Electron. Syst., vol. 29, no. 3, Apr. 2024. [Online]. Available: https://doi.org/10.1145/3643681

    2024 doi

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.