Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

AssertCoder: LLM-Based Assertion Generation via Multimodal Specification Extraction

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

Pith's one-line read The paper claims that high-quality SystemVerilog assertions can be generated directly from multimodal hardware specifications, without reading the RTL, and reports that its pipeline raises functional correctness by 8.4% and mutation…

desk verdict Solid pipeline with a load-bearing evaluation flaw: the MDR result is measured on the same mutation set used for refinement. read the letter →

arxiv 2507.10338 v1 pith:R77MFT34 submitted 2025-07-14 cs.SE cs.ARcs.LO

classification cs.SEcs.ARcs.LO
keywords assertion-basedverificationSystemVerilogassertionshardwareformallargelanguagemodelsmultimodalspecificationextractionchain-of-thoughtpromptingmutationtestingretrieval-augmentedgeneration
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

The paper is trying to establish that high-quality SystemVerilog assertions can be generated automatically from hardware design specifications as they actually appear in engineering documents: mixtures of text, tables, diagrams, and formulas. The proposed pipeline first classifies each block of a specification by modality and semantic role, then uses dedicated analyzers to convert each modality into a unified, signal-level structured description. From that description, a large language model produces assertions through a four-step chain-of-thought procedure, and a mutation-based evaluation loop detects which assertions miss seeded bugs and regenerates them. Across three open-source RTL designs, the paper reports an average functional-correctness rate of 87.6% versus 79.2% for the strongest prior method, and a mutation detection rate of 85.6% versus 79.8%. If the result holds, verification engineers could start from the specification document itself rather than from RTL code or hand-written properties.

What carries the argument

The load-bearing mechanism is the unified semantic specification: a merged, signal-centered structured representation built from text, table, diagram, and formula analyzers. It carries the argument because it converts heterogeneous PDF content into the same shape the assertion generator consumes, making signal names, directions, FSM transitions, timing constraints, and source locations jointly visible. Around that object, the pipeline runs two further mechanisms: a four-step chain-of-thought SVA synthesis step (semantic decomposition, pattern selection, temporal binding, syntax synthesis) and a mutation-guided refinement loop in which model checking scores each assertion against injected mutations, low-scoring assertions are removed, and undetected mutations are fed back as cues for regeneration.

What would settle it

Run a mutation campaign in which the injected mutants are split before refinement: use one subset to guide regeneration and a disjoint held-out subset to compute the final mutation detection rate. If the held-out detection improvement over the no-refinement baseline is small or zero, the claim that mutation-guided refinement improves generalization to new bugs is refuted.

Watch

Extended reading notes

Core claim

AssertCoder's central claim is that the semantic gap between multimodal specifications and SystemVerilog assertions can be closed by a four-stage pipeline that does not need RTL code. Preprocessing segments the specification and labels each block by modality and semantic category; dedicated analyzers for text, tables, formulas, and diagrams extract signal-level facts; those facts are merged into one structured specification that groups every signal's attributes, behavior, timing, and source traceability. A retrieval-augmented chain-of-thought prompt then decomposes each signal's intended behavior into precondition, consequence, and timing, selects an assertion pattern, binds temporal operators, and emits SVA syntax. Finally, model checking against injected mutations produces a per-assertion mutation score and a mutation detection rate; assertions that detect nothing are dropped, and undetected mutations are fed back to trigger a new generation round. The paper reports that on three real-world designs this yields 97.8% syntactically correct assertions, 87.6% functionally correct assertions, 85.6% mutation detection, and a 3.2% false-positive rate.

Load-bearing premise

The load-bearing premise is that the mutation detection rate measured on the exact mutations used to guide regeneration will also hold for bugs the framework has never seen; if regeneration only imprinted those specific mutations, the reported gain would not transfer to new fault classes.

Editorial extensions

