Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Accelerating Hardware Verification with Graph Models

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

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

Pith's one-line read GraphFuzz claims that a graph recurrent neural network trained on gate-level simulation data can predict node logic values with roughly 80% accuracy and detect synthesis-introduced bugs with roughly 70% accuracy, enabling accelerated…

desk verdict A plausible graph-learning pipeline for gate-level netlists, but the central 'bug detection' claim is a mislabeled node-value prediction accuracy and the evaluation never shows a real detection. read the letter →

arxiv 2412.13374 v2 pith:HCSIRGSJ submitted 2024-12-17 cs.CR

Raghul Saravanan , Sreenitha Kasarapu , Sai Manoj Pudukotai Dinakarrao This is my paper · ORCID
classification cs.CR
keywords hardwarefuzzinggate-levelnetlistverificationgraphneuralnetworksrecurrentnetworksynthesisbugssecurityEDAsimulationbugdetection
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

GraphFuzz proposes to speed up gate-level hardware verification by treating a synthesized netlist as a graph and training a graph recurrent neural network to predict the logic value of every node (input, wire, and output). Once trained on simulation data from the same netlist, the model is fuzzed with mutated input bit vectors, and predicted node values are compared against RTL simulation as a golden reference. The paper reports about 80% average prediction accuracy and 70% average bug detection accuracy across benchmark circuits, AES and DSP peripherals, and ALUs of open-source RISC-V and OpenRISC processors. If correct, this would give verification engineers a way to catch synthesis-introduced bugs without running slow gate-level simulations for every test, replacing part of the simulation workload with learned inference.

What carries the argument

The load-bearing object is the NetGraph: an undirected graph of the gate-level netlist where each gate and interface port is a node, and each node carries a feature vector encoding interface type, gate type, and current logic value. The model is a Graph Recurrent Neural Network (GRNN) that stacks four graph convolutional layers, using the normalized adjacency matrix $\hat{A} = D^{-1/2}(A+I)D^{-1/2}$ and ReLU activations, over a single long short-term memory (LSTM) layer, trained on logic-value traces extracted from EDA gate-level simulation. Fuzzing is steered by graph node coverage metrics—degree, betweenness, closeness, and eigenvector centrality—treated as analogues of gate-level toggle coverage, and the RTL description serves as the golden reference model for flagging discrepancies.

What would settle it

Take one of the benchmark netlists the paper reports as bug-free, inject a known synthesis-style functional fault (for example, alter the carry or overflow assignment in the ALU), and check whether GraphFuzz's flagged mismatches coincide with the injected fault on both buggy and bug-free versions. If the flagged-bug rate is similar on clean and mutated netlists, then the reported detections are not separating model error from real bugs; if mismatches disappear once the circuit reaches steady state, the claimed gate-delay bugs are timing artifacts rather than functional flaws.

Watch

Extended reading notes

Core claim

The paper's central claim is that a gate-level netlist can be modeled as a graph, with gate types, interface types, and evolving logic values encoded as node features, and that a Graph Recurrent Neural Network (GRNN) trained on this representation can learn enough of the circuit's behavior to support fuzzing. The fuzzer, NetGraph Fuzzer, mutates input seed bit vectors, uses graph centrality metrics as coverage feedback, and compares GRNN-predicted node values against RTL simulation outputs, flagging mismatches as bugs. The authors report detecting the known carry-flag bug in the mor1kx ALU with about 70% accuracy and the overflow-flag bug in the or1200 ALU with about 82.7% accuracy, and they observe gate-delay-related mismatches in several designs. They further claim this is the first hardware fuzzing approach to operate on gate-level netlists using graph learning, in contrast to prior fuzzers that target RTL.

Load-bearing premise

A mismatch between the GRNN's predicted node values and the RTL simulation output is treated as a bug signal, but the model is trained on gate-level simulation data from the same netlist, so a mismatch can also be ordinary model error or transient timing behavior rather than a real design flaw.

Editorial extensions

If this is right

  • Gate-level fuzzing can proceed at inference speed on the learned graph model rather than through full gate-level simulation, reducing the verification time per input seed.
  • GraphFuzz can reproduce known ALU flag bugs that prior RTL-level fuzzers found, and can expose gate-delay-related mismatches that RTL simulation does not show.
  • The approach fits into existing EDA flows because it builds graphs and training data from standard synthesis and simulation outputs, then compares predictions against RTL as the golden model.
  • Prediction accuracy varies with the connectivity of the netlist, so the method works best on well-connected designs and degrades on sparsely connected graphs such as one of the OpenRISC ALUs.
  • The presence or absence of flagged bugs is design-dependent; on the ISCAS benchmark circuits examined, no RTL-versus-netlist discrepancies were observed.

Reading between the lines

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

  • A natural extension the authors do not develop is to use the GRNN's prediction confidence as a ranking signal, so verification effort is targeted at the most uncertain nodes rather than treating every mismatch as an equal bug.
  • The same graph encoding of gate types, connectivity, and logic states could likely be reused for other netlist-level tasks such as hardware Trojan detection or reverse-engineering, since it already captures structural and functional features.
  • Because the paper counts timing-related transient mismatches as bugs, one testable refinement is to compare predictions only after the circuit stabilizes, which would separate true synthesis-introduced functional bugs from ordinary propagation-delay effects.
  • The reported bug detection accuracy is measured against known buggy node values, so a practical deployment would additionally need to measure false-alarm rate on clean netlists; that measurement is not reported.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper proposes GraphFuzz, a graph-recurrent-neural-network-based approach to gate-level netlist verification. It represents a synthesized netlist as a graph whose nodes carry interface-type, gate-type, and logic-value features; trains a GRNN on logic values extracted from Cadence Xcelium simulations; and then "fuzzes" the trained NetGraph by mutating input bit vectors and comparing predicted node values against RTL simulation. The authors claim an average prediction accuracy of 80% and bug detection accuracy of 70%, and they report two processor-ALU flag bugs plus transient gate-delay mismatches. The evaluation, however, reports node-value classification accuracy rather than bug-level detection rates, and the bug-detection claim is not supported by the experiments as designed.

