Fast Multi-level Test Generation at the RTL

Abstract

Abstract-Functional, at-speed vectors continue to provide added value to the testing community as circuit complexity rises. Complex defects may escape traditional scan vectors and thus often require at-speed patterns. However, generation of functional/sequential vectors is an extremely challenging problem. Previous methods rely on formal models of the RTL or calls to gate level ATPG, both of which are computationally expensive, limiting the efficacy of gains made in RTL stimuli generation. In this work, we present an efficient engine for the generation of high quality functional tests at the RTL which are effective for both validation and at-speed defect detection. The proposed method utilizes a rule based, behavioral coverage metric to accurately assess the activation of circuit modules by the generated stimuli. Based on this metric, we are able to effectively generate functional test vectors at the RTL, without additional gate level information, that can achieve a high level of defect coverage and up to an order of magnitude speedup over existing techniques.

Hyperfuzzing for SoC security validation

“…Similar ideas have been explored by Ahmed et al [1] and Farahmandi et al [16]. Li et al [29], and Gent et al [18] used ant colony optimization (ACO) to generate inputs that increase coverage. A notable effort that is related to our own is rfuzz, which uses coverage-guided mutational fuzzing via afl to perform FPGA-based validation of RTL design designs [27].…”

“…However, we argue the real problem in SoC security validation is in what (hyper-)property to validate, and how to model adversarial behavior? Our work introduces techniques for solving these two problems, and ideas such as the use of SAT/SMT solvers for whitebox fuzzing à la SAGE/HYBRO/QUEBS [1,20,30], the use of ACO as in [18,29], or acceleration via FPGAs [27] can all be readily integrated into our framework to further improve its performance. Blackbox and Whitebox Fuzzing: Seminal work on fuzzing was done by Miller and colleagues [32,33].…”

Fuzzing Hardware Like Software

“…Unfortunately, RFUZZ must be accelerated on FPGAs since coverage tracing is slow, and it is unclear how their mux toggle coverage maps to existing RTL coverage metrics DV engineers care about most, e.g., code coverage and functional coverage [37], [38]. Gent et al [17] propose an automatic test pattern generator based on custom coverage metrics, for which they also instrument the RTL directly to trace. Unfortunately, like RFUZZ, the scalability of their approach remains in question, given their coverage tracing method, and unlike RFUZZ, they do not accelerate their simulations on FPGAs.…”