If this is right

  • Verification teams could generate a first-pass assertion suite from specification documents alone, before or without RTL, reducing the manual bottleneck in assertion-based verification.
  • Because the pipeline removes assertions that fail on the original design and drops detection-free assertions, the final set has a reported false-positive rate around 3%, making the suite usable as a regression monitor.
  • The ablation study attributes the largest mutation-detection loss to removing iterative refinement, so feedback of this kind belongs in LLM-based assertion generators even when the initial prompt is strong.
  • The reported functional-correctness gap (87.6% versus 79.2%) points to temporal binding and pattern selection as the steps where the four-step prompt adds the most value.

Reading between the lines

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

  • Beyond the paper's claims, the unified semantic specification could be reused for other formal artefacts such as PSL properties, coverage goals, or interface contracts, because it already separates precondition, consequence, and timing.
  • A testable extension would be to split injected mutations into a guidance set and a held-out set; if the reported 5.8 percentage-point mutation-detection gain survives on the held-out set, mutation-guided refinement generalizes to unseen bug classes, and if not, the gain is partly an artifact of fitting the guide mutations.
  • The ablation's finding that retrieval-augmented generation is the least critical component suggests a simpler pipeline with static SVA reference templates could retain most of the functional-correctness benefit.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The manuscript presents AssertCoder, a framework for generating SystemVerilog assertions (SVAs) from multimodal hardware design specifications. The pipeline consists of four stages: modality-aware preprocessing of PDF specification blocks, multimodal information extraction via specialized analyzers for text, tables, diagrams, and formulas, a retrieval-augmented multi-step chain-of-thought prompting stage for SVA synthesis, and a mutation-guided evaluation-and-refinement loop based on model checking. The paper reports experiments on three open-source RTL designs (I2C master, AES core, Openmsp430) and compares against AssertLLM and zero-shot GPT-4o, claiming average improvements of 8.4% in functional correctness and 5.8% in mutation detection rate (MDR).

Significance. If the reported results were valid, the framework would be a useful contribution to assertion-based verification, since it addresses a real bottleneck: extracting formal assertions from heterogeneous specification documents. The paper is well structured, the prompt templates are concrete and reproducible, and the use of model checking and mutation testing is methodologically appropriate. However, the central quantitative claims are not currently supported because the mutation-guided refinement stage is evaluated on the same mutation set that provides feedback for refinement, which confounds the reported MDR improvement. The evaluation also lacks statistical controls, exact mutation counts, and a precise definition of functional correctness. The framework itself is plausible, but the experimental evidence as presented cannot establish superiority over the baselines.

major comments (4)
  1. [Section III-E, Eq. (4), and Table II] The MDR metric in Eq. (4) is defined over the mutation set M, and the surrounding text states that when MDR < 1, the mutation traces and logs are used as feedback to regenerate SVAs. Table II then reports MDR values after this refinement loop over the same mutation set M. This means the reported MDR measures how well the assertions fit the specific mutants that were used to guide generation, not how well they generalize to previously unseen faults. The paper does not describe any held-out mutant partition or separate validation set. Because the 5.8% mutation-detection improvement is one of the two headline claims, this evaluation leak is load-bearing. To support the claim, the authors should report MDR on a disjoint held-out mutation set, or split the mutants into a refinement set and a validation set and report MDR only on the latter.
  2. [Section IV-A and Section III-E] The comparison is asymmetric: AssertCoder receives iterative feedback from model-checking failures on the mutation set, while the baselines AssertLLM and GPT-4o are not given any mutation feedback. With only three designs, the reported 5.8 percentage-point MDR advantage could reflect optimization against the evaluation mutants rather than intrinsic superiority. The paper should report AssertCoder's MDR before any refinement, compare against baselines run under the same feedback protocol, or otherwise demonstrate that the improvement is not an artifact of test-set optimization.
  3. [Section IV-A and Section IV-B, Table II] The experimental evaluation lacks statistical support. Only three RTL designs are tested, no error bars or standard deviations are reported for any metric, and no statistical significance tests are performed. The paper states only that 'approximately 100–300' mutants are generated per DUT, without giving exact counts or per-DUT mutation operators. Figures 2 and 3 similarly report ablation effects without error bars or numerical tables. The authors should provide exact mutation counts, repeat generation across multiple seeds or prompt variations, and report variance and significance information.
  4. [Section IV-B and Table II] The metric 'functional correctness' is used as a headline result (8.4% improvement) but is never precisely defined. It is unclear whether functional correctness is determined by model checking against a golden property set, by manual review of each assertion against the specification, or by some other procedure. Since this is the other headline claim, the paper must specify the evaluation protocol for functional correctness, including who performed the assessment and what criteria were used.
