Pith. sign in

REVIEW 5 major objections 6 minor 81 references

SV-LLM: An Agentic Approach for SoC Security Verification using Large Language Models

T0 review · 5 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read The paper claims that a six-agent LLM framework can automate the full SoC security verification workflow, from asset identification through simulation-based bug validation.

desk verdict A genuine, well-built multi-agent system for SoC security verification, but the headline accuracy numbers rest on undisclosed datasets and a validation loop that measures the LLM against its own expectations. read the letter →

arxiv 2506.20415 v1 pith:GSL4CE7O submitted 2025-06-25 cs.CR cs.AIcs.MA

Dipayan Saha , Shams Tarek , Hasan Al Shaikh , Khan Thamid Hasan , Pavan Sai Nalluri , Md. Ajoad Hasan , Nashmin Alam , Jingbo Zhou
show 3 more authors
Sujan Kumar Saha Mark Tehranipoor Farimah Farahmandi
This is my paper
classification cs.CRcs.AIcs.MA
keywords HardwareSecurityandTrustVerificationLargeLanguageModelAgenticAIAssetIdentificationPropertyGenerationTestbenchBugDetection
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

SV-LLM is a multi-agent assistant for system-on-chip security verification, built from six specialized LLM agents that cover security Q&A, asset identification, threat modeling and test plans, vulnerability detection, property and assertion generation, and simulation-based bug validation. The paper's claim is that decomposing the verification workflow into cooperating, purpose-tuned agents makes LLMs genuinely useful for hardware security, where monolithic prompting has failed. Its headline evidence: a fine-tuned open-source detection model reaches 84.8% vulnerability detection accuracy versus 42.5% for the same model before fine-tuning, and the agentic bug-validation pipeline produces bug-validated testbenches at 82-89% across three proprietary backends versus 18-43% for zero-shot prompting. A retrieval-augmented chat agent also answers a hardware-fuzzing query without the fabricated tools that a general-purpose chatbot produced. If these results hold, the framework would reduce the manual expertise currently required to translate natural-language security requirements into assets, threats, properties, and testbenches, and would let security checks run earlier in the design cycle.

What carries the argument

The object that carries the argument is the supervisor-orchestrator-agent pipeline: the Supervisor interprets the user query, validates and completes missing context, assigns an agent, and generates a task plan; the Orchestrator executes the plan, delegates to sub-agents, reroutes outputs, and initiates corrective action on failure; and the Agent Layer houses the six specialists. The vulnerability detection result is carried by parameter-efficient fine-tuning of a small open-source instruct model on a structured prompt-response dataset of RTL modules paired with vulnerability-focused queries and security annotations. The bug-validation result is carried by a three-stage loop: scenario generation with an LLM critic, testbench generation with syntax-check feedback, and a validation sub-agent that compares simulated signals against an expected region of interest. The property-generation result is carried by a CWE-mapping stage that intersects structural and threat-derived CWE lists before generating and self-refining SystemVerilog assertions.

What would settle it

Run the fine-tuned vulnerability detector and the agentic bug-validation pipeline on a new, publicly released benchmark of vulnerable RTL designs whose vulnerability classes were held out of fine-tuning; if detection accuracy and bug-validated testbench rates fall toward the zero-shot baselines (about 42% and 18-43%), the claim that the framework materially improves security verification is refuted.

Watch

Extended reading notes

Core claim

SV-LLM claims that the full SoC security verification pipeline can be automated by a team of specialized LLM agents coordinated by supervisor and orchestrator layers, rather than by a single monolithic prompt. Each agent is assigned one stage of the workflow, and each is tuned with a suitable learning paradigm: in-context examples for asset identification, retrieval-augmented generation for security Q&A, fine-tuning for vulnerability detection, and iterative scenario, testbench, and validation loops for bug confirmation. On the paper's measurements, the fine-tuned open-source detection agent reaches 84.8% vulnerability detection accuracy against 42.5% for the same model without fine-tuning, while the agentic bug-validation pipeline generates bug-validated testbenches for 82-89% of cases depending on the LLM backend, versus 18-43% for zero-shot prompting. The authors present this as evidence that task decomposition and iterative refinement, not raw model scale, are what make LLMs practical for hardware security verification.

Load-bearing premise

The headline numbers rest on benchmark datasets that the paper does not describe; if those sets are small, easy, or overlap the fine-tuning corpus, the measured accuracy gains will not generalize to real SoC designs.

Editorial extensions

If this is right

  • Verification teams could replace hand-written security assets, threat models, test plans, properties, and testbenches with reviewed outputs from one tool, shifting effort from creation to validation.
  • Fine-tuned open-source models at 84.8% detection accuracy give a deployable alternative to closed APIs for security-sensitive RTL, since the design does not have to leave the local compute environment.
  • The bug-validation pipeline's 82-89% validated-testbench rate implies that most reported vulnerabilities can be demonstrated in simulation before tape-out, which should cut false alarms in downstream security sign-off.
  • Structured outputs (JSON asset lists, syntactically checked .sva files, executable testbenches) mean the framework can be inserted into existing formal and simulation flows without changing the toolchain.

Reading between the lines

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

  • If the reported gains hold on an independent benchmark, the same supervisor-orchestrator pattern is likely to transfer to other hardware security tasks such as hardware Trojan localization or side-channel leakage assessment, because the framework's task-specific part is confined to the agent layer.
  • The large jump from zero-shot to agentic bug validation suggests most of the improvement comes from the iterative scenario-testbench-validation loop rather than from model choice; a stage-by-stage ablation would identify which step contributes the gain.
  • Because the validation oracle is an LLM-defined region of interest derived from the bug description, the framework will confidently confirm a bug that was mischaracterized in the first place; checking the validator on planted non-bugs would measure how often that error occurs.
  • The unstated benchmark datasets are the main threat to generalization; releasing them with difficulty ratings and training and validation separation would turn the headline percentages into a reproducible claim.
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

5 major / 6 minor