Significance. If substantiated, a graph-model-based substitute for part of gate-level simulation would be a useful contribution to hardware verification, and the paper is among the first to apply graph learning to gate-level fuzzing. The pipeline is coherent in structure: netlist-to-graph conversion, feature encoding, EDA dataset generation, and inference timing/memory measurements are all described, and Table I gives a concrete architecture. However, because the central bug-detection claim rests on a mislabeled metric and on a comparison that cannot distinguish model error from design flaws, the significance of the approach cannot currently be assessed from the reported evidence.

major comments (4)
  1. [Abstract; §VI-B2; §VI-B3; Table III] The abstract's "bug detection accuracy of 70%" is not a detection rate. In §VI-B2, the mor1kx result is stated as "an approximate accuracy of 70% in predicting the node value associated with the carry flag" on mutated bug-triggering inputs, and §VI-B3 reports an average accuracy of 82.7% for the or1200 overflow flag; Table III likewise reports GRNN node-value classification accuracy. No precision, recall, false-positive count, false-negative count, or held-out bug set is provided, so the paper does not establish that GraphFuzz detects bugs at a 70% rate.
  2. [§IV-E5; §IV-D; §V-b] The bug signal is defined as a mismatch between GRNN predictions and RTL simulation (§IV-E5), but the GRNN is trained on gate-level simulation data from the same netlist (§IV-D and §V-b). A mismatch can therefore be ordinary model approximation error, a coverage artifact of the centrality-based fuzzer, or transient timing behavior; the paper never separates these from real design flaws. This makes the reported "bugs detected" ambiguous and does not support the claim that the mismatches correspond to synthesis-introduced bugs.
  3. [§VI-B4; §VIII-c] The gate-delay bugs are described as transient discrepancies that appear "prior to the stabilization of the correct result," but §VIII(c) states that GraphFuzz's graph model "does not currently account for temporal characteristics, such as timing violations." These transient mismatches are therefore outside the scope of the proposed model and cannot be counted as detections by GraphFuzz; including them in the reported findings inflates the central bug-detection claim.
  4. [§VI; Table III] The evaluation lacks any baseline or ground-truth comparison for the claimed acceleration and detection. There are no results comparing GraphFuzz against gate-level simulation time, against existing RTL fuzzers such as TheHuzz, or against injected faults with known labels. Without such comparisons, the per-node accuracy numbers in Table III do not demonstrate that the approach accelerates verification or that it detects bugs more effectively than existing methods.
minor comments (4)
  1. [§I] The subsection heading "Proposed Work and Key Contributions: :" contains a doubled colon, and the names "GraphFuzz" and "GraphFuzzer" are used inconsistently throughout the text.
  2. [Figures 5 and 6] The x-axis labels in Figures 5 and 6 are badly overlapping and truncated (e.g., "MOR1K XALU"), making the figures difficult to read; a table of inference time and memory consumption would be clearer.
  3. [§VI-B4] "DSA" appears to be a typo for "DSP," since DSP is the design discussed throughout the rest of the paper.
  4. [§IV-E3] The four graph centrality metrics are asserted to be analogous to toggle coverage, but no experiment demonstrates that centrality-based selection actually improves node coverage or bug finding; this connection should be justified or relaxed.

Circularity Check

1 steps flagged · score 6.0 of 10

The abstract's 'bug detection accuracy of 70%' is, by the paper's own evaluation text, a per-node value-prediction accuracy on a known bug-triggering input, not a bug detection rate.

  1. fitted input called prediction [Abstract; Section VI-B2 (mor1kx ALU); Section VI-B3 (or1200 ALU)]
    "Our evaluation ... demonstrates an average prediction accuracy of 80% and bug detection accuracy of 70%. ... Our GraphFuzz model achieved an approximate accuracy of 70% in predicting the node value associated with the carry flag ... we introduced mutations to the bug-triggering input (i.e bit vectors for the sub instruction) and calculated the average accuracy across these variations. ... Our GraphFuzz model was also successful in detecting the incorrect assignment of the overflow flag, achieving an average accuracy of 82.7% across a range of test case scenarios."

    The model's training objective is exactly node-value prediction on gate-level simulation data from the same netlists: Section IV-B states 'Our primary objective is to predict the logic values of nodes in the DUT,' and Section IV-D builds the training set from Cadence gate-level simulations. The abstract's 'bug detection accuracy of 70%' is taken directly from the mor1kx experiment, which measures per-node value-prediction accuracy on mutated versions of a known bug-triggering input for a bug previously reported by TheHuzz [52]. The or1200 'detection' is likewise per-node value-prediction accuracy (82.7%) for the overflow-flag node. Neither metric counts bugs found, false positives, or precision/recall at the bug level, and no held-out bug set or independent bug signal is used.

full rationale

The node-value prediction pipeline itself has independent content: Table III reports classification accuracy, precision, recall, and F1 against gate-level simulation labels, and that benchmark is not circular in itself. However, the paper's headline claim that GraphFuzz 'detects bugs with an average accuracy of 70%' reduces to the mor1kx/or1200 node-value accuracy numbers, which are measured on inputs already known to trigger bugs reported by prior work, with no bug-level detection metric. The reported 'gate delay bugs' are also undermined by Section VIII-c, which states that the graph model does not account for temporal characteristics such as timing violations; that is a correctness inconsistency rather than a circular reduction. The paper's self-citations ([53], [55], [56]) are survey material and not load-bearing for the central claim. Overall, the bug-detection claim partially reduces by construction to a fitted node-prediction metric, while the average node-prediction accuracy retains independent, though weakly validated, content; hence score 6 rather than 0 or 2.

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

No new physical entities are introduced. The trained software model NetGraph is a surrogate artifact without independent falsifiable handles, and the paper provides no evidence that it exists as anything other than a fitted predictor. The load-bearing assumptions are about the graph representation, the coverage analogy, the golden reference model, and neural network generalization.

free parameters (2)
  • GRNN hyperparameters = Table I: GCN layers [128,256,512,256,256], LSTM depth 1, learning rate 0.001, batch size 128, dropout 0.1, RMSprop…
    The model accuracy and bug detection numbers depend on these hand-chosen hyperparameters; no sensitivity analysis or validation procedure is reported, so they are effectively fitted to the benchmark set.
  • training and validation data split and fuzzing seed budget = not specified
    The paper does not report how simulation data was split between training and evaluation, nor how many input seeds or mutations were used, both of which directly affect the reported accuracy.