minor comments (4)
  1. [Throughout] The manuscript contains several formatting and typographical issues, such as inconsistent spacing in 'SV As', 'Listing5' missing a space, and inconsistent use of 'MDR' and 'Mutation detection Rate' capitalization. These should be cleaned up.
  2. [Section IV-A] The description 'approximately 100–300 mutants are generated per DUT' is vague; the exact number of mutants and the mutation operators used by Mantra for each design should be reported to allow reproducibility.
  3. [Table I] The column 'Testbench Scale' is not clearly defined, and the entries 'Small-scale', 'Mid-scale', and 'Full-scale' lack a stated scale definition. Clarify what determines the scale.
  4. [References] Some references appear incomplete or inconsistently formatted, for example [14] lacks full page numbers, and [25] uses nonstandard capitalization in the title. The reference list should be checked against the venue styles.

Circularity Check

1 steps flagged · score 7.0 of 10

Mutation-guided refinement optimizes assertions using the exact mutation set later reported as MDR, so the headline 5.8% mutation-detection gain is partly fitted rather than predicted.

  1. fitted input called prediction [Section III-E (Eq. 4), Section III-D (Listing 5), Table II, Abstract]
    "If MDR <1, it implies that certain mutations remain undetected by all generated assertions. In such cases, the mutation traces and logs serve as feedback to regeneration SVA. The failed mutations' context (e.g., affected signal, location, or operation) is used to promote the LLM to produce more relevant assertions. (Section III-E; Eq. 4 defines MDR = |{mj | ∃ai : detect(ai, mj) = 1}| / k.)"

    By the paper's own equations, the same mutation set M is both the objective that drives assertion regeneration and the benchmark on which the reported MDR is computed. Section III-D states that 'subsequent iterations incorporate mutation-specific cues (mutation points)' and Listing 5 shows those cues as concrete mutant behaviors (e.g., 'read_valid never asserted'). Section III-E then reports MDR over that same set M, and Table II / the Abstract present the resulting improvement (5.8%) against baselines that received no mutation feedback. The final MDR therefore measures fit to the evaluation mutants, not generalization to new faults; no held-out mutant partition or validation set is described. The ablation in Fig.

full rationale

The central derivation chain — multimodal preprocessing, modality-sensitive analyzers, unified semantic representation, multi-step CoT prompting, and RAG-augmented SVA synthesis — is self-contained and not circular: structured specifications are extracted and then used to synthesize assertions, with no equation that reduces the output to the input by definition. There are no load-bearing self-citations and no uniqueness theorems imported from the authors' prior work; references such as LayoutParser, LightRAG, SymbiYosys, and Mantra are external and independently checkable. The one substantive circularity is confined to the mutation-detection result. Section III-E defines MDR over the mutation set M (Eq. 4), then feeds the undetected members of exactly that set back into the generator as 'mutation points' (Section III-D, Listing 5), and finally reports MDR on the same set M in Table II. Consequently the 5.8 percentage-point advantage in MDR over AssertLLM is at least in part a fitted result: AssertCoder was allowed to optimize against the evaluation mutants while the baselines were not. The paper gives no evidence of a separate held-out mutant set, so the reported MDR does not establish generalization to new bugs. The functional-correctness claim (8.4%) is less affected because it is judged by model checking against the unmutated DUT and semantic alignment, but the mutation-detection claim, one of the two headline quantitative results, is substantially forced by the evaluation loop. I therefore assign a score of 7: the derivation is not wholly circular, but the headline mutation-detection improvement reduces, by the paper's own definitions, to optimization against the reported benchmark.

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

