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: This paper introduces Design2Vec, which models the semantics of RTL programs using a graph neural network. The representation is used for 2 tasks: coverage prediction and test generation. The experiments on different designs show that Design2Vec can achieve high accuracy on the coverage prediction task and can also generate tests that cover hard-to-cover points.