assumptions (4)
  • domain assumption The gate-level netlist can be represented as an undirected graph whose node features (interface type, gate type, logic value) suffice to reproduce simulation behavior via neighborhood aggregation.
    Sections IV-A and IV-B introduce this representation; the entire GRNN training and inference pipeline depends on it, and no equivalence proof or error analysis is given.
  • domain assumption Graph centrality metrics (degree, betweenness, closeness, eigenvector) are analogous to gate-level toggle coverage and can guide fuzzing toward bug-relevant regions.
    Section IV-E3 asserts the analogy without empirical support or any calibration against actual toggle coverage.
  • domain assumption RTL simulation is a valid golden reference model for detecting gate-level bugs.
    Section IV-E5 uses RTL as the golden reference; this assumes RTL is correct and that any mismatch with gate-level behavior indicates a bug rather than acceptable synthesis or timing effects.
  • domain assumption A GRNN trained on EDA simulation data generalizes to unseen input seeds and can predict node logic values across the whole netlist.
    Sections IV-C and IV-D rely on standard ML generalization; no out-of-distribution or holdout evaluation is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Accelerating Hardware Verification with Graph Models." pith.science (2026). https://pith.science/paper/HCSIRGSJ

@misc{pith2026241213374,
  author       = {Pith},
  title        = {Pith review of: Accelerating Hardware Verification with Graph Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HCSIRGSJ}},
  note         = {Machine review of arXiv:2412.13374}
}
read the original abstract

The increasing complexity of modern processor and IP designs presents significant challenges in identifying and mitigating hardware flaws early in the IC design cycle. Traditional hardware fuzzing techniques, inspired by software testing, have shown promise but face scalability issues, especially at the gate-level netlist where bugs introduced during synthesis are often missed by RTL-level verification due to longer simulation times. To address this, we introduce GraphFuzz, a graph-based hardware fuzzer designed for gate-level netlist verification. In this approach, hardware designs are modeled as graph nodes, with gate behaviors encoded as features. By leveraging graph learning algorithms, GraphFuzz efficiently detects hardware vulnerabilities by analyzing node patterns. Our evaluation across benchmark circuits and open-source processors demonstrates an average prediction accuracy of 80% and bug detection accuracy of 70%, highlighting the potential of graph-based methods for enhancing hardware verification.

Figures

Figures reproduced from arXiv: 2412.13374 by the authors.

