Pith. sign in

REVIEW 4 major objections 1 minor 1 cited by

Wit-HW: Bug Localization in Hardware Design Code via Witness Test Case Generation

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

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

Pith's one-line read By generating passing witness tests from a single failing simulation, Wit-HW uses coverage differences to rank the true buggy statement in the top 10 for 88% of 41 benchmark hardware bugs.

desk verdict A plausible witness-generation twist on spectrum-based hardware bug localization with strong reported Top-k numbers, but the supplied text is undecodable and the core premise—that generated witnesses differ at the fault—needs evidence. read the letter →

arxiv 2508.14414 v1 pith:MQGXEOVM submitted 2025-08-20 cs.AR

Ruiyang Ma , Daikang Kuang , Ziqian Liu , Jiaxi Zhang , Ping Fan , Guojie Luo This is my paper
classification cs.AR
keywords hardwaredebuggingbuglocalizationwitnesstestcasegenerationspectrum-basedfaultmutation-basedsimulation-basedverificationRTLsuspiciousstatementranking
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 aims to fix hardware bug localization, which today stalls when designs are large and bugs are deep. The core idea is to stop relying on a single bug-triggering simulation and instead generate a small set of witness test cases—mutated variants that pass on the faulty design—then compare execution traces with a spectrum-based method. The claim is that this reframing, from debugging to test generation, lets innocent statements be eliminated and the true buggy statement be ranked near the top: 49%, 73%, and 88% of 41 bugs at Top-1, Top-5, and Top-10, with an additional 13 real-world open-source hardware bugs handled as well. A reader should care because the approach attacks the manual trace-analysis bottleneck in hardware verification.

What carries the argument

The central object is the witness test case: a mutated variant of the bug-triggering test that does not trigger the bug on the faulty design. Its job is to create the passing side of a pass/fail comparison. Wit-HW's contribution is coupling these witnesses to spectrum-based analysis—coverage of each design statement in passing versus failing runs—so statements that look suspicious in one failing trace but appear equally in passing witnesses are eliminated. The effectiveness criteria and the mutation strategy are the machinery that makes the witnesses useful rather than arbitrary.

What would settle it

Take a set of bugs in which the faulty statement is always executed regardless of the bug and the only difference between failing and passing runs is values, not statement coverage. If Wit-HW's Top-10 rate on that set is near random, the spectral premise is the bottleneck. More concretely, instrument the witness set for each of the 41 benchmark bugs, count how many witnesses skip the true fault site, and check whether bugs whose witnesses skip the site are exactly those ranked outside Top-10.

Watch

Extended reading notes

Core claim

On its own terms, Wit-HW establishes that a set of effective witness test cases can be generated by mutation from the one failing test case, and that these witnesses make spectrum-based bug localization practical on large, deep hardware designs. The paper defines effectiveness criteria for witnesses—they must pass on the faulty design and be varied enough in execution—and shows a mutation-based search that satisfies them. Feeding the failing run and the passing witnesses into a spectrum-based comparison eliminates statements that are executed regardless of outcome, and the remaining suspicious statements are ranked. The reported outcome is that the true buggy statement lands in Top-1 for 49%

Load-bearing premise

The ranking works only if the buggy statement's execution differs between the failing run and the generated passing witnesses; when the fault is executed in every run, or when the failure symptom propagates far from the fault site, spectrum comparison has no signal to rank it.

Editorial extensions

If this is right

  • A verification engineer who already has one failing simulation can get a ranked list of suspicious statements without reading the full waveform trace.
  • Because the input to localization is generated test cases, future improvements in test generation and mutation search can transfer directly to bug-localization accuracy.
  • Bug localization no longer depends on an existing passing test suite; the failing test itself is leveraged to produce the passing cases.
  • The Top-1/Top-5/Top-10 numbers imply that inspection effort can be concentrated on a small set of statements for most real bugs.