The framework introduces no new physical or mathematical entities. Its central claims depend on assumptions about specification completeness, LLM semantic fidelity, mutation representativeness, formal tool correctness, and the reliability of manual annotation.

assumptions (5)
  • domain assumption Specification documents are complete and consistent for the signals of interest.
    Section III-C merges information from all modalities; if specs are ambiguous or incomplete, the extracted semantic representation and hence generated assertions will inherit the defects.
  • domain assumption LLM extraction and CoT synthesis preserve the intended signal-level semantics.
    The prompt templates in Listings 2-5 assume the LLM faithfully converts natural language, tables, and diagrams into code; there is no formal guarantee.
  • domain assumption Mantra mutation operators are representative of real-world hardware bugs.
    Section IV-A uses Mantra to inject 100-300 mutants per DUT; if these mutations are not representative, MDR does not measure practical bug-detection ability.
  • standard math Model checking with SymbiYosys is sound for the generated SVA properties.
    Section III-E uses SymbiYosys for model checking; assumes the formal engine terminates and is correct for the temporal properties.
  • domain assumption Manual semantic correctness annotation is unbiased and accurate.
    Section III-E relies on manual post-validation to label assertion failures as false positives or real bugs; the reported functional correctness and FPR depend on this subjective assessment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AssertCoder: LLM-Based Assertion Generation via Multimodal Specification Extraction." pith.science (2026). https://pith.science/paper/R77MFT34

@misc{pith2026250710338,
  author       = {Pith},
  title        = {Pith review of: AssertCoder: LLM-Based Assertion Generation via Multimodal Specification Extraction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/R77MFT34}},
  note         = {Machine review of arXiv:2507.10338}
}
read the original abstract

Assertion-Based Verification (ABV) is critical for ensuring functional correctness in modern hardware systems. However, manually writing high-quality SVAs remains labor-intensive and error-prone. To bridge this gap, we propose AssertCoder, a novel unified framework that automatically generates high-quality SVAs directly from multimodal hardware design specifications. AssertCoder employs a modality-sensitive preprocessing to parse heterogeneous specification formats (text, tables, diagrams, and formulas), followed by a set of dedicated semantic analyzers that extract structured representations aligned with signal-level semantics. These representations are utilized to drive assertion synthesis via multi-step chain-of-thought (CoT) prompting. The framework incorporates a mutation-based evaluation approach to assess assertion quality via model checking and further refine the generated assertions. Experimental evaluation across three real-world Register-Transfer Level (RTL) designs demonstrates AssertCoder's superior performance, achieving an average increase of 8.4% in functional correctness and 5.8% in mutation detection compared to existing state-of-the-art approaches.

Figures

Figures reproduced from arXiv: 2507.10338 by the authors.