Figure 1
Figure 1. Overview of hardware fuzzing, illustrating the selection of different [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of our GraphFuzz Framework. ⃝A Graph Generator (Section IV-A), ⃝B EDA Dataset Generation (Section IV-D), ⃝C GRNN Training (Section IV-C), ⃝D GRNN Inference A. Graph Learning for IC Security Graph Neural Networks (GNNs) have gained significant attention due to their superior performance in graph-based learning tasks, as highlighted in several studies [100]–[105]. The success of GNNs in EDA is largely attribu… view at source ↗
Figure 3
Figure 3. Proposed Graph Node Encoding. GraphFuzz encodes three category [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Overview of Netgraph Fuzzer 3) Coverage:: To ensure that the NetGraph Fuzzer thor￾oughly explores different regions of the graph, we utilize graph node coverage metrics, as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 6
Figure 6. Figure 6: Memory Consumption of various architectures [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 5
Figure 5. Figure 5: Inference time of various architectures seconds. In contrast, smaller circuits such as S5378, S13207, and C5315 have lower latencies. S5378 has an inference latency of 0.457 seconds, S13207 has a latency of 0.421 seconds, and C5315 has a latency of 0.317 seconds. The m…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. Bit-Flip Fault Attack: Crushing Graph Neural Networks via Gradual Bit Search

    cs.LG 2025-07 conditional novelty 5.0 of 10

    GBFA shows GNNs can be degraded by flipping one or a few weight bits in a targeted layer, though the advantage over random flips is marginal at the reported minimum bit error rates.

Reference graph

Works this paper leans on

112 extracted references · 80 canonical work pages · cited by 1 Pith paper

  1. [1]

    Work- flow design and management for IC supply chain,

    J. C. Chen, H. Rau, C.-J. Sun, H.-W. Stzeng, and C.-H. Chen, “Work- flow design and management for IC supply chain,” in International Conference on Networking, Sensing and Control , 2009, pp. 697–701

    2009

  2. [2]

    Apple iPhone 15 Pro Teardown,

    TechInsights, “Apple iPhone 15 Pro Teardown,” last Accessed : 6/1/2024. [Online]. Available: https://www.techinsights.com/blog/ apple-iphone-15-pro-teardown

    2024

  3. [3]

    Broadpwn: Remotely compromising android and iOS via a bug in broadcom’s Wi-Fi chipsets,

    N. Artenstein, “Broadpwn: Remotely compromising android and iOS via a bug in broadcom’s Wi-Fi chipsets,” in BlackHat USA, 2017

    2017

  4. [4]

    Silicon demonstration of hardware trojan design and detection in wireless cryptographic ICs,

    Y . Liu, Y . Jin, A. Nosratinia, and Y . Makris, “Silicon demonstration of hardware trojan design and detection in wireless cryptographic ICs,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems , vol. 25, no. 4, pp. 1506–1519, 2017

    2017

  5. [5]

    Meltdown: Reading kernel memory from user space,

    M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y . Yarom, and M. Hamburg, “Meltdown: Reading kernel memory from user space,” in USENIX Security Symposium, 2018

    2018

  6. [6]

    Spectre attacks: Exploiting speculative execution,

    P. Kocher, J. Horn, A. Fogh, , D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y . Yarom, “Spectre attacks: Exploiting speculative execution,” inIEEE Symposium on Security and Privacy (S&P’19) , 2019

    2019

  7. [7]

    Foreshadow: Extracting the keys to the intel SGX kingdom with transient Out-of- Order execution,

    J. V . Bulck, M. Minkin, O. Weisse, D. Genkin, B. Kasikci, F. Piessens, M. Silberstein, T. F. Wenisch, Y . Yarom, and R. Strackx, “Foreshadow: Extracting the keys to the intel SGX kingdom with transient Out-of- Order execution,” in USENIX Security Symposium , 2018

    2018

  8. [8]

    Zombieload: Cross-privilege-boundary data sampling,

    M. Schwarz, M. Lipp, D. Moghimi, J. Van Bulck, J. Stecklina, T. Prescher, and D. Gruss, “Zombieload: Cross-privilege-boundary data sampling,” in ACM SIGSAC Conference on Computer and Communi- cations Security, 2019

    2019

Show all 112 references
  1. [9]

    Breaking kernel address space layout randomization with intel TSX,

    Y . Jang, S. Lee, and T. Kim, “Breaking kernel address space layout randomization with intel TSX,” in ACM SIGSAC Conference on Computer and Communications Security , 2016

    2016

  2. [10]

    Xen security advisory 7 (CVE-2012-0217) - PV privi- lege escalation,

    R. Wojtczuk, “Xen security advisory 7 (CVE-2012-0217) - PV privi- lege escalation,” last accessed: 11/18/2023. [Online]. Available: https: //lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html

    2012

  3. [11]

    A survey and perspective on electronic design automation tools for ensuring soc security,

    T. Feng, H. Pei, Z. Jin, and X. Wu, “A survey and perspective on electronic design automation tools for ensuring soc security,” in International SoC Design Conference (ISOCC) , 2022

    2022

  4. [12]

    Self- checking performance verification methodology for complex SoCs,

    P. Ghosh, V . N. Dwaraka Mai, A. Chopra, and B. Sood, “Self- checking performance verification methodology for complex SoCs,” in International Symposium on Quality Electronic Design (ISQED) , 2023

    2023

  5. [13]

    Seamless SoC verification using virtual platforms: An industrial case study,

    K. Kang, S. Park, B. Bae, J. Choi, S. Lee, B. Lee, and J.-B. Lee, “Seamless SoC verification using virtual platforms: An industrial case study,” in Design, Automation & Test in Europe Conference & Exhibition (DATE), 2019

    2019

  6. [14]

    SoC trust validation using assertion-based security monitors,

    K. Alatoun, B. Shankaranarayanan, S. M. Achyutha, and R. Vemuri, “SoC trust validation using assertion-based security monitors,” in International Symposium on Quality Electronic Design (ISQED), 2021

    2021

  7. [15]

    Accelerating SoC security verification and vulnerability detection through symbolic execution,

    S. Tang, X. Wang, Y . Gao, and W. Hu, “Accelerating SoC security verification and vulnerability detection through symbolic execution,” in International SoC Design Conference (ISOCC) , 2022

    2022

  8. [16]

    Pre-silicon DFT verification on SoC slim model,

    P. Mohandoss and A. Rengaraj, “Pre-silicon DFT verification on SoC slim model,” in International Workshop on Microprocessor and SOC Test and Verification (MTV), 2018

    2018

  9. [17]

    An 80-tile sub-100-w ter- aFLOPS processor in 65-nm CMOS,

    S. R. Vangal, J. Howard, G. Ruhl, S. Dighe, H. Wilson, J. Tschanz, D. Finan, A. Singh, T. Jacob, S. Jain, V . Erraguntla, C. Roberts, Y . Hoskote, N. Borkar, and S. Borkar, “An 80-tile sub-100-w ter- aFLOPS processor in 65-nm CMOS,” IEEE Journal of Solid-State Circuits, vol. 4...

    2008

  10. [18]

    Rethink- ing watermark: Providing proof of IP ownership in modern SoCs,

    N. N. Anandakumar, M. S. Rahman, M. M. M. Rahman, R. Kibria, U. Das, F. Farahmandi, F. Rahman, and M. M. Tehranipoor, “Rethink- ing watermark: Providing proof of IP ownership in modern SoCs,” Cryptology ePrint Archive, Paper 2022/092, 2022

    2022

  11. [19]

    From cryptography to logic locking: A survey on the architecture evolution of secure scan chains,

    K. Z. Azar, H. M. Kamali, H. Homayoun, and A. Sasan, “From cryptography to logic locking: A survey on the architecture evolution of secure scan chains,” IEEE Access, 2021

    2021

  12. [20]

    Forte, S

    D. Forte, S. Bhunia, and M. M. Tehranipoor, Hardware Protection through Obfuscation, 2017

    2017

  13. [21]

    Security analysis of integrated circuit camouflaging,

    J. Rajendran, M. Sam, O. Sinanoglu, and R. Karri, “Security analysis of integrated circuit camouflaging,” Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security , 2013

    2013

  14. [22]

    Property learning techniques for efficient generation of directed tests,

    M. Chen and P. Mishra, “Property learning techniques for efficient generation of directed tests,” IEEE Transactions on Computers, vol. 60, no. 6, pp. 852–864, Feb 2011

    2011

  15. [23]

    Hardware verification us- ing software analyzers,

    R. Mukherjee, D. Kroening, and T. Melham, “Hardware verification us- ing software analyzers,” in IEEE Computer Society Annual Symposium on VLSI, 2015

    2015

  16. [24]

    Hardfails: Insights into software-exploitable hardware bugs,

    G. Dessouky, D. Gens, P. Haney, G. Persyn, A. Kanuparthi, H. Khattri, J. M. Fung, A.-R. Sadeghi, and J. Rajendran, “Hardfails: Insights into software-exploitable hardware bugs,” in USENIX Conference on Security Symposium, 2019

    2019

  17. [25]

    Phoenix: Detecting and recovering from permanent processor design bugs with programmable hardware,

    S. R. Sarangi, A. Tiwari, and J. Torrellas, “Phoenix: Detecting and recovering from permanent processor design bugs with programmable hardware,” in IEEE/ACM International Symposium on Microarchitec- ture, 2006

    2006

  18. [26]

    Engineering trust with semantic guardians,

    I. Wagner and V . Bertacco, “Engineering trust with semantic guardians,” in Design, Automation & Test in Europe Conference & Exhibition, 2007

    2007

  19. [27]

    Tightly integrate dynamic verification with formal verification: a GSTE based approach,

    J. Yang and A. Puder, “Tightly integrate dynamic verification with formal verification: a GSTE based approach,” in Asia and South Pacific Design Automation Conference , 2005

    2005

  20. [28]

    Transaction level stim- ulus optimization in functional verification using machine learning predictors,

    S. Gogri, A. Tyagi, M. Quinn, and J. Hu, “Transaction level stim- ulus optimization in functional verification using machine learning predictors,” in International Symposium on Quality Electronic Design (ISQED), 2022

    2022

  21. [29]

    Increasing the efficiency of simulation-based functional verification through unsuper- vised support vector analysis,

    O. Guzey, L.-C. Wang, J. R. Levitt, and H. Foster, “Increasing the efficiency of simulation-based functional verification through unsuper- vised support vector analysis,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 29, no. 1, pp. 138–148, 2010

    2010

  22. [30]

    Questa advanced verification,

    Siemens, “Questa advanced verification,” last accessed: 11/18/2023. [Online]. Available: https://eda.sw.siemens.com/en-US/ic/questa/

    2023

  23. [31]

    Symbiyosys documentation,

    Yosys, “Symbiyosys documentation,” last accessed: 11/18/2023. [Online]. Available: https://symbiyosys.readthedocs.io/en/latest/

    2023

  24. [32]

    of California Berkley, “ABC,” last Accessed : 6/1/2024

    U. of California Berkley, “ABC,” last Accessed : 6/1/2024. [Online]. Available: https://people.eecs.berkeley.edu/∼alanmi/abc/

    2024

  25. [33]

    Smt attack: Next generation attack on obfuscated circuits with capabilities and performance beyond the sat attacks,

    K. Z. Azar, H. M. Kamali, H. Homayoun, and A. Sasan, “Smt attack: Next generation attack on obfuscated circuits with capabilities and performance beyond the sat attacks,” IACR Trans. Cryptogr. Hardw. Embed. Syst., pp. 97–122, 2018

    2018

  26. [34]

    Nngsat: Neural network guided sat attack on logic locked complex structures,

    ——, “Nngsat: Neural network guided sat attack on logic locked complex structures,” in 2020 IEEE/ACM International Conference On Computer Aided Design (ICCAD) , 2020

    2020

  27. [35]

    Warm up before circuit de-obfuscation? an exploration through bounded- model-checkers,

    K. Z. Azar, H. M. Kamali, F. Farahmandi, and M. Tehranipoor, “Warm up before circuit de-obfuscation? an exploration through bounded- model-checkers,” in 2022 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , 2022

    2022

  28. [36]

    Towards prop- erty driven hardware security,

    W. Hu, A. Althoff, A. Ardeshiricham, and R. Kastner, “Towards prop- erty driven hardware security,” in 2016 17th International Workshop on Microprocessor and SOC Test and Verification (MTV) , 2016

    2016

  29. [37]

    Enforcing information flow guarantees in reconfigurable systems with mix-trusted ip,

    R. Kastner, J. Oberg, W. Hu, and A. Irturk, “Enforcing information flow guarantees in reconfigurable systems with mix-trusted ip,” 2011

    2011

  30. [38]

    Gate level information flow analysis for multi-valued logic system,

    Y . Tai, W. Hu, L. Guo, B. Mao, and D. Mu, “Gate level information flow analysis for multi-valued logic system,” 2017 2nd International Conference on Image, Vision and Computing (ICIVC)

    2017

  31. [39]

    Ac- celerating coverage directed test generation for functional verification: A neural network-based framework,

    F. Wang, H. Zhu, P. Popli, Y . Xiao, P. Bodgan, and S. Nazarian, “Ac- celerating coverage directed test generation for functional verification: A neural network-based framework,” in Great Lakes Symposium on VLSI, 2018

    2018

  32. [40]

    Crafting a usable micro- kernel, processor, and I/O system with strict and provable information flow security,

    M. Tiwari, J. K. Oberg, X. Li, J. Valamehr, T. Levin, B. Hardekopf, R. Kastner, F. T. Chong, and T. Sherwood, “Crafting a usable micro- kernel, processor, and I/O system with strict and provable information flow security,” in International Symposium on Computer Architecture (I...

    2011

  33. [41]

    Register transfer level information flow tracking for provably secure hardware design,

    A. Ardeshiricham, W. Hu, J. Marxen, and R. Kastner, “Register transfer level information flow tracking for provably secure hardware design,” in Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017

    2017

  34. [42]

    Caisson: A hardware description language for secure information flow,

    X. Li, M. Tiwari, J. K. Oberg, V . Kashyap, F. T. Chong, T. Sherwood, and B. Hardekopf, “Caisson: A hardware description language for secure information flow,” SIGPLAN Not. , vol. 46, no. 6, p. 109–120, June 2011

    2011

  35. [43]

    Sap- per: A language for hardware-level security policy enforcement,

    X. Li, V . Kashyap, J. K. Oberg, M. Tiwari, V . R. Rajarathinam, R. Kastner, T. Sherwood, B. Hardekopf, and F. T. Chong, “Sap- per: A language for hardware-level security policy enforcement,” in International Conference on Architectural Support for Programming Languages and Op...

    2014

  36. [44]

    A hardware design language for timing-sensitive information-flow security,

    D. Zhang, Y . Wang, G. E. Suh, and A. C. Myers, “A hardware design language for timing-sensitive information-flow security,” in International Conference on Architectural Support for Programming Languages and Operating Systems , 2015

    2015

  37. [45]

    RTL-contest: Concolic testing on RTL for detecting security vulnerabilities,

    X. Meng, S. Kundu, A. K. Kanuparthi, and K. Basu, “RTL-contest: Concolic testing on RTL for detecting security vulnerabilities,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 41, no. 3, pp. 466–477, 2022

    2022

  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,” in IEEE/ACM Interna- tional Conference on Computer-Aided Design (ICCAD) , 2018

    2018

  39. [47]

    Symbolic simulation enhanced coverage-directed fuzz testing of RTL design,

    T. Li, H. Zou, L. D, and Q. W, “Symbolic simulation enhanced coverage-directed fuzz testing of RTL design,” in IEEE International Symposium on Circuits and Systems (ISCAS) , 2021

    2021

  40. [48]

    DifuzzRTL: Differential fuzz testing to find CPU bugs,

    J. Hur, S. Song, D. Kwon, E. Baek, J. Kim, and B. Lee, “DifuzzRTL: Differential fuzz testing to find CPU bugs,” in IEEE Symposium on Security and Privacy (SP) , 2021

    2021

  41. [49]

    Fuzzing hardware like software,

    T. Trippel, K. G. Shin, A. Chernyakhovsky, G. Kelly, D. Rizzo, and M. Hicks, “Fuzzing hardware like software,” in USENIX Security Symposium (USENIX Security) , 2022

    2022

  42. [50]

    Hyperfuzzing for SoC security validation,

    S. K. Muduli, G. Takhar, and P. Subramanyan, “Hyperfuzzing for SoC security validation,” in IEEE/ACM International Conference On Computer Aided Design (ICCAD) , 2020

    2020

  43. [51]

    Effec- tive processor verification with logic fuzzer enhanced co-simulation,

    N. Kabylkas, T. Thorn, S. Srinath, P. Xekalakis, and J. Renau, “Effec- tive processor verification with logic fuzzer enhanced co-simulation,” in IEEE/ACM International Symposium on Microarchitecture , 2021

    2021

  44. [52]

    TheHuzz: Instruction fuzzing of processors using Golden-Reference models for finding Software-Exploitable vulnerabil- ities,

    R. Kande, A. Crump, G. Persyn, P. Jauernig, A.-R. Sadeghi, A. Tyagi, and J. Rajendran, “TheHuzz: Instruction fuzzing of processors using Golden-Reference models for finding Software-Exploitable vulnerabil- ities,” in USENIX Security Symposium (USENIX Security) , 2022

    2022

  45. [53]

    The fuzz odyssey: A survey on hardware fuzzing frameworks for hardware design verifica- tion,

    R. Saravanan and S. M. Pudukotai Dinakarrao, “The fuzz odyssey: A survey on hardware fuzzing frameworks for hardware design verifica- tion,” in Proceedings of the Great Lakes Symposium on VLSI 2024 , ser. GLSVLSI ’24. Association for Computing Machinery, 2024

    2024

  46. [54]

    Special ses- sion: Detecting and defending vulnerabilities in heterogeneous and monolithic systems: Current strategies and future directions,

    V . N. Patnala, S. M. P. Dinakarrao, G. Venkataramani, J. Chen, P. Derasari, M. Doroslovacki, F. Yao, H. Fang, M. Demissie, T. Austin, L. Biernacki, S. Upadhyay, A. Kalita, and A. Venkat, “Special ses- sion: Detecting and defending vulnerabilities in heterogeneous and monolith...

    2024

  47. [55]

    Exploring coverage metrics in hardware fuzzing: A comprehensive analysis,

    R. Saravanan and S. M. Pudukotai Dinakarrao, “Exploring coverage metrics in hardware fuzzing: A comprehensive analysis,” ser. GLSVLSI ’24. Association for Computing Machinery, 2024, p. 240–245

    2024

  48. [56]

    The emergence of hardware fuzzing: A critical review of its significance,

    R. Saravanan and S. M. P. Dinakarrao, “The emergence of hardware fuzzing: A critical review of its significance,” 2024. [Online]. Available: https://arxiv.org/abs/2403.12812

    2024 arXiv

  49. [57]

    OSS-Fuzz - google’s continuous fuzzing service for open source software,

    K. Serebryany, “OSS-Fuzz - google’s continuous fuzzing service for open source software,” in USENIX Security Symposium , 2017

    2017

  50. [58]

    Microsoft security risk detection,

    Microsoft, “Microsoft security risk detection,” last Accessed : 6/1/2024. [Online]. Available: https://www.microsoft.com/en-us/research/project/ project-springfield/

    2024

  51. [59]

    Americal fuzzy loop,

    Google, “Americal fuzzy loop,” last Accessed : 6/1/2024. [Online]. Available: https://github.com/google/AFL

    2024

  52. [60]

    HyPFuzz: Formal-Assisted processor fuzzing,

    C. Chen, R. Kande, N. Nguyen, F. Andersen, A. Tyagi, A.-R. Sadeghi, and J. Rajendran, “HyPFuzz: Formal-Assisted processor fuzzing,” 2023, pp. 1361–1378

    2023

  53. [61]

    Processorfuzz: Processor fuzzing with control and status registers guidance,

    S. Canakci, C. Rajapaksha, L. Delshadtehrani, A. Nataraja, M. Taylor, M. Egele, and A. Joshi, “Processorfuzz: Processor fuzzing with control and status registers guidance,” in IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , 2023

    2023

  54. [62]

    [Online]

    Openhwgroup, last Accessed : 6/1/2024. [Online]. Available: https: //github.com/openhwgroup/cva6

    2024

  55. [63]

    R.-V . W. Group, “Risc-v,” last accessed: 11/18/2023. [Online]. Available: https://riscv.org/

    2023

  56. [64]

    Openrisc,

    O. W. Group, “Openrisc,” last accessed: 11/18/2023. [Online]. Available: https://openrisc.io/

    2023

  57. [65]

    mor1kx - an openrisc processor IP core,

    OpenRISC, “mor1kx - an openrisc processor IP core,” last accessed: 11/18/2023. [Online]. Available: https://github.com/openrisc/mor1kx

    2023

  58. [66]

    Sigfuzz: A framework for discovering microarchitectural timing side channels,

    C. Rajapaksha, L. Delshadtehrani, M. Egele, and A. Joshi, “Sigfuzz: A framework for discovering microarchitectural timing side channels,” 2023

    2023

  59. [67]

    Directfuzz: Automated test generation for rtl designs using directed graybox fuzzing,

    S. Canakci, L. Delshadtehrani, F. Eris, M. B. Taylor, M. Egele, and A. Joshi, “Directfuzz: Automated test generation for rtl designs using directed graybox fuzzing,” in 2021 58th ACM/IEEE Design Automation Conference (DAC), 2021, pp. 529–534

    2021

  60. [68]

    Hyperproperties,

    M. R. Clarkson and F. B. Schneider, “Hyperproperties,” in 2008 21st IEEE Computer Security Foundations Symposium , 2008, pp. 51–65

    2008

  61. [69]

    Towards automatic property generation for soc security verification,

    X. Wang, S. Tang, and W. Hu, “Towards automatic property generation for soc security verification,” 2022 19th International SoC Design Conference (ISOCC), 2022

    2022

  62. [70]

    SoC security verification using property checking,

    N. Farzana, F. Rahman, M. Tehranipoor, and F. Farahmandi, “SoC security verification using property checking,” in IEEE International Test Conference (ITC), 2019

    2019

  63. [71]

    Opentitan,

    Google, “Opentitan,” last Accessed : 6/1/2024. [Online]. Available: https://opentitan.org/

    2024

  64. [72]

    Oss-fuzz,

    “Oss-fuzz,” last Accessed : 6/1/2024. [Online]. Available: https: //google.github.io/oss-fuzz/

    2024

  65. [73]

    B. Wile, J. Goss, and W. Roesner, Comprehensive Functional Verifi- cation: The Complete Industry Cycle . Morgan Kaufmann Publishers Inc., 2005

    2005

  66. [74]

    E. M. Clarke, W. Klieber, M. Nov ´aˇcek, and P. Zuliani, Model Checking and the State Explosion Problem . Springer, 2012, pp. 1–30

    2012

  67. [75]

    SPECS: A lightweight runtime mechanism for protecting software from security- critical processor bugs,

    M. Hicks, C. Sturton, S. T. King, and J. M. Smith, “SPECS: A lightweight runtime mechanism for protecting software from security- critical processor bugs,” SIGPLAN Not. , vol. 50, no. 4, p. 517–529, Mar 2015

    2015

  68. [76]

    Automatic code converter enhanced pch framework for soc trust verification,

    X. Guo, R. G. Dutta, P. Mishra, and Y . Jin, “Automatic code converter enhanced pch framework for soc trust verification,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems , vol. 25, no. 12, pp. 3390–3400, 2017

    2017

  69. [77]

    Pch framework for ip runtime security verification,

    X. Guo, R. G. Dutta, J. He, and Y . Jin, “Pch framework for ip runtime security verification,” in 2017 Asian Hardware Oriented Security and Trust Symposium (AsianHOST) , 2017, pp. 79–84

    2017

  70. [78]

    Eliminating the hardware-software boundary: A proof-carrying approach for trust evaluation on computer systems,

    X. Guo, R. G. Dutta, and Y . Jin, “Eliminating the hardware-software boundary: A proof-carrying approach for trust evaluation on computer systems,” IEEE Transactions on Information Forensics and Security , vol. 12, no. 2, pp. 405–417, 2017

    2017

  71. [79]

    Trojan localization using symbolic algebra,

    F. Farahmandi, Y . Huang, and P. Mishra, “Trojan localization using symbolic algebra,” in 2017 22nd Asia and South Pacific Design Automation Conference (ASP-DAC), 2017, pp. 591–597

    2017

  72. [80]

    Bounded model checking,

    A. Biere, A. Cimatti, E. M. Clarke, O. Strichman, and Y . Zhu, “Bounded model checking,” ser. Advances in Computers. Elsevier, 2003, pp. 117–148

    2003

  73. [81]

    Proof-carrying hardware: Runtime formal verification for secure dynamic reconfiguration,

    S. Drzevitzky, “Proof-carrying hardware: Runtime formal verification for secure dynamic reconfiguration,” in 2010 International Conference on Field Programmable Logic and Applications , 2010, pp. 255–258

    2010

  74. [82]

    Z3: An Efficient SMT Solver,

    L. De Moura and N. Bjørner, “Z3: An Efficient SMT Solver,” in Proceedings of the Theory and Practice of Software, 14th International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Springer-Verlag, 2008, p. 337–340

    2008

  75. [83]

    Welcome to verilator,

    Verilator, “Welcome to verilator,” last accessed: 11/18/2023. [Online]. Available: https://www.veripool.org/verilator/

    2023

  76. [84]

    WhisperFuzz: White-Box Fuzzing for Detecting and Locating Timing Vulnerabilities in Processors,

    P. Borkar, C. Chen, M. Rostami, N. Singh, R. Kande, A.-R. Sadeghi, C. Rebeiro, and J. Rajendran, “WhisperFuzz: White-Box Fuzzing for Detecting and Locating Timing Vulnerabilities in Processors,” arXiv preprint arXiv:2402.03704, 2024

    2024 arXiv

  77. [85]

    Synopsys webpage,

    Synopsys, “Synopsys webpage,” last accessed: 11/18/2023. [Online]. Available: https://www.synopsys.com/

    2023

  78. [86]

    Security-aware fsm design flow for identifying and mitigating vulnerabilities to fault attacks,

    A. Nahiyan, F. Farahmandi, P. Mishra, D. Forte, and M. M. Tehranipoor, “Security-aware fsm design flow for identifying and mitigating vulnerabilities to fault attacks,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 38, pp. 1003–1016, 2019...

    2019

  79. [87]

    Designing trusted embedded systems from finite state machines,

    C. Dunbar and G. Qu, “Designing trusted embedded systems from finite state machines,” ACM Trans. Embed. Comput. Syst. , vol. 13, pp. 153:1–153:20, 2014. [Online]. Available: https://api.semanticscholar. org/CorpusID:14568179

    2014

  80. [88]

    Cascade: Cpu fuzzing via intricate program generation,

    F. Solt, K. Ceesay-Seitz, and K. Razavi, “Cascade: Cpu fuzzing via intricate program generation,” in USENIX Security Symposium , 2024

    2024

  81. [89]

    Analyzing circuit vulnerability to hardware trojan insertion at the behavioral level,

    H. Salmani and M. Tehranipoor, “Analyzing circuit vulnerability to hardware trojan insertion at the behavioral level,” in 2013 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFTS) , 2013

    2013

  82. [90]

    Kaeslin, Digital Integrated Circuit Design: From VLSI Architectures to CMOS Fabrication , 2008

    H. Kaeslin, Digital Integrated Circuit Design: From VLSI Architectures to CMOS Fabrication , 2008

    2008

  83. [91]

    Multi-objective hypergraph parti- tioning algorithms for cut and maximum subdomain degree minimiza- tion,

    N. Selvakkumaran and G. Karypis, “Multi-objective hypergraph parti- tioning algorithms for cut and maximum subdomain degree minimiza- tion,” in International Conference on Computer Aided Design , 2003

    2003

  84. [92]

    Congestion-constrained layer assign- ment for via minimization in global routing,

    T.-H. Lee and T.-C. Wang, “Congestion-constrained layer assign- ment for via minimization in global routing,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 27, no. 9, pp. 1643–1656, 2008

    2008

  85. [93]

    Inductive representation learning on large graphs,

    W. L. Hamilton, R. Ying, and J. Leskovec, “Inductive representation learning on large graphs,” in International Conference on Neural Information Processing Systems , 2017

    2017

  86. [94]

    Graph convolutional neural networks for web-scale recommender systems,

    R. Ying, R. He, K. Chen, P. Eksombatchai, W. L. Hamilton, and J. Leskovec, “Graph convolutional neural networks for web-scale recommender systems,” in ACM SIGKDD International Conference on Knowledge Discovery & Data Mining , 2018

    2018

  87. [95]

    Learning- based power/performance optimization for many-core systems with extended-range voltage/frequency scaling,

    E. Cai, D.-C. Juan, S. Garg, J. Park, and D. Marculescu, “Learning- based power/performance optimization for many-core systems with extended-range voltage/frequency scaling,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 35, no. 8, pp. 13...

    2016

  88. [96]

    Cross-layer optimization for high speed adders: A pareto driven machine learning approach,

    Y . Ma, S. Roy, J. Miao, J. Chen, and B. Yu, “Cross-layer optimization for high speed adders: A pareto driven machine learning approach,” Trans. Comp.-Aided Des. Integ. Cir. Sys., vol. 38, no. 12, p. 2298–2311, Dec 2019

    2019

  89. [97]

    Deep learning for logic optimization algorithms,

    W. Haaswijk, E. Collins, B. Seguin, M. Soeken, F. Kaplan, S. S¨usstrunk, and G. De Micheli, “Deep learning for logic optimization algorithms,” in IEEE International Symposium on Circuits and Systems (ISCAS), 2018

    2018

  90. [98]

    Routenet: Routability prediction for mixed-size designs using convolutional neural network,

    Z. Xie, Y .-H. Huang, G.-Q. Fang, H. Ren, S.-Y . Fang, Y . Chen, and J. Hu, “Routenet: Routability prediction for mixed-size designs using convolutional neural network,” in IEEE/ACM International Conference on Computer-Aided Design (ICCAD) , 2018

    2018

  91. [99]

    BEOL stack-aware routability prediction from placement using data mining techniques,

    W.-T. J. Chan, Y . Du, A. B. Kahng, S. Nath, and K. Samadi, “BEOL stack-aware routability prediction from placement using data mining techniques,” in IEEE International Conference on Computer Design (ICCD), 2016

    2016

  92. [100]

    A comprehensive survey of graph embedding: Problems, techniques, and applications,

    H. Cai, V . W. Zheng, and K. Chang, “A comprehensive survey of graph embedding: Problems, techniques, and applications,” IEEE Transactions on Knowledge and Data Engineering , vol. 30, no. 09, pp. 1616–1637, sep 2018

    2018

  93. [101]

    Node2vec: Scalable feature learning for networks,

    A. Grover and J. Leskovec, “Node2vec: Scalable feature learning for networks,” in ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , 2016

    2016

  94. [102]

    Layout decomposition approaches for double patterning lithography,

    A. B. Kahng, C.-H. Park, X. Xu, and H. Yao, “Layout decomposition approaches for double patterning lithography,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , vol. 29, no. 6, pp. 939–952, 2010

    2010

  95. [103]

    Layout decom- position for triple patterning lithography,

    B. Yu, K. Yuan, B. Zhang, D. Ding, and D. Z. Pan, “Layout decom- position for triple patterning lithography,” in IEEE/ACM International Conference on Computer-Aided Design (ICCAD) , 2011

    2011

  96. [104]

    Timing-driven test point insertion for full- scan and partial-scan BIST,

    K.-T. Cheng and C.-J. Lin, “Timing-driven test point insertion for full- scan and partial-scan BIST,” in IEEE International Test Conference (ITC), 1995

    1995

  97. [105]

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

    M. A. A. F. Rozhin Yasaei, Shih-Yuan Yu, “GNN4TJ: Graph neural networks for hardware trojan detection at register transfer level,” in IEEE/ACM Design Automation and Test in Europe (DATE) , 2021

    2021

  98. [106]

    Grarep: Learning graph representations with global structural information,

    S. Cao, W. Lu, and Q. Xu, “Grarep: Learning graph representations with global structural information,” in ACM International on Confer- ence on Information and Knowledge Management , 2015

    2015

  99. [107]

    Routability optimization for industrial designs at sub-14nm process nodes using machine learning,

    W.-T. J. Chan, P.-H. Ho, A. B. Kahng, and P. Saxena, “Routability optimization for industrial designs at sub-14nm process nodes using machine learning,” in ACM International Symposium on Physical Design, 2017

    2017

  100. [108]

    Accurate machine- learning-based on-chip router modeling,

    K. Jeong, A. B. Kahng, B. Lin, and K. Samadi, “Accurate machine- learning-based on-chip router modeling,” IEEE Embedded Systems Letters, vol. 2, no. 3, pp. 62–66, 2010

    2010

  101. [109]

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

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

    2021

  102. [110]

    Hw2vec: a graph learning tool for automating hardware security,

    S. Y . Yu, R. Yasaei, Q. Zhou, T. Nguyen, and M. A. A. Faruque, “Hw2vec: a graph learning tool for automating hardware security,” 2021 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , 2021

    2021

  103. [111]

    Machine learning and structural characteristics for reverse engineering,

    J. Baehr, A. Bernardini, G. Sigl, and U. Schlichtmann, “Machine learning and structural characteristics for reverse engineering,” 2019 24th Asia and South Pacific Design Automation Conference (ASP- DAC), 2019

    2019

  104. [112]

    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,” in Design, Automation & Test in Europe Conference & Exhibition (DATE) , 2023

    2023

Pith tools

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