Reading between the lines

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

  • The paper leaves implicit that the value of each witness depends on its execution differing from the failing test near the fault, not just anywhere; a witness that passes for an unrelated reason shifts the spectrum in the wrong direction.
  • The same witness-generation framing could be applied to software bug localization, where spectrum analysis is mature but mutation around a failing regression test is less explored.
  • A testable extension is to pair witness search with coverage-guided objectives so generated passing tests are forced through the fault-adjacent region, which should improve Top-1 rates on deep sequential bugs.
  • The approach's reliance on spectra suggests a boundary worth testing: bugs where the faulty statement is executed in all runs—for example, a wrong data value in an always-taken branch—are the hard cases, and an evaluation stratified by that property would show when the method fails.
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 / 1 minor

Summary. The paper proposes Wit-HW, a hardware bug-localization framework that converts a single bug-triggering simulation into a small set of generated passing 'witness' test cases, then applies spectrum-based analysis to the execution differences between passing and failing cases to rank suspicious statements. The abstract reports Top-1/5/10 localization rates of 49%, 73%, and 88% on 41 benchmark bugs and additional results on 13 real-world open-source hardware bugs. In the version supplied for review, the full text is indecipherable: the body is a sequence of unreadable characters, so no algorithm, definition, equation, or table can be checked. The assessment therefore rests on the abstract and on the structural claims visible in the fragments.

Significance. If the reported results are correct, the core idea is of interest to the hardware verification community: using one failing test and a small number of automatically generated passing tests to improve spectrum-based localization is a plausible and practical direction, and the claim of effectiveness on deep bugs is valuable. The method's concrete, falsifiable performance numbers are a strength, as is the inclusion of real-world bug cases. However, the supplied manuscript does not currently permit verification of the method's derivation, the witness-effectiveness criterion, the mutation strategy, or the experimental comparison. The contribution cannot be assessed as presented, and the load-bearing premise — that coverage differences between the failing test and mutated witnesses point to the faulty statement rather than to unrelated input-driven changes — is not supported by the abstract alone.

major comments (4)
  1. [Full text (all body sections after the abstract)] The supplied PDF text decodes as an unreadable sequence; no section, equation, algorithm, or table can be recovered. Consequently, the derivation of the witness-effectiveness criteria, the mutation strategy, the spectral formulas, the benchmark setup, and the baseline comparisons cannot be checked. This is a load-bearing reviewability failure: the abstract's numerical claims cannot be verified or reproduced from the manuscript in its current form. The authors should resubmit a readable version before substantive evaluation.
  2. [Abstract, para. 2] The abstract introduces 'effective witness test cases' but does not state the criteria. If effectiveness is defined in terms of improving the suspiciousness ranking, the witness-selection objective is aligned with the evaluation metric and the reported Top-k improvement becomes partly by construction. If effectiveness is instead defined as coverage distance from the failing test, the selection may favor witnesses with many unrelated input-driven coverage changes, biasing the spectrum. The manuscript must define these criteria and demonstrate that they are not pre-wired to the ranking.
  3. [Abstract, para. 2 (mutation-based strategy)] The central premise is that mutating a single bug-triggering test yields passing witnesses whose coverage differs at the faulty statement. The abstract provides no evidence for this premise. For the deep sequential bugs that the paper explicitly targets, the faulty statement (e.g., FSM transition logic) can execute in every run, with only state or output differing; then passing witnesses have identical coverage at the fault, and spectrum-based ranking cannot place it at the reported ranks. The paper needs a per-bug analysis showing the actual coverage deltas at the fault site, or an argument for why the witness set remains informative in such cases.
  4. [Abstract, evaluation paragraph] The abstract reports 49%/73%/88% on 41 bugs and additional results on 13 real-world bugs, but gives no error bars, no per-design breakdown, no bug-type composition, no statistical comparison to baselines, and no description of baseline tuning. With 41 bugs, the difference between Top-1 rates of competing methods is sensitive to a few cases. The full evaluation must include confidence intervals or per-benchmark results, and must specify how baselines were configured, to support the 'significantly outperforming' claim.
