Learning Semantic Representations to Verify Hardware Designs

1 Introduction . Hardware designs are verified to check if a design implements the architectural specification correctly . Verification is widely considered the most serious bottleneck in the contemporary industrial hardware design cycle [ 2 , 16 , 15 ] . It requires 60-75 % of the time , compute , and human resources during the design phase , routinely taking multiple person-years of effort . Verification is a complex problem because modern hardware has billions of inputs and flops , and the number of states is exponential in the number of flops and inputs . Checking every state of the system is infeasible due to a combinatorial ∗Equal contributors 35th Conference on Neural Information Processing Systems ( NeurIPS 2021 ) . state space explosion . While there is excellent research in automatic hardware verification techniques involving formal and static analysis , their applicability in practice is limited by scale . Instead , practical design verification sacrifices automation and completeness for a “ best effort , risk reducing ” process based on simulating the design on test inputs.2 Traditionally , formal verification methods analyze synchronous hardware designs through reachability analysis of a gate level state transition graph . Each node in this graph corresponds to a single value of bit-level state of all registers , and edges correspond to the legal changes in state that the design can make in a single clock cycle . It is well known in the formal methods community that most questions about hardware functionality can be posed as reachability questions in the state transition graph . This suggests a fundamental new research question in representation learning : Can we learn a continuous representation of a hardware design that allows us to predict its functionality ? This paper presents a first approach to this problem . Since designs are practically verified by simulations using millions of test inputs , this gives us a ready source of training data . To avoid the combinatorial explosion at the gate level , we approach the problem at a higher level of abstraction , the Register Transfer Level ( RTL ) that describes hardware at the bit-vector or integer level . RTL is described in a Hardware Description Language ( Verilog RTL [ 3 ] ) that is syntactically similar to the source code of software , while modeling the concurrent , non-deterministic , non-terminating , and reactive semantics of hardware . Despite the higher level of abstraction , RTL static analysis approaches for reachability analysis [ 4 ] and test input generation [ 31 ] do not scale to even reasonably sized practical designs . So our research question can be restated as : Can we use simulation data to learn a tractable continuous representation that can predict the answers to the state reachability queries in hardware ? In this paper , we introduce Design2Vec , an architecture for learning continuous representations that capture the semantics of a hardware design . We choose to represent the design as a control data flow graph ( CDFG ) at the RTL level . Based on the CDFG , we use graph neural networks ( GNN ) to learn representations that predict states reached by the design when simulated on test inputs . While standard GNN architectures do work well , we achieve improved performance by introducing a new propagation layer that specifically incorporates the concurrent and non-terminating semantics of RTL . Design2Vec is trained to predict if , given a simulation test input , a particular branch ( like a case statement in software ) will be covered . The CDFG is an abstraction of the gate-level state space since one edge in the CDFG maps to many edges in the gate-level transition graph . We can therefore interpret Design2Vec as learning an abstraction of the intractable gate-level design state space . We apply Design2Vec to two practical problems in hardware verification : coverage prediction and test generation . The coverage prediction model can act as a proxy simulator , and an engineer can query it to estimate coverage in seconds , instead of waiting for a night of simulations . Our test generation method uses a gradient-based search over the trained Design2Vec model to generate new tests . It is desirable to find tests for hard to cover points , or points human experts find difficult to cover after reaching around 80 % ( or more ) cumulative coverage using random testing . This coverage plateau can take months to close , effectively taking multiple expert months of productivity and effort . We demonstrate Design2Vec is able to successfully learn representations of multiple designs : ( i ) IBEX v1 [ 1 ] , a RISC-V design ( ii ) IBEX v2 , IBEX enhanced with security features , and ( iii ) Tensor Processing Unit ( TPU ) [ 23 ] , Google ’ s industrial scale commercial infrastructure ML accelerator chip , and performs dramatically better than black-box baselines that are uninformed by knowledge of the design ( up to 50 % better , and on average 20 % better for real designs ) . Our results show that Design2Vec achieves over 90 % accuracy in coverage prediction on the industrial TPU design , making it ideal to serve as a proxy simulator that can evaluate if a test can cover a given point within seconds . Our results on test generation show that Design2Vec is able to successfully find tests for hard to cover points in real designs in a fraction of the time ( up to 88 fewer simulator calls for TPU and 40 fewer for IBEX ) as compared to random testing and a black-box optimizer . This order of magnitude improvement can potentially lead to huge savings . Our key contributions follow . • We introduce the problem of learning continuous representations ( abstractions ) of hardware semantics that can be used for various tasks in hardware verification . We present Design2Vec , a model that encodes the syntactic and semantic structure of an RTL design using a GNN based architecture . 2All future references to verification will imply simulation based design verification as the majority practice in industry , not formal verification . • We propose the RTL IPA-GNN , which extends a recent architecture for learning to execute software [ 6 ] to model the concurrent and non-terminating semantics of RTL . • We introduce a test generation algorithm that uses Design2Vec to generate focused tests for a subset of cover points . The tests generated by Design2Vec are able to successfully cover hard to cover points using significantly fewer simulations than state of practice human expert guided random testing and a state of the art black-box optimization tool . • We demonstrate the scalability of the approach to large industrial scale designs . Our approach is practical in industrial settings . 2 Design2Vec : Representation learning of design abstractions . Verilog RTL source code is a powerful tool for writing non-terminating , continuous , reactive “ programs ” to design hardware . A program in RTL is structured as a modular hierarchy , with multiple concurrent blocks executing within each module . We consider the subset of behavioral RTL that can be synthesized into gate level designs [ 3 ] . Figure 1 shows an example snippet of Verilog RTL source code . A “ module ” corresponds to a hardware construct ( e.g . a decoder or ALU ) . A module can instantiate other modules ( e.g . a cache module may instantiate a prefetch module ) . Each “ variable ” in the RTL corresponds to either an input signal ( input ) , an output signal ( output ) , a register that stores values ( reg ) or a temporary variable ( wire ) . The bit width of each such variable is declared . In the example , a , b , and state are two-bit registers , c , d , p , and q are two-bit input signals . This design has three concurrent ( always ) blocks denoted by three colors . For synchronous hardware , an external clock signal triggers execution of each concurrent block per clock cycle . On each clock cycle , one statement in each always block is executed . The statements in an always block are thereby executed in sequence over multiple consecutive clock cycles . When executing a statement , the input values of variables in the current cycle come from the output values of variables from the previous cycle . There is an implicit loop from the end of each block back to its start , simulating the non-terminating nature of hardware . Within a cycle , the order in which the always blocks are executed is non-deterministic . In practice , it is as determined by an RTL simulator . Figure 4 in Appendix A.1 shows the execution ( simulation ) over a three cycle window of this example . RTL designs are typically simulated using an RTL design simulator , which does not suffice for the design goals of our analysis . For use with machine learning , we choose to represent RTL as a control data flow graph ( CDFG ) . The CDFG we construct for each Verilog RTL program encodes the program ’ s simulation semantics , so that our models may make inferences about the their behavior . The CDFG has nodes and heterogeneous edges . Nodes correspond to statements in code . Edges corresponds to either data flow or control flow . Dotted lines show data dependencies between concurrently executing blocks . The root node corresponds to the begin node of the top module . Branches denote localized node sequences . The designs that we consider contain branches , but not loops , which are atypical in synthesizable RTL . A test is a set of high level parameters , each of which can be Boolean , integer or categorical . A test defines a distribution over input signals to the design . When a test is run , the testbench samples many inputs from this distribution , and simulates the design on that sequence of inputs . The output of the testbench is Boolean input vectors applied to the RTL design under test . These input vectors execute different design paths . All the branches executed along different design paths are said to be covered . A test is written to achieve different types of design code coverage . Branch coverage tends to be the most important metric . Branch coverage of a test refers to branches executed by that test . Each branch is referred to as a cover point . A cover point over the RTL CDFG is identified as a sequence of nodes starting from the branch control node and ending at the destination of the branch . Two local branch cover points lie along the same global path if they have ancestor/descendant relationship . Figure 5 in Appendix A.1 shows the executed branches the input arrives at a certain clock cycle . 2.1 Architecture . Our Design2Vec architecture , shown in Figure 2 , is trained on the supervised task of coverage prediction . The network takes as input a cover point C , represented as a sequence of CDFG notes , and a test parameter vector I , and outputs the probability is_hit ( C , I ) that the test I covers C. Cover point embedding : We use a graph convolution network ( GCN ) over the Verilog CDFG . Each node n ∈ N has attributes/features denoted by fnj such as node identifier , node type , fan in and fan out . In addition , the RTL token sequence sn = < sn1 , s n 2 , · · · , snk > in the program statement is also considered as an additional attribute . We first perform an embedding of the token sequence φ ( sn ) using an LSTM ( or alternatively using a pre-trained word2vec module ) : φ ( sn ) = LSTM ( < sn1 , s n 2 , · · · , snk > ) . ( 1 ) The initial embedding of a node φ ( 0 ) ( n ) is computed as concatenation of the node attribute values and the token sequence embedding : φ ( 0 ) ( n ) = Concat ( < φ ( sn ) , fn1 , · · · , fnl > ) . ( 2 ) Let the embedding of a graph G at a step t be denoted by ψ ( t ) ( G ) = { φ ( t ) ( n ) |∀n ∈ N } . We use a GCN ( with learnable parameters θ ) to perform a sequence of graph convolution steps to update the node embeddings : ψ ( t+1 ) ( G ) = fθ ( ψ ( t ) ( G ) ) ∀t ∈ { 0 , 1 , · · · , T } . ( 3 ) A cover point C = < n1 , n2 , · · · , nm > is a sequence of nodes . The cover point identity is used to select the corresponding sequence of node embeddings of the cover point nodes . Since these sequences are of varying length , an LSTM layer is used to produce the cover point embeddings φ ( T ) ( C ) = LSTM ( < φ ( T ) ( n1 ) , φ ( T ) ( n2 ) , · · · , φ ( T ) ( nm ) > ) . ( 4 ) Test parameter embedding : For the input test parameters I , each of which can be integers or categorical , we learn an embedding for the parameters by passing them through a feed forward MLP layer as φ ( I ) = MLP ( Concat ( i1 , · · · , ip ) ) . ( 5 ) MLP layer : Finally , the test parameter φ ( I ) and cover point embeddings φ ( T ) ( C ) are concatenated and provided to a feed forward layer with sigmoid activation to predict for each cover point is_hit ( C , I ) = MLPσ ( Concat ( φ ( T ) ( C ) , φ ( I ) ) ) . ( 6 ) Given a supervised dataset of test inputs and the corresponding coverage information of different cover points in the RTL design , the network is trained using binary cross entropy loss . We find that our model learns more from local paths than global paths ( root to cover point ) . A reason for this is that GNNs are not proficient at learning long path information . In the case of a control flow , tracing and learning global paths is relevant . We use shortcut edges , where we add edges along every kth node along a path , to reinforce the relationship of long paths ( results in Appendix D ) . We use a variation of the GNN , called the GNN-MLP [ 7 ] to propagate edge information . We also used gating layers and residual layers in the GGNN .

Summary: The paper proposes an approach for predicting whether a given set of inputs will induce a given branch to be taken in an RTL program, along with an algorithm for synthesizing inputs to the program that induce a given branch to be taken. The objective is to aid verification of proposed hardware designs by reducing the number of actual simulations required to find test cases that fully cover the control flow graph of the RTL program. The approach is to use a graph neural network, enhanced with some task-specific features, along with a gradient-descent algorithm for finding inputs that induce a given branch to be taken. The paper evaluates the approach, showing that it leads to relatively high branch-taken predictive accuracy on three hardware architectures, and showing that the approach requires fewer evaluations than Bayesian Optimization driven search to find inputs that induce a given branch.