Figure 1
Figure 1. The Overview of AssertCoder Framework Control Logic, Reset Behavior, Module Interface, etc.). The prompt includes structured input-output examples and explic￾itly instructs the model to reason about signal semantics, control logic, and structural content. An example of the full prompt structure is shown in Listing 1. SYSTEM ROLE You are a hardware specification analyst with expertise in signal semantics, interface c… view at source ↗
Figure 2
Figure 2. Effect of component ablations on functional correctness assertions [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Impact on mutation detection rate (MDR) across designs. structural guidance, yielding a low mutation detection rate and high false positive rate. The advantage of AssertCoder lies in its unified semantic decomposition and CoT reasoning pipeline, which enables precise identification of assertion intent and timing constraints. Importantly, the low FPR indicates that the SVA generated by the AssertCoder framework has h… view at source ↗

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. LLM Assisted Verification Assertion Generation: Challenges and Future Directions

    cs.ET 2026-07 conditional novelty 2.0 of 10

    A review of LLM-based SystemVerilog Assertion generation frameworks, identifying challenges in specification processing, signal mapping, vacuity, and evaluation, with guidelines for future research.

Reference graph

Works this paper leans on

32 extracted references · 27 canonical work pages · cited by 1 Pith paper

  1. [1]

    Bergeron, Writing testbenches using SystemVerilog

    J. Bergeron, Writing testbenches using SystemVerilog. Springer Science & Business Media, 2007

  2. [2]

    A survey on assertion- based hardware verification,

    H. Witharana, Y . Lyu, S. Charles, and P. Mishra, “A survey on assertion- based hardware verification,” ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1–33, 2022

  3. [3]

    Au- tosva: Democratizing formal verification of rtl module interactions,

    M. Orenes-Vera, A. Manocha, D. Wentzlaff, and M. Martonosi, “Au- tosva: Democratizing formal verification of rtl module interactions,” in Proceedings of the 58th ACM/IEEE Design Automation Conference (DAC). IEEE, 2021, pp. 535–540

  4. [4]

    r-map: Relating implementation and specification in hardware refinement checking,

    W. Fang, G. Hu, and H. Zhang, “r-map: Relating implementation and specification in hardware refinement checking,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 2023

  5. [5]

    A-team: Automatic template- based assertion miner,

    A. Danese, N. D. Riva, and G. Pravadelli, “A-team: Automatic template- based assertion miner,” in Proceedings of the 54th Annual Design Automation Conference (DAC), 2017, pp. 1–6

  6. [6]

    Harm: a hint-based assertion miner,

    S. Germiniani and G. Pravadelli, “Harm: a hint-based assertion miner,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 41, no. 11, pp. 4277–4288, 2022

  7. [7]

    Goldmine: Automatic assertion generation using data mining and static analysis,

    S. Vasudevan, D. Sheridan, S. Patel, D. Tcheng, B. Tuohy, and D. John- son, “Goldmine: Automatic assertion generation using data mining and static analysis,” in 2010 Design, Automation & Test in Europe Conference & Exhibition (DATE) . IEEE, 2010, pp. 626–629

  8. [8]

    Hybrid rule-based and machine learning system for assertion generation from natural language specifications,

    F. Aditi and M. S. Hsiao, “Hybrid rule-based and machine learning system for assertion generation from natural language specifications,” in 2022 IEEE 31st Asian Test Symposium (ATS) . IEEE, 2022, pp. 126–131

Show all 32 references
  1. [9]

    Automated assertion generation from natural language specifications,

    S. J. Frederiksen, J. Aromando, and M. S. Hsiao, “Automated assertion generation from natural language specifications,” in 2020 IEEE Interna- tional Test Conference (ITC) . IEEE, 2020, pp. 1–5

  2. [10]

    Glast: Learning formal grammars to translate natural language specifications into hardware assertions,

    C. B. Harris and I. G. Harris, “Glast: Learning formal grammars to translate natural language specifications into hardware assertions,” in 2016 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2016, pp. 966–971

  3. [11]

    Chatbot-based assertion generation from natural language specifications,

    O. Keszocze and I. G. Harris, “Chatbot-based assertion generation from natural language specifications,” in 2019 Forum for Specification and Design Languages (FDL) . IEEE, 2019, pp. 1–6

  4. [12]

    Spectosva: Circuit specification document to systemverilog assertion translation,

    G. Parthasarathy, S. Nanda, P. Choudhary, and P. Patil, “Spectosva: Circuit specification document to systemverilog assertion translation,” in 2021 Second Document Intelligence Workshop at KDD , 2021, n.d

  5. [13]

    Natural language is not enough: Benchmarking multi-modal generative ai for verilog generation,

    K. Chang, Z. Chen, Y . Zhou, W. Zhu, K. Wang, H. Xu, C. Li, M. Wang, S. Liang, H. Li et al., “Natural language is not enough: Benchmarking multi-modal generative ai for verilog generation,” in Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design ,...

  6. [14]

    Assertllm: Generating hardware verification assertions from design specifications via multi-llms,

    Z. Yan, W. Fang, M. Li, M. Li, S. Liu, Z. Xie, and H. Zhang, “Assertllm: Generating hardware verification assertions from design specifications via multi-llms,” in Proceedings of the 30th Asia and South Pacific Design Automation Conference, 2025, pp. 614–621

  7. [15]

    Chiraag: Chatgpt informed rapid and automated assertion generation,

    B. Mali, K. Maddala, V . Gupta, S. Reddy, C. Karfa, and R. Karri, “Chiraag: Chatgpt informed rapid and automated assertion generation,” in 2024 IEEE Computer Society Annual Symposium on VLSI (ISVLSI) . IEEE, 2024, pp. 680–683

  8. [16]

    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

  9. [17]

    (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

  10. [18]

    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

  11. [19]

    Spec2assertion: Automatic pre-rtl assertion generation using large language models with progressive regularization,

    F. Wu, E. Pan, R. Kande, M. Quinn, A. Tyagi, D. K. Houngninou, J. Rajendran, and J. Hu, “Spec2assertion: Automatic pre-rtl assertion generation using large language models with progressive regularization,” arXiv preprint arXiv:2505.07995 , 2025

  12. [20]

    Are llms ready for practical adoption for assertion generation?

    V . Pulavarthi, D. Nandal, S. Dan, and D. Pal, “Are llms ready for practical adoption for assertion generation?” in 2025 Design, Automation & Test in Europe Conference (DATE) . IEEE, 2025, pp. 1–7

  13. [21]

    Chain-of-thought prompting elicits reasoning in large language models,

    J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V . Le, D. Zhou et al. , “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems , vol. 35, pp. 24 824–24 837, 2022

  14. [22]

    Model checking,

    E. M. Clarke, “Model checking,” in Foundations of Software Technology and Theoretical Computer Science: 17th Conference Kharagpur, India, December 18–20, 1997 Proceedings 17 . Springer, 1997, pp. 54–56

  15. [23]

    Layoutparser: A unified toolkit for deep learning based document image analysis,

    Z. Shen, R. Zhang, M. Dell, B. C. G. Lee, J. Carlson, and W. Li, “Layoutparser: A unified toolkit for deep learning based document image analysis,” in Document Analysis and Recognition–ICDAR 2021: 16th International Conference, Lausanne, Switzerland, September 5–10, 2021, Proc...

  16. [24]

    Publaynet: largest dataset ever for document layout analysis,

    X. Zhong, J. Tang, and A. J. Yepes, “Publaynet: largest dataset ever for document layout analysis,” in 2019 International conference on document analysis and recognition (ICDAR) . IEEE, 2019, pp. 1015– 1022

  17. [25]

    Handwritten opti- cal character recognition (ocr): A comprehensive systematic literature review (slr),

    J. Memon, M. Sami, R. A. Khan, and M. Uddin, “Handwritten opti- cal character recognition (ocr): A comprehensive systematic literature review (slr),” IEEE access, vol. 8, pp. 142 642–142 668, 2020

  18. [26]

    Lightrag: Simple and fast retrieval-augmented generation,

    Z. Guo, L. Xia, Y . Yu, T. Ao, and C. Huang, “Lightrag: Simple and fast retrieval-augmented generation,” 2025. [Online]. Available: https://arxiv.org/abs/2410.05779

  19. [27]

    I2c-master core specification,

    R. Herveille, “I2c-master core specification,” svn://opencores. org/ocsvn/i2c@ r76, OpenCores , 2003

  20. [28]

    Aes core specification,

    H. Hsing, “Aes core specification,” OpenCores, 2013

  21. [29]

    openmsp430,

    O. Girard, “openmsp430,” URL: http://opencores.org, 2009

  22. [30]

    GPT-4 Technical Report,

    OpenAI, “GPT-4 Technical Report,” https://openai.com/research/gpt-4, Mar. 2024, accessed: Jul. 2025

  23. [31]

    Yosys open synthesis suite,

    C. Wolf, “Yosys open synthesis suite,” 2016

  24. [32]

    Mantra: Mutation testing of hardware design code based on real bugs,

    J. Wu, Y . Lei, Z. Zhang, X. Meng, D. Yang, P. Li, J. He, and X. Mao, “Mantra: Mutation testing of hardware design code based on real bugs,” in 2023 60th ACM/IEEE Design Automation Conference (DAC). IEEE, 2023, pp. 1–6

Pith tools

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