minor comments (1)
  1. [Page 1 running header] The running header contains 'arXiv:2508.14415v1 [cs.AI] 20 Aug 2025', which is a different identifier from the manuscript's own arXiv number (2508.14414). This looks like a typesetting or submission contamination and should be removed or corrected. It also reinforces the impression that the current PDF is not a clean final version.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity detectable from the readable abstract; the full-text body is undecodable so no equation-level reduction can be exhibited.

full rationale

The supplied full text is a byte-level mojibake rendering; no equations, definitions, or numbered claims can be quoted from the body. Restricting the analysis to the readable abstract, the derivation chain is: (1) take a bug-triggering test; (2) generate witness tests that do not trigger the bug in the faulty design; (3) run spectrum-based fault localization over the resulting passing/failing coverage; (4) rank statements. Step (2) is definitional but not circular: witness tests are defined as passing, which is the standard oracle input to spectrum-based methods, not the output of the localization. Step (3) invokes the usual SBFL correlation premise; that premise is an assumption about fault-signal propagation, not a reduction of the prediction to its input. The abstract states that 'effective witness' criteria are defined and a mutation strategy is used, but it does not say the criteria are the suspiciousness scores being predicted, so no fitted-input-called-prediction step can be substantiated. No self-citations or imported uniqueness theorems appear in the readable text. Under the hard rule that circularity must be exhibited by quote and specific reduction, no circular step can be identified. The potential concern that witness effectiveness is defined via the same suspiciousness scores remains unverifiable and therefore does not raise the score.

Assumptions & free parameters 3 free parameters · 3 assumptions · 1 invented entities

Everything here is extracted from the abstract because the body is undecodable. The method rests on classical SBFL premises plus a set of unstated hyperparameters and an effectiveness criterion that cannot be audited from the abstract alone. If the effectiveness criterion is tuned against known bug locations, it would count as an additional fitted parameter.

free parameters (3)
  • mutation strategy parameters (mutation rate, number of generated witnesses)
    The abstract states a mutation-based witness generation strategy but gives no parameter values; these influence spectral ranking and cannot be audited.
  • suspiciousness metric and ranking threshold
    The spectrum-based method requires a ranking formula and possibly a cutoff; not specified in the abstract.
  • witness effectiveness criteria
    The paper 'defines the criteria for effective witness test cases'; the criteria are chosen within the paper, possibly with the bug location known, which would act as a free parameter for the reported ranks.
assumptions (3)
  • domain assumption A bug-triggering test case is available before localization starts.
    Stated in the abstract as the starting point: 'After engineers identify a bug-triggering test case in simulation-based hardware verification'.
  • domain assumption Coverage differences between passing and failing runs concentrate on the buggy statements.
    Spectrum-based reasoning underpins the elimination of 'innocent design statements'; this is the classical SBFL premise.
  • domain assumption Mutation of the bug-triggering test case yields valid witness test cases that still exercise the buggy region.
    The witness generation step depends on reaching passing inputs that are informative for ranking; this is not guaranteed for deep or sequential bugs.
invented entities (1)
  • effective witness test case criteria
    purpose: Defines which generated passing test cases are worth adding to the spectral analysis to sharpen the suspicious ranking.
    The criteria are defined inside the paper; the abstract offers no external falsifiable handle for them, so the entity is self-referential until the body is inspectable.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Wit-HW: Bug Localization in Hardware Design Code via Witness Test Case Generation." pith.science (2026). https://pith.science/paper/MQGXEOVM

@misc{pith2026250814414,
  author       = {Pith},
  title        = {Pith review of: Wit-HW: Bug Localization in Hardware Design Code via Witness Test Case Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MQGXEOVM}},
  note         = {Machine review of arXiv:2508.14414}
}
read the original abstract