Summary. The paper presents SV-LLM, a multi-agent LLM framework intended to automate six SoC security verification tasks: security Q&A, security asset identification, threat modeling and test-plan generation, RTL vulnerability detection, simulation-based security bug validation, and SystemVerilog assertion generation. The system is organized into Supervisor, Orchestrator, and Agent layers, with agents built on different learning paradigms (RAG, fine-tuning, in-context learning). The manuscript supports the framework-exists claim with case studies using NEORV32, a UART/DMA/debug subsystem, and an authentication FSM, and it reports two quantitative results: a fine-tuned Mistral-7B vulnerability detection accuracy of 84.8% versus 42.5% for the non-fine-tuned model, and bug-validated testbench generation rates of 82-89% with the agent framework versus 18-43% with zero-shot prompting. The paper argues that SV-LLM reduces manual intervention and broadens the scope of LLM-based hardware security verification.

Significance. If the quantitative claims are supported, SV-LLM would be a useful step toward automating the full SoC security verification workflow, and the architecture is genuinely broad in scope. The paper has real strengths: it uses real artifacts (NEORV32, ModelSim, official CWE repositories), the illustrative FSM case study is internally consistent and the bug in Listing 3 is genuinely exposed at 45 ns in Listing 4, and the agent decomposition is detailed enough to be reproduced as a system. However, the two headline quantitative results currently rest on undocumented evaluation sets and on a validation oracle that is not independent of the LLM pipeline. As written, the paper is best read as a system demonstration with promising case studies rather than as a validated accuracy claim, and the quantitative sections need substantial additional evidence.

major comments (5)
  1. [Section VII-A, Figure 18] The reported 84.8% detection accuracy for the fine-tuned Security Vulnerability Detection Agent is not interpretable without a description of the evaluation set. Section IV-D says only that a structured prompt-response dataset was constructed, and the results section gives percentages without the number of RTL modules, the vulnerability classes covered, the difficulty mix, or any check that evaluation examples are disjoint from the fine-tuning corpus. The 42.3-point improvement over the non-fine-tuned model could therefore reflect dataset-specific effects or contamination. Please provide the benchmark composition, sizes, class-wise results, a contamination analysis, and the benchmark itself.
  2. [Section VII-B and Section IV-E] The bug-validated testbench generation rates of 82-89% versus 18-43% are the main evidence that the framework closes the loop between LLM-generated testbenches and simulation evidence, but the validation oracle is not independent of the artifacts being validated. The Test Scenario Generation Sub-agent defines the expected signal traces and monitoring points, the Testbench Generation Sub-agent embeds those predefined regions of interest into the monitor, and the Bug Validation Sub-agent compares simulation output against those same LLM-generated expectations (Figure 16). A MATCH at 45 ns therefore establishes that the RTL behaved as the pipeline expected, not that the flagged behavior is a true security bug with respect to an independent specification. The illustrative FSM example is persuasive, but the aggregate percentages need external ground truth (human-labeled vulnerability lists, independent formal properties, or a released labeled benchmark) and per-design results; otherwise the metric is best described as an LLM self-consistency rate.
  3. [Section VII-B, Figure 19] The comparison lacks the experimental detail needed to support the claimed gains. The number of RTL designs, the number of vulnerabilities per design, the number of independent runs per model, and the variance across runs are all unspecified. Because LLM outputs are stochastic, the 89% versus 18% spread could be the result of a small sample or a favorable seed. Please provide a per-design table, run counts, and confidence intervals, and define precisely what counts as a successful bug-validated testbench versus a failed activation or an incomplete definition.
  4. [Section V-C, Listing 2] The generated property list contains a logical inconsistency. The third assertion requires dbg_rdata == 32'hDEADBEEF whenever dbg_sel && dbg_en, while the fourth assertion requires dbg_rdata == 32'hCAFEBABE under the same antecedent; if both are active in the same verification environment they cannot both hold, and the second assertion (which allows either constant) does not reconcile them. The paper should either state that these are alternative candidate assertions from separate scenarios or remove the contradiction before claiming that the outputs are a validated, tool-executable SVA list ready for formal verification.
  5. [Section VII-A, Figure 18] The comparison of the fine-tuned open-source model with GPT-4o and o1 is not controlled: the proprietary models are used in a different prompting regime, and the lengths, formats, and parsing of their answers are not described. Please report the exact prompts, decoding settings, number of runs, and a confusion matrix for every model so the 84.8% figure can be compared with the 91.3% and 86.9% figures.
minor comments (6)
  1. [Section V-A] The chat-agent evaluation is a single anecdotal query; it supports the qualitative claim that RAG reduces hallucination, but the statement that SV-LLM 'exhibited no hallucination' should be softened or backed by a larger evaluation.
  2. [Section V-E, Listings 3 and 4] As typeset, the instantiated module name Authentication_Bypass in Listing 4 does not match the module name Authentication Bypass in Listing 3, and Listing 4 uses a non-ASCII tilde in the clock assignment; please ensure the listings compile as shown or note any PDF conversion artifacts.
  3. [Section VII-B] The heading 'Bug Vallidation' should be corrected to 'Bug Validation', and Figure 19 should include a data table because the bar chart does not convey sample sizes or error bars.
  4. [Section III-A] The description of long-term memory as storing 'the context of the overall conversation of the current session' conflates long-term and short-term memory; please distinguish session-level context from cross-session knowledge.
  5. [Section VIII, Table I] The claim that SV-LLM is the only approach supporting all five verification dimensions should be qualified, since Table I compares only a small curated subset of related work and does not include several recent LLM-based frameworks cited in Section VIII-B.
  6. [Section IV-E] Figure 16 calls the monitor predictions 'golden monitor predictions,' which is misleading because the monitor is generated by the same LLM pipeline rather than derived from an independent golden reference; consider terminology such as 'expected ROI' instead.

Circularity Check

1 steps flagged · score 6.0 of 10