Debugging hardware designs requires significant manual effort during hardware development. After engineers identify a bug-triggering test case in simulation-based hardware verification, they usually spend considerable time analyzing the execution trace to localize the bug. Although numerous automated hardware debugging techniques exist, they are not applicable to large designs and deep bugs. A primary reason for their limitations is that these techniques only utilize the information of a single bug-triggering test case for bug localization, which prevents them from effectively analyzing intricate hardware systems and figure out the root cause of bugs. To solve this problem, in this paper, we transform the hardware bug localization problem into a test generation problem, aiming to find a set of effective witness test cases beyond the initial bug-triggering test case to enhance hardware bug localization. Witness test cases refer to the cases that do not trigger the bug in the faulty design. By analyzing the execution differences between passing and failing test cases with spectrum-based method, we can eliminate innocent design statements and localize the buggy ones. To further refine the suspicious area, we define the criteria for effective witness test cases and use a mutation-based strategy to generate such test cases. Based on this approach, we propose an automated hardware bug localization framework named Wit-HW. We evaluate Wit-HW on 41 bugs from various hardware designs. The experimental results show that Wit-HW effectively localize 49%, 73%, 88% bugs within Top-1, Top-5, Top-10 ranks, significantly outperforming state-of-the-art bug localization techniques. Additionally, we evaluate Wit-HW on 13 real-world bugs collected from open-source hardware projects, showcasing the robust performance of our method.

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

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

  1. CWEEP: A Lexical Static Analysis Framework for CWE Early Prevention

    cs.CR 2026-07 conditional novelty 6.0 of 10

    CWEEP, a lexical static analysis tool, detects RTL security weaknesses with precision up to 60.8% and offers bug localization and auto-fix suggestions.

Reference graph

Works this paper leans on

44 extracted references · 43 canonical work pages · cited by 1 Pith paper

  1. [1]

    W. Chen, S. Ray, J. Bhadra, M. Abadir, and L.-C. Wang, ``Challenges and trends in modern SoC design verification,'' IEEE Design & Test, vol. 34, no. 5, pp. 7--22, 2017

    work page 2017

  2. [2]

    W. K. Lam, Hardware design verification: simulation and formal method-based approaches. 1em plus 0.5em minus 0.4em Prentice Hall PTR, 2008

    work page 2008

  3. [3]

    Dessouky, D

    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 28th USENIX Security Symposium, 2019

    work page 2019

  4. [4]

    H. D. Foster, ``2024 Wilson Research Group IC/ASIC functional verification trend report,'' Siemens Digital Industries Software, 2025

    work page 2024

  5. [5]

    W. E. Wong, R. Gao, Y. Li, R. Abreu, and F. Wotawa, ``A survey on software fault localization,'' IEEE Transactions on Software Engineering, vol. 42, no. 8, pp. 707--740, 2016

    work page 2016

  6. [6]

    Ahmad, Y

    H. Ahmad, Y. Huang, and W. Weimer, `` CirFix : automatically repairing defects in hardware design code,'' in 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2022

    work page 2022

  7. [7]

    J. Wu, Z. Zhang, D. Yang, X. Meng, J. He, X. Mao, and Y. Lei, ``Fault localization for hardware design code with time-aware program spectrum,'' in IEEE 40th International Conference on Computer Design, 2022

    work page 2022

  8. [8]

    Laeufer, B

    K. Laeufer, B. Fajardo, A. Ahuja, V. Iyer, B. Nikoli \'c , and K. Sen, `` RTL-Repair : Fast symbolic repair of hardware design code,'' in 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2024

    work page 2024

Show all 44 references
  1. [9]

    Laeufer, J

    K. Laeufer, J. Koenig, D. Kim, J. Bachrach, and K. Sen, `` RFUZZ : Coverage-directed fuzz testing of RTL on FPGAs ,'' in IEEE/ACM International Conference on Computer-Aided Design, 2018

    2018

  2. [10]

    Trippel, K

    T. Trippel, K. G. Shin, A. Chernyakhovsky, G. Kelly, D. Rizzo, and M. Hicks, ``Fuzzing hardware like software,'' in 31st USENIX Security Symposium, 2022

    2022

  3. [11]

    Kande, A

    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 vulnerabilities,'' in 31st USENIX Security Symposium, 2022

    2022

  4. [12]

    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, 2023

    2023

  5. [13]

    Abreu, P

    R. Abreu, P. Zoeteweij, and A. J. Van Gemund, ``An evaluation of similarity coefficients for software fault localization,'' in 12th Pacific Rim International Symposium on Dependable Computing, 2006

    2006

  6. [14]

    J. Chen, J. Han, P. Sun, L. Zhang, D. Hao, and L. Zhang, ``Compiler bug isolation via effective witness test program generation,'' in 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2019

    2019

  7. [15]

    Xuan and M

    J. Xuan and M. Monperrus, ``Test case purification for improving fault localization,'' in 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2014

    2014

  8. [16]

    Soremekun, L

    E. Soremekun, L. Kirschner, M. B \"o hme, and A. Zeller, ``Locating faults with program slicing: an empirical analysis,'' Empirical Software Engineering, 2021

    2021

  9. [17]

    DiGiuseppe and J

    N. DiGiuseppe and J. A. Jones, ``On the influence of multiple faults on coverage-based fault localization,'' in International Symposium on Software Testing and Analysis, 2011

    2011

  10. [18]

    Q. I. Sarhan and \'A . Besz \'e des, ``A survey of challenges in spectrum-based software fault localization,'' IEEE Access, vol. 10, pp. 10\,618--10\,639, 2022

    2022

  11. [19]

    J. A. Jones and M. J. Harrold, ``Empirical evaluation of the Tarantula automatic fault-localization technique,'' in 20th IEEE/ACM International Conference on Automated Software Engineering, 2005

    2005

  12. [20]

    Y. Tsai, M. Liu, and H. Ren, `` RTLFixer : Automatically fixing RTL syntax errors with large language model,'' in 61st ACM/IEEE Design Automation Conference, 2024

    2024

  13. [21]

    Ahmad, S

    B. Ahmad, S. Thakur, B. Tan, R. Karri, and H. Pearce, ``Fixing hardware security bugs with large language models,'' arXiv preprint arXiv:2302.01215 [cs.CR], 2023

    2023 arXiv

  14. [22]

    Stracquadanio, S

    G. Stracquadanio, S. Medya, S. Quer, and D. Pal, `` VeriBug : An attention-based framework for bug localization in hardware designs,'' in Design, Automation & Test in Europe Conference & Exhibition, 2024

    2024

  15. [23]

    M \"u ller, ``Dynamic time warping,'' in Information Retrieval for Music and Motion

    M. M \"u ller, ``Dynamic time warping,'' in Information Retrieval for Music and Motion. 1em plus 0.5em minus 0.4em Springer Berlin Heidelberg, 2007, pp. 69--84

    2007

  16. [24]

    J. S. Hunter, ``The exponentially weighted moving average,'' Journal of Quality Technology, vol. 18, no. 4, pp. 203--210, 1986

    1986

  17. [25]

    Canakci, L

    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 58th ACM/IEEE Design Automation Conference, 2021

    2021

  18. [26]

    J. Ma, G. Zuo, K. Loughlin, H. Zhang, A. Quinn, and B. Kasikci, ``Debugging in the brave new world of reconfigurable hardware,'' in 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2022

    2022

  19. [27]

    Snyder, `` Verilator and SystemPerl ,'' in North American SystemC Users' Group, 2004

    W. Snyder, `` Verilator and SystemPerl ,'' in North American SystemC Users' Group, 2004

    2004

  20. [28]

    Vittal, `` ASIC hardware verification: Debug challenges & solutions,'' Synopsys, 2021

    K. Vittal, `` ASIC hardware verification: Debug challenges & solutions,'' Synopsys, 2021

    2021

  21. [29]

    Papadakis and Y

    M. Papadakis and Y. Le Traon, ``Metallaxis- FL : mutation-based fault localization,'' Software Testing, Verification and Reliability, vol. 25, no. 5-7, pp. 605--628, 2015

    2015

  22. [30]

    S. Moon, Y. Kim, M. Kim, and S. Yoo, ``Ask the mutants: Mutating faulty programs for fault localization,'' in IEEE Seventh International Conference on Software Testing, Verification and Validation, 2014

    2014

  23. [31]

    J. Wu, Z. Zhang, D. Yang, J. Xu, J. He, and X. Mao, ``Knowledge-augmented mutation-based bug localization for hardware design code,'' ACM Transactions on Architecture and Code Optimization, vol. 21, no. 3, pp. 1--26, 2024

    2024

  24. [32]

    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, 2021

    2021

  25. [33]

    R. Ma, J. Huang, S. Zhang, Y. Xie, and G. Luo, `` NoCFuzzer : Automating NoC verification in UVM ,'' IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 44, no. 1, pp. 371--384, 2025

    2025

  26. [34]

    Ahmed, F

    A. Ahmed, F. Farahmandi, and P. Mishra, ``Directed test generation using concolic testing on RTL models,'' in Design, Automation & Test in Europe Conference & Exhibition, 2018

    2018

  27. [35]

    Lyu and P

    Y. Lyu and P. Mishra, ``Automated test generation for activation of assertions in RTL models,'' in 25th Asia and South Pacific Design Automation Conference, 2020

    2020

  28. [36]

    Zhang, G

    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

  29. [37]

    R. Ma, Y. Yang, Z. Liu, J. Zhang, M. Li, J. Huang, and G. Luo, `` VerilogReader : LLM -aided hardware test generation,'' in IEEE LLM Aided Design Workshop, 2024

    2024

  30. [38]

    R. Ma, T. Wei, J. Zhang, C. Yang, J. Yi, and G. Luo, ``Bridging the gap between hardware fuzzing and industrial verification,'' in Proceedings of the Great Lakes Symposium on VLSI 2025, 2025, pp. 626--633

    2025

  31. [39]

    J. Wu, Z. Zhang, D. Yang, J. Xu, J. He, and X. Mao, ``Time-aware spectrum-based bug localization for hardware design code with data purification,'' ACM Transactions on Architecture and Code Optimization, vol. 21, no. 3, pp. 1--25, 2024

    2024

  32. [40]

    Hu and Z

    J. Hu and Z. Liu, ``Context aware deep learning-based fault localization for hardware design code,'' IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (Early Access), 2025

    2025

  33. [41]

    D. Yang, J. He, X. Mao, T. Li, Y. Lei, X. Yi, and J. Wu, ``Strider: Signal value transition-guided defect repair for HDL programming assignments,'' IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 43, no. 5, pp. 1594--1607, 2023

    2023

  34. [42]

    Singh, D

    E. Singh, D. Lin, C. Barrett, and S. Mitra, ``Logic bug detection and localization using symbolic quick error detection,'' IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (Early Access), 2018

    2018

  35. [43]

    Singh, F

    E. Singh, F. Lonsing, S. Chattopadhyay, M. Strange, P. Wei, X. Zhang, Y. Zhou, D. Chen, J. Cong, P. Raina et al., ``A- QED verification of hardware accelerators,'' in 57th ACM/IEEE Design Automation Conference, 2020

    2020

  36. [44]

    T. Hong, Y. Li, S.-B. Park, D. Mui, D. Lin, Z. A. Kaleq, N. Hakim, H. Naeimi, D. S. Gardner, and S. Mitra, `` QED : Quick error detection tests for effective post-silicon validation,'' in IEEE International Test Conference, 2010

    2010

Pith tools

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