Bug-validation metric is self-referential: the LLM-generated 'regions of interest' define what counts as a validated bug.

  1. self definitional [Section IV-E (Simulation-based Security Bug Validation Agent), Figure 16; Section VII-B (Bug Validation)]
    "Through careful analysis of simulation results and comparison with predefined regions of interest (specific temporal and behavioral points critical for vulnerability verification), the sub-agent categorizes outcomes effectively into successful validation, failed activation, or incomplete definition scenarios."

    The 'predefined regions of interest' are produced by the Test Scenario Generation Sub-agent (an LLM) from the same vulnerability description, and the generated testbench embeds monitoring logic derived from those scenarios. The Bug Validation Sub-agent then confirms a bug when simulation matches this LLM-authored expectation. A 'bug-validated testbench' is therefore defined as one whose simulation output agrees with the same pipeline's earlier prediction, not as one that matches an independent golden model, a human-labeled ground truth, or an externally specified security property. The headline rates in Section VII-B (87%/82%/89% with the framework vs 18%/20%/43% zero-shot) thus measure LLM self-consistency rather than correctness against an independent oracle.

full rationale

Most of the paper's demonstrations are anchored to external artifacts: the NEORV32 SoC specification, ModelSim simulation, and official CWE repositories, and the vulnerability detection improvement (84.8% fine-tuned vs 42.5% non-fine-tuned) is presented as a comparison between models, not a derivation from the paper's own premises. No load-bearing self-citation chain or forbidden-uniqueness argument appears. The one genuine circular step is the bug-validation oracle: the LLM writes the scenarios, writes the testbench, defines the regions of interest, and then compares simulation against those same regions of interest. A match therefore confirms only that the RTL behaved as the LLM expected, which is close to a tautology for a testbench that was iteratively refined to produce that match. The paper does not describe a separate, human-verified benchmark or a golden reference for the Section VII-B experiments, so the reported 82–89% validation rates cannot be distinguished from self-consistency. This is partial circularity affecting the central validation claim, but it does not invalidate the framework's other, externally grounded case studies.

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

SV-LLM anchors its demonstrations to external artifacts (NEORV32 specification, ModelSim simulation, official CWE repositories, proprietary LLM backends), so it is not definitionally circular. The circularity burden comes from three softer dependencies: the vulnerability detection evaluation uses an undisclosed self-constructed dataset; the bug validation oracle is the LLM's own region-of-interest description rather than an independent golden model; and several agents are direct extensions of the authors' prior papers (ThreatLens, BugWhisperer, SoCureLLM, LASP). No hypothetical entities are introduced; the agents are engineered software. The free parameters listed are the undisclosed dataset and corpus choices on which the headline numbers depend.

free parameters (4)
  • Vulnerability detection fine-tuning dataset = undisclosed
    Section IV-D describes a constructed prompt-response dataset for fine-tuning Mistral-7B-Instruct but omits size, source designs, and label sources; the 84.8% accuracy depends on this corpus.
  • Vulnerability detection evaluation test set = undisclosed
    Section VII-A and Figure 18 give 84.8% versus 42.5% and 91.3% versus 86.9% for other models without test set size or composition and without error bars.
  • Bug validation evaluation design set = undisclosed
    Section VII-B says experiments covered 'a diverse set of RTL designs' but shows only aggregate rates (82% to 89% versus 18% to 43%) with no design count, vulnerability types, or design list.
  • Knowledge base corpus for chat agent = undisclosed
    Section IV-A's vectorstores and Section V-A's no-hallucination finding depend on a curated corpus whose coverage and construction are not described.
assumptions (4)
  • domain assumption LLM-generated verification artifacts (security properties, testbenches, threat models, asset lists) are correct enough to be useful after the described refinement loops.
    Central to Sections IV-B through IV-F; if LLM outputs are systematically wrong in ways the refinement loops miss, the framework's outputs mislead rather than assist.
  • domain assumption The LLM-defined region of interest faithfully encodes the real vulnerability, so a simulation matching the ROI confirms the bug.
    Section IV-E and Figure 16: validation compares simulation signals against an expected ROI written from the bug report; there is no independent golden model. A wrong bug characterization would be confidently misvalidated.
  • domain assumption Security-critical assets can be identified from the SoC specification alone, without RTL access.
    Section IV-B deliberately limits input to the spec document; the cited prior works [43]-[45] use RTL. If specifications omit security-relevant details, recall of asset identification suffers.
  • domain assumption The CWE mappings underlying property generation are complete and accurate for the target design classes.
    Section IV-F maps designs and threat vectors to CWE identifiers via LLM classification and a static lookup; missed CWE classes translate directly to missed security properties.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SV-LLM: An Agentic Approach for SoC Security Verification using Large Language Models." pith.science (2026). https://pith.science/paper/GSL4CE7O

@misc{pith2026250620415,
  author       = {Pith},
  title        = {Pith review of: SV-LLM: An Agentic Approach for SoC Security Verification using Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GSL4CE7O}},
  note         = {Machine review of arXiv:2506.20415}
}
read the original abstract

Ensuring the security of complex system-on-chips (SoCs) designs is a critical imperative, yet traditional verification techniques struggle to keep pace due to significant challenges in automation, scalability, comprehensiveness, and adaptability. The advent of large language models (LLMs), with their remarkable capabilities in natural language understanding, code generation, and advanced reasoning, presents a new paradigm for tackling these issues. Moving beyond monolithic models, an agentic approach allows for the creation of multi-agent systems where specialized LLMs collaborate to solve complex problems more effectively. Recognizing this opportunity, we introduce SV-LLM, a novel multi-agent assistant system designed to automate and enhance SoC security verification. By integrating specialized agents for tasks like verification question answering, security asset identification, threat modeling, test plan and property generation, vulnerability detection, and simulation-based bug validation, SV-LLM streamlines the workflow. To optimize their performance in these diverse tasks, agents leverage different learning paradigms, such as in-context learning, fine-tuning, and retrieval-augmented generation (RAG). The system aims to reduce manual intervention, improve accuracy, and accelerate security analysis, supporting proactive identification and mitigation of risks early in the design cycle. We demonstrate its potential to transform hardware security practices through illustrative case studies and experiments that showcase its applicability and efficacy.

Figures

Figures reproduced from arXiv: 2506.20415 by the authors.

Figure 1
Figure 1. Frontend interface of SV-LLM. verification tasks into manageable subgoals, supports collabo￾rative decision-making among specialized agents responsible for individual subtasks, and allows agents to iteratively refine their outputs based on feedback - either from the verification engineer or from other agents - within an evolving verification context. III. SV-LLM SV-LLM is an LLM-driven agentic framework designed for… view at source ↗
Figure 2
Figure 2. Overview of SV-LLM. d) Safe and Domain-Constrained Dialogue: To ensure the integrity and relevance of interactions, SV-LLM actively constrains dialogue to topics within the scope of semiconduc￾tor design, hardware security, and system-level verification. Irrelevant or off-topic queries, particularly those unrelated to hardware, VLSI, or formal methods, are gracefully rejected, maintaining the professional focus of t… view at source ↗
Figure 3
Figure 3. Layered architecture of the SV-LLM framework security verification tasks through a unified interface. To accomplish this, the system employs a large language model to classify the query into one or more functional cate￾gories. These categories represent different verification-related activities, such as analyzing design vulnerabilities, generating formal properties, identifying security-relevant components, or guidi… view at source ↗
Figures from the paper (16 more)
Figure 4
Figure 4. Figure 4: Overview of Supervisor and Orchestrator. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Overview of Security Chat Agent. has been emphasized in initiatives such as Accellera’s SA-EDI standard [41] and the IEEE P3164 [42] effort before. Existing approaches, such as [43] and [44], focus on asset identification from RTL alone, without utilizing the SoC speci…
Figure 6
Figure 6. Figure 6: Overview of Security Asset Generation Agent [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Overview of Threat Modeling and Test Plan Generation Agent. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Overview of Security Bug Detection Agent. cation using a retriever-LLM combination. Subsequently, a second RAG system searches the ISA document to extract corresponding security policies associated with each asset. Once the policies are gathered, they are passed to the…
Figure 9
Figure 9. Figure 9: Overview of Simulation-based Security Bug Validation Agent [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Overview of Security Property Generation Agent. presence and correct manifestation of the targeted vulnerabil￾ity. Through careful analysis of simulation results and com￾parison with predefined regions of interest (specific temporal and behavioral points critical for …
Figure 11
Figure 11. Figure 11: Response of ChatGPT-4o [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: Response of SV-LLM. through a structured multi-stage pipeline. The process begins with the Input Design being fed into a Design-to-CWE Map￾ping module. Here, a prompting engine and a specialized LLM classify the RTL design into predefined structural categories and ass…
Figure 13
Figure 13. Figure 13: SV-LLM Response for Hardware Vulnerability Detection Generator Agent within this framework constructed detailed simulation scenarios, illustrated in [PITH_FULL_IMAGE:figures/full_fig_p014_13.png]
Figure 15
Figure 15. Figure 15: Test scenarios generated for the FSM bug, with precise timestamps [PITH_FULL_IMAGE:figures/full_fig_p015_15.png]
Figure 14
Figure 14. Figure 14: Description of the authentication FSM vulnerability [PITH_FULL_IMAGE:figures/full_fig_p015_14.png]
Figure 17
Figure 17. Figure 17: SV-LLM system architecture [PITH_FULL_IMAGE:figures/full_fig_p016_17.png]
Figure 18
Figure 18. Figure 18: Comparison of Security Vulnerability Detection Agent with other Proprietary and Open-source LLMs secure SSH tunnel. This tunnel creates an encrypted channel between the backend server and HiperGator compute nodes, enabling reliable, high-performance model inference wi…
Figure 16
Figure 16. Figure 16: Validator output at 45 ns, comparing the expected ROI against [PITH_FULL_IMAGE:figures/full_fig_p016_16.png]
Figure 19
Figure 19. Figure 19: Comparison of bug-validated testbench generation rates across [PITH_FULL_IMAGE:figures/full_fig_p017_19.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

81 extracted references · 59 canonical work pages

  1. [1]

    A. Darbari. (2024, April) Verification in crisis. Accessed: 2025-04-25. [Online]. Available: https://semiengineering.com/verification-in-crisis/

    2024

  2. [2]

    Pacman: attacking arm pointer authentication with speculative execution,

    J. Ravichandran, W. T. Na, J. Lang, and M. Yan, “Pacman: attacking arm pointer authentication with speculative execution,” inProceedings of the 49th Annual International Symposium on Computer Architecture, 2022, pp. 685–698

    work page 2022

  3. [3]

    Augury: Using data memory- dependent prefetchers to leak data at rest,

    J. S. Vicarte, M. Flanders, R. Paccagnella, G. Garrett-Grossman, A. Mor- rison, C. Fletcher, and D. Kohlbrenner, “Augury: Using data memory- dependent prefetchers to leak data at rest,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2022, pp. 1518– 1518

    work page 2022

  4. [4]

    Riscvuzz: Discovering architectural cpu vulnerabilities via differential hardware fuzzing,

    F. Thomas, L. Hetterich, R. Zhang, D. Weber, L. Gerlach, and M. Schwarz, “Riscvuzz: Discovering architectural cpu vulnerabilities via differential hardware fuzzing,” 2024

    work page 2024

  5. [5]

    Formal security verification of third party intellectual property cores for infor- mation leakage,

    J. Rajendran, A. M. Dhandayuthapany, V . Vedula, and R. Karri, “Formal security verification of third party intellectual property cores for infor- mation leakage,” in2016 29th International conference on VLSI design and 2016 15th international conference on embedded systems (VLSID). IEEE, 2016, pp. 547–552

    2016

  6. [6]

    Formal verification of taint-propagation security properties in a commercial soc design,

    P. Subramanyan and D. Arora, “Formal verification of taint-propagation security properties in a commercial soc design,” in2014 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2014, pp. 1–2

    work page 2014

  7. [7]

    Hardware trojan detection through information flow security verification,

    A. Nahiyan, M. Sadi, R. Vittal, G. Contreras, D. Forte, and M. Tehra- nipoor, “Hardware trojan detection through information flow security verification,” in2017 IEEE International Test Conference (ITC). IEEE, 2017, pp. 1–10

    work page 2017

  8. [8]

    Scalable concolic testing of rtl models,

    Y . Lyu and P. Mishra, “Scalable concolic testing of rtl models,”IEEE Transactions on Computers, vol. 70, no. 7, pp. 979–991, 2020

    work page 2020

Show all 81 references
  1. [9]

    Automated activation of multiple targets in rtl models using concolic testing,

    Y . Lyu, A. Ahmed, and P. Mishra, “Automated activation of multiple targets in rtl models using concolic testing,” in2019 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2019, pp. 354–359

    2019

  2. [10]

    Rtl- fsmx: Fast and accurate finite state machine extraction at the rtl for security applications,

    R. Kibria, M. S. Rahman, F. Farahmandi, and M. Tehranipoor, “Rtl- fsmx: Fast and accurate finite state machine extraction at the rtl for security applications,” in2022 IEEE International Test Conference (ITC). IEEE, 2022, pp. 165–174

    2022

  3. [11]

    Quardtropy: Detecting and quantifying unauthorized information leakage in hardware designs using g-entropy,

    H. Al Shaikh, M. B. Monjil, K. Z. Azar, F. Farahmandi, M. Tehranipoor, and F. Rahman, “Quardtropy: Detecting and quantifying unauthorized information leakage in hardware designs using g-entropy,” in2023 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nan...

    2023

  4. [12]

    Mab- fuzz: Multi-armed bandit algorithms for fuzzing processors,

    V . Gohil, R. Kande, C. Chen, A.-R. Sadeghi, and J. Rajendran, “Mab- fuzz: Multi-armed bandit algorithms for fuzzing processors,” in2024 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2024, pp. 1–6

    2024

  5. [13]

    Socfuzzer: Soc vulnerability detection using cost function enabled fuzz testing,

    M. M. Hossain, A. Vafaei, K. Z. Azar, F. Rahman, F. Farahmandi, and M. Tehranipoor, “Socfuzzer: Soc vulnerability detection using cost function enabled fuzz testing,” in2023 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2023, pp. 1–6

    2023

  6. [14]

    Fuzz, penetration, and ai testing for soc security verification: Challenges and solutions,

    K. Z. Azar, M. M. Hossain, A. Vafaei, H. Al Shaikh, N. N. Mondol, F. Rahman, M. Tehranipoor, and F. Farahmandi, “Fuzz, penetration, and ai testing for soc security verification: Challenges and solutions,” Cryptology ePrint Archive, 2022

    2022

  7. [15]

    Fuzzing hardware like software,

    T. Trippel, K. G. Shin, A. Chernyakhovsky, G. Kelly, D. Rizzo, and M. Hicks, “Fuzzing hardware like software,”arXiv preprint arXiv:2102.02308, 2021

    2021 arXiv

  8. [16]

    Sharpen: Soc security verification by hardware penetration test,

    H. Al-Shaikh, A. Vafaei, M. M. M. Rahman, K. Z. Azar, F. Rahman, F. Farahmandi, and M. Tehranipoor, “Sharpen: Soc security verification by hardware penetration test,” inProceedings of the 28th Asia and South Pacific Design Automation Conference, 2023, pp. 579–584

    2023

  9. [17]

    Re-pen: Reinforcement learning-enforced penetration testing for soc security verification,

    H. Al Shaikh, S. Saha, K. Z. Azar, F. Farahmandi, M. Tehranipoor, and F. Rahman, “Re-pen: Reinforcement learning-enforced penetration testing for soc security verification,”IEEE Transactions on Very Large Scale Integration (VLSI) Systems, no. 01, pp. 1–14, 2024

    2024

  10. [18]

    Bench- marking of soc-level hardware vulnerabilities: A complete walkthrough,

    S. Tarek, H. Al Shaikh, S. R. Rajendran, and F. Farahmandi, “Bench- marking of soc-level hardware vulnerabilities: A complete walkthrough,” in2023 IEEE Computer Society Annual Symposium on VLSI (ISVLSI). IEEE, 2023, pp. 1–6

    2023

  11. [19]

    Llm for soc security: A paradigm shift,

    D. Saha, S. Tarek, K. Yahyaei, S. K. Saha, J. Zhou, M. Tehranipoor, and F. Farahmandi, “Llm for soc security: A paradigm shift,”IEEE Access, vol. 12, pp. 155 498–155 521, 2024

    2024

  12. [20]

    (security) assertions by large language models,

    R. Kande, H. Pearce, B. Tan, B. Dolan-Gavitt, S. Thakur, R. Karri, and J. Rajendran, “(security) assertions by large language models,”IEEE Transactions on Information Forensics and Security, 2024

    2024

  13. [21]

    On hardware security bug code fixes by prompting large language models,

    B. Ahmad, S. Thakur, B. Tan, R. Karri, and H. Pearce, “On hardware security bug code fixes by prompting large language models,”IEEE Transactions on Information Forensics and Security, 2024

    2024

  14. [22]

    Nspg: Natural language processing-based secu- rity property generator for hardware security assurance,

    X. Meng, A. Srivastava, A. Arunachalam, A. Ray, P. H. Silva, R. Psiakis, Y . Makris, and K. Basu, “Nspg: Natural language processing-based secu- rity property generator for hardware security assurance,” inProceedings of the 61st ACM/IEEE Design Automation Conference, 2024, pp. 1–6

    2024

  15. [23]

    Empowering hardware security with llm: The development of a vul- nerable hardware database,

    D. Saha, K. Yahyaei, S. K. Saha, M. Tehranipoor, and F. Farahmandi, “Empowering hardware security with llm: The development of a vul- nerable hardware database,” in2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST). IEEE, 2024, pp. 233– 243

    2024

  16. [24]

    Socurellm: An llm-driven approach for large-scale system-on-chip security verification and policy generation,

    S. Tarek, D. Saha, S. K. Saha, M. Tehranipoor, and F. Farahmandi, “Socurellm: An llm-driven approach for large-scale system-on-chip security verification and policy generation,”Cryptology ePrint Archive, 2024

    2024

  17. [25]

    Special session: Threatlens: Llm-guided threat modeling and test plan generation for hardware security verification,

    D. Saha, H. Al Shaikh, S. Tarek, and F. Farahmandi, “Special session: Threatlens: Llm-guided threat modeling and test plan generation for hardware security verification,” in2025 IEEE 43rd VLSI Test Symposium (VTS), 2025, pp. 1–5

    2025

  18. [26]

    Bugwhisperer: Fine- tuning llms for soc hardware vulnerability detection,

    S. Tarek, D. Saha, S. K. Saha, and F. Farahmandi, “Bugwhisperer: Fine- tuning llms for soc hardware vulnerability detection,” in2025 IEEE 43rd VLSI Test Symposium (VTS), 2025, pp. 1–5

    2025

  19. [27]

    Navigating soc security landscape on llm-guided paths,

    S. Paria, A. Dasgupta, and S. Bhunia, “Navigating soc security landscape on llm-guided paths,” inProceedings of the Great Lakes Symposium on VLSI 2024, 2024, pp. 252–257

    2024

  20. [28]

    Self-hwdebug: Automation of llm self- instructing for hardware security verification,

    M. Akyash and H. M. Kamali, “Self-hwdebug: Automation of llm self- instructing for hardware security verification,” in2024 IEEE Computer Society Annual Symposium on VLSI (ISVLSI). IEEE, 2024, pp. 391– 396

    2024

  21. [29]

    Toward hardware security benchmarking of llms,

    R. Afsharmazayejani, M. M. Shahmiri, P. Link, H. Pearce, and B. Tan, “Toward hardware security benchmarking of llms,” in2024 IEEE LLM Aided Design Workshop (LAD), 2024, pp. 1–7

    2024

  22. [30]

    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

  23. [31]

    Automated hardware logic obfuscation framework using gpt,

    B. S. Latibari, S. Ghimire, M. A. Chowdhury, N. Nazari, K. I. Gubbi, H. Homayoun, A. Sasan, and S. Salehi, “Automated hardware logic obfuscation framework using gpt,” in2024 IEEE 17th Dallas Circuits and Systems Conference (DCAS). IEEE, 2024, pp. 1–5

    2024

  24. [32]

    Hardware trojan detection in open-source hardware designs using machine learning,

    V . T. Hayashi and W. Vicente Ruggiero, “Hardware trojan detection in open-source hardware designs using machine learning,”IEEE Access, vol. 13, pp. 37 771–37 788, 2025

    2025

  25. [33]

    Openassert: Towards secure assertion generation using large language models,

    A. Menon, S. S. Miftah, A. Srivastava, S. Kundu, S. Kundu, A. Raha, S. Banerjee, D. Mathaikutty, and K. Basu, “Openassert: Towards secure assertion generation using large language models,” in2025 IEEE 43rd VLSI Test Symposium (VTS), 2025, pp. 1–5

    2025

  26. [34]

    Llm-based agentic systems in medicine and healthcare,

    J. Qiu, K. Lam, G. Li, A. Acharya, T. Y . Wong, A. Darzi, W. Yuan, and E. J. Topol, “Llm-based agentic systems in medicine and healthcare,” Nature Machine Intelligence, vol. 6, no. 12, pp. 1418–1420, 2024

    2024

  27. [35]

    Agentic ai: Autonomous intelligence for complex goals–a comprehensive survey,

    D. B. Acharya, K. Kuppan, and B. Divya, “Agentic ai: Autonomous intelligence for complex goals–a comprehensive survey,”IEEE Access, 2025

    2025

  28. [36]

    Macm: Utilizing a multi-agent system for condition mining in solving complex mathemat- ical problems,

    B. Lei, Y . Zhang, S. Zuo, A. Payani, and C. Ding, “Macm: Utilizing a multi-agent system for condition mining in solving complex mathemat- ical problems,”arXiv preprint arXiv:2404.04735, 2024

    2024 arXiv

  29. [37]

    Autodefense: Multi-agent llm defense against jailbreak attacks,

    Y . Zeng, Y . Wu, X. Zhang, H. Wang, and Q. Wu, “Autodefense: Multi-agent llm defense against jailbreak attacks,”arXiv preprint arXiv:2403.04783, 2024

    2024 arXiv

  30. [38]

    Fincon: A synthesized llm multi-agent system with conceptual verbal reinforcement for enhanced financial decision making,

    Y . Yu, Z. Yao, H. Li, Z. Deng, Y . Jiang, Y . Cao, Z. Chen, J. Suchow, Z. Cui, R. Liuet al., “Fincon: A synthesized llm multi-agent system with conceptual verbal reinforcement for enhanced financial decision making,”Advances in Neural Information Processing Systems, vol. 37, ...

    2024

  31. [39]

    An autonomous multi-agent llm framework for agile soft- ware development,

    S. Manish, “An autonomous multi-agent llm framework for agile soft- ware development,”International Journal of Trend in Scientific Research and Development, vol. 8, no. 5, pp. 892–898, 2024

    2024

  32. [40]

    A survey on multi- generative agent system: Recent advances and new frontiers,

    S. Chen, Y . Liu, W. Han, W. Zhang, and T. Liu, “A survey on multi- generative agent system: Recent advances and new frontiers,”arXiv preprint arXiv:2412.17481, 2024

    2024 arXiv

  33. [41]

    [Online]

    (2021) Security annotation for electronic design integration standard. [Online]. Available: https://www.accellera.org/images/ downloads/standards/Accellera SA-EDI Standard v10.pdf

    2021

  34. [42]

    Asset identification for electronic design ip,

    “Asset identification for electronic design ip,”Asset Identification for Electronic Design IP, pp. 1–26, 2024

    2024

  35. [43]

    Toward automated potential primary asset identification in verilog designs,

    S. K. D. Nath and B. Tan, “Toward automated potential primary asset identification in verilog designs,”arXiv preprint arXiv:2502.04648, 2025

    2025 arXiv

  36. [44]

    Automatic asset identification for assertion-based soc security verifi- cation,

    A. Ayalasomayajula, N. F. Dipu, M. M. Tehranipoor, and F. Farahmandi, “Automatic asset identification for assertion-based soc security verifi- cation,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 43, no. 10, pp. 3264–3277, 2024

    2024

  37. [45]

    Lasp: Llm assisted security property generation for soc verification,

    A. Ayalasomayajula, R. Guo, J. Zhou, S. K. Saha, and F. Farahmandi, “Lasp: Llm assisted security property generation for soc verification,” inProceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD, 2024, pp. 1–7

    2024

  38. [46]

    Rfuzz: Coverage-directed fuzz testing of rtl on fpgas,

    K. Laeufer, J. Koenig, D. Kim, J. Bachrach, and K. Sen, “Rfuzz: Coverage-directed fuzz testing of rtl on fpgas,” in2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD). IEEE, 2018, pp. 1–8

    2018

  39. [47]

    Thehuzz: Instruction fuzzing of processors using golden- reference models for finding software-exploitable vulnerabilities,

    A. Tyagi, A. Crump, A.-R. Sadeghi, G. Persyn, J. Rajendran, P. Jauernig, and R. Kande, “Thehuzz: Instruction fuzzing of processors using golden- reference models for finding software-exploitable vulnerabilities,”arXiv preprint arXiv:2201.09941, 2022

    2022 arXiv

  40. [48]

    Formalfuzzer: Formal verification assisted fuzz testing for soc vulnerability detection,

    N. F. Dipu, M. M. Hossain, K. Z. Azar, F. Farahmandi, and M. Tehra- nipoor, “Formalfuzzer: Formal verification assisted fuzz testing for soc vulnerability detection,” in2024 29th Asia and South Pacific Design Automation Conference (ASP-DAC). IEEE, 2024, pp. 355–361

    2024

  41. [49]

    Cist: A threat modelling approach for hardware supply chain security,

    B. Halak, “Cist: A threat modelling approach for hardware supply chain security,”Hardware Supply Chain Security: Threat Modelling, Emerging Attacks and Countermeasures, pp. 3–65, 2021

    2021

  42. [50]

    Hardware security: Threat models and metrics,

    M. Rostami, F. Koushanfar, J. Rajendran, and R. Karri, “Hardware security: Threat models and metrics,” in2013 IEEE/ACM International Conference on Computer-Aided Design (ICCAD). IEEE, 2013, pp. 819–823

    2013

  43. [51]

    A hardware threat modeling concept for trustable integrated circuits,

    J. Di and S. Smith, “A hardware threat modeling concept for trustable integrated circuits,” in2007 IEEE Region 5 Technical Conference. IEEE, 2007, pp. 354–357

    2007

  44. [52]

    Security policy enforcement in modern soc designs,

    S. Ray and Y . Jin, “Security policy enforcement in modern soc designs,” in2015 IEEE/ACM International Conference on Computer-Aided De- sign (ICCAD). IEEE, 2015, pp. 345–350

    2015

  45. [53]

    System-on-chip platform security assurance: Architecture and validation,

    S. Ray, E. Peeters, M. M. Tehranipoor, and S. Bhunia, “System-on-chip platform security assurance: Architecture and validation,”Proceedings of the IEEE, vol. 106, no. 1, pp. 21–37, 2017

    2017

  46. [54]

    Security vulnerability analysis of design-for-test exploits for asset protection in socs,

    G. K. Contreras, A. Nahiyan, S. Bhunia, D. Forte, and M. Tehranipoor, “Security vulnerability analysis of design-for-test exploits for asset protection in socs,” in2017 22nd Asia and South Pacific Design Automation Conference (ASP-DAC). IEEE, 2017, pp. 617–622

    2017

  47. [55]

    Script: A cad framework for power side-channel vulnerability assessment using information flow tracking and pattern generation,

    A. Nahiyan, J. Park, M. He, Y . Iskander, F. Farahmandi, D. Forte, and M. Tehranipoor, “Script: A cad framework for power side-channel vulnerability assessment using information flow tracking and pattern generation,”ACM Transactions on Design Automation of Electronic Systems (...

    2020

  48. [56]

    A flexible architecture for systematic implementation of soc security policies,

    A. Basak, S. Bhunia, and S. Ray, “A flexible architecture for systematic implementation of soc security policies,” in2015 IEEE/ACM Interna- tional Conference on Computer-Aided Design (ICCAD). IEEE, 2015, pp. 536–543

    2015

  49. [57]

    Security verification of the opentitan hardware root of trust,

    A. Meza, F. Restuccia, J. Oberg, D. Rizzo, and R. Kastner, “Security verification of the opentitan hardware root of trust,”IEEE Security & Privacy, vol. 21, no. 3, pp. 27–36, 2023

    2023

  50. [58]

    Soc secu- rity verification using property checking,

    N. Farzana, F. Rahman, M. Tehranipoor, and F. Farahmandi, “Soc secu- rity verification using property checking,” in2019 IEEE International Test Conference (ITC). IEEE, 2019, pp. 1–10

    2019

  51. [59]

    Towards property driven hardware security,

    W. Hu, A. Althoff, A. Ardeshiricham, and R. Kastner, “Towards property driven hardware security,” in2016 17th International Workshop on Microprocessor and SOC Test and Verification (MTV). IEEE, 2016, pp. 51–56

    2016

  52. [60]

    Automated generation of security assertions for rtl models,

    H. Witharana, A. Jayasena, A. Whigham, and P. Mishra, “Automated generation of security assertions for rtl models,”J. Emerg. Technol. Comput. Syst., vol. 19, 2023

    2023

  53. [61]

    Harnessing machine learning to improve the success rate of stimuli generation,

    S. Fine, A. Freund, I. Jaeger, Y . Mansour, Y . Naveh, and A. Ziv, “Harnessing machine learning to improve the success rate of stimuli generation,”IEEE Transactions on Computers, vol. 55, no. 11, pp. 1344– 1355, 2006

    2006

  54. [62]

    Automated coverage directed test generation using a cell-based genetic algorithm,

    A. Samarah, A. Habibi, S. Tahar, and N. Kharma, “Automated coverage directed test generation using a cell-based genetic algorithm,” in2006 IEEE International High Level Design Validation and Test Workshop. IEEE, 2006, pp. 19–26

    2006

  55. [63]

    Machine learning for hardware security: Opportunities and risks,

    R. Elnaggar and K. Chakrabarty, “Machine learning for hardware security: Opportunities and risks,”Journal of Electronic Testing, vol. 34, pp. 183–201, 2018

    2018

  56. [64]

    Hypfuzz:formal-assisted processor fuzzing,

    C. Chen, R. Kandeet al., “Hypfuzz:formal-assisted processor fuzzing,” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 1361–1378

    2023

  57. [65]

    Automatic test bench generation for simulation-based validation,

    M. Lajolo, L. Lavagno, M. Rebaudengo, M. S. Reorda, and M. Violante, “Automatic test bench generation for simulation-based validation,” in Proceedings of the eighth international workshop on Hardware/software codesign, 2000, pp. 136–140

    2000

  58. [66]

    Coverage directed test generation: Godson experience,

    H. Shen, W. Wei, Y . Chen, B. Chen, and Q. Guo, “Coverage directed test generation: Godson experience,” in2008 17th Asian Test Symposium. IEEE, 2008, pp. 321–326

    2008

  59. [67]

    Automatic boost- ing of cross-product coverage using bayesian networks,

    D. Baras, S. Fine, L. Fournier, D. Geiger, and A. Ziv, “Automatic boost- ing of cross-product coverage using bayesian networks,”International Journal on Software Tools for Technology Transfer, vol. 13, pp. 247– 261, 2011

    2011

  60. [68]

    Divas: An llm-based end-to-end framework for soc security analysis and policy-based protection,

    S. Paria, A. Dasgupta, and S. Bhunia, “Divas: An llm-based end-to-end framework for soc security analysis and policy-based protection,”arXiv preprint arXiv:2308.06932, 2023

    2023 arXiv

  61. [69]

    Llm4sechw: Leveraging domain-specific large language model for hardware debug- ging,

    W. Fu, K. Yang, R. G. Dutta, X. Guo, and G. Qu, “Llm4sechw: Leveraging domain-specific large language model for hardware debug- ging,” in2023 Asian Hardware Oriented Security and Trust Symposium (AsianHOST), 2023, pp. 1–6

    2023

  62. [70]

    Uvllm: An automated universal rtl verification framework using llms,

    Y . Hu, J. Ye, K. Xu, J. Sun, S. Zhang, X. Jiao, D. Pan, J. Zhou, N. Wang, W. Shanet al., “Uvllm: An automated universal rtl verification framework using llms,”arXiv preprint arXiv:2411.16238, 2024

    2024 arXiv

  63. [71]

    Rtlfixer: Automatically fixing rtl syntax errors with large language model,

    Y . Tsai, M. Liu, and H. Ren, “Rtlfixer: Automatically fixing rtl syntax errors with large language model,” inProceedings of the 61st ACM/IEEE Design Automation Conference, 2024, pp. 1–6

    2024

  64. [72]

    Hdldebugger: Streamlining hdl debugging with large language models,

    X. Yao, H. Li, T. H. Chan, W. Xiao, M. Yuan, Y . Huang, L. Chen, and B. Yu, “Hdldebugger: Streamlining hdl debugging with large language models,”arXiv preprint arXiv:2403.11671, 2024

    2024 arXiv

  65. [73]

    Llm4dv: Using large language models for hardware test stimuli generation,

    Z. Zhang, G. Chadwick, H. McNally, Y . Zhao, and R. Mullins, “Llm4dv: Using large language models for hardware test stimuli generation,”arXiv preprint arXiv:2310.04535, 2023

    2023 arXiv

  66. [74]

    Towards llm-powered verilog rtl assistant: Self-verification and self-correction,

    H. Huang, Z. Lin, Z. Wang, X. Chen, K. Ding, and J. Zhao, “Towards llm-powered verilog rtl assistant: Self-verification and self-correction,” arXiv preprint arXiv:2406.00115, 2024

    2024 arXiv

  67. [75]

    Veridebug: A unified llm for verilog debugging via contrastive embed- ding and guided correction,

    N. Wang, B. Yao, J. Zhou, Y . Hu, X. Wang, N. Guan, and Z. Jiang, “Veridebug: A unified llm for verilog debugging via contrastive embed- ding and guided correction,”arXiv preprint arXiv:2504.19099, 2025

    2025 arXiv

  68. [76]

    Flag: Formal and llm- assisted sva generation for formal specifications of on-chip communica- tion protocols,

    Y .-A. Shih, A. Lin, A. Gupta, and S. Malik, “Flag: Formal and llm- assisted sva generation for formal specifications of on-chip communica- tion protocols,”arXiv preprint arXiv:2504.17226, 2025

    2025 arXiv

  69. [77]

    Assertionforge: Enhancing formal verification assertion generation with structured representation of specifications and rtl,

    Y . Bai, G. B. Hamad, S. Suhaib, and H. Ren, “Assertionforge: Enhancing formal verification assertion generation with structured representation of specifications and rtl,”arXiv preprint arXiv:2503.19174, 2025

    2025 arXiv

  70. [78]

    Fveval: Understanding language model capabilities in formal verification of digital hardware,

    M. Kang, M. Liu, G. B. Hamad, S. Suhaib, and H. Ren, “Fveval: Understanding language model capabilities in formal verification of digital hardware,”arXiv preprint arXiv:2410.23299, 2024

    2024 arXiv

  71. [79]

    Towards improving verification pro- ductivity with circuit-aware translation of natural language to systemver- ilog assertions,

    C. Sun, C. Hahn, and C. Trippel, “Towards improving verification pro- ductivity with circuit-aware translation of natural language to systemver- ilog assertions,” inFirst International Workshop on Deep Learning-aided Verification, 2023

    2023

  72. [80]

    Assertionbench: A benchmark to evaluate large-language models for assertion generation,

    V . Pulavarthi, D. Nandal, S. Dan, and D. Pal, “Assertionbench: A benchmark to evaluate large-language models for assertion generation,” arXiv preprint arXiv:2406.18627, 2024

    2024 arXiv

  73. [81]

    Llm-guided formal verification coupled with mutation testing,

    M. Hassan, S. Ahmadi-Pour, K. Qayyum, C. K. Jha, and R. Drechsler, “Llm-guided formal verification coupled with mutation testing,” in2024 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2024, pp. 1–2

    2024

Pith tools

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