Model Synthesis for Communication Traces of System-on-Chip Designs
Hao Zheng, Md Rubel Ahmed, Parijat Mukherjee, Mahesh C. Ketkar, Jin Yang
MModel Synthesis for Communication Traces ofSystem-on-Chip Designs
Hao Zheng, Md Rubel Ahmed
U of South Florida, Tampa, FL{haozheng,mdrubelahmed}@usf.edu
Parijat Mukherjee
Intel, Hillsboro, [email protected]
Mahesh C. Ketkar
Intel, Folsom, [email protected]
Jin Yang
Intel, Hillsboro, [email protected]
Abstract —Concise and abstract models of system-level behav-iors are invaluable in design analysis, testing, and validation.In this paper, we consider the problem of inferring modelsfrom communication traces of system-on-chip (SoC) designs. Thetraces capture communications among different blocks of a SoCdesign in terms of messages exchanged. The extracted modelscharacterize the system-level communication protocols governinghow blocks exchange messages, and coordinate with each other torealize various system functions. In this paper, the above problemis formulated as a constraint satisfaction problem, which is thenfed to a SMT solver. The solutions returned by the SMT solverare used to extract the models that accept the input traces. Inthe experiments, we demonstrate the proposed approach withtraces collected from a transaction-level simulation model of amulticore SoC design and traces of a more detailed multicoreSoC design developed in GEM5 environment.
Index Terms —specification mining, learning, system-on-chip
I. I
NTRODUCTION
Modern system-on-chip (SoC) designs integrate a largenumber of functional blocks procured from various sources.At runtime, these blocks communicate and coordinate witheach other through intricate system-level protocols to im-plement various sophisticated functions. SoC executions arehighly concurrent where a large number of system transac-tions following those protocols are often executed simulta-neously.Experiences have shown that communications amongdifferent blocks are the major source of various design andruntime errors. In order to thoroughly verify the communi-cation behavior of an SoC, well-defined and comprehensiveprotocol specifications are essential. However, in practice, suchspecifications are usually not available, ambiguous, incom-plete, or even contain errors. They often become outdated anddisconnected from the design implementation as the designprogresses.Many methods and approaches, e.g. [1]–[4], have beenproposed to mine patterns or models from traces of variousforms. They are inadequate to handle the SoC communicationtraces considered in this work. The existing methods extractpatterns of events from a trace if those events show strong tem-poral dependencies. However, in communication traces as aresult from concurrent executions of a large number of systemtransactions, events showing strong temporal dependenciesmay not be related according to the true dependencies in theground truth specifications. In the next section, an example isused to elaborate this challenge. As a result, existing mining methods often generate a large number of patterns, many ofwhich are not meaningful. Moreover, they may not be able toextract a model that includes all real valid patterns. Therefore,the extracted models can be large, not understandable, or evenmisleading.To address the above challenge, this paper describes amethod that can automatically infer reduced and concise mod-els from communication traces of SoC designs obtained fromsimulation or emulation. These traces considered in this paperare sequences of messages exchanged among design blocks.Given an input trace, the model extraction is formulatedas constraint satisfaction problem, which is then fed to anSMT solver. A model is constructed from solutions returnedby the SMT solver. The extracted model characterizes theunderlying system-level communication protocols that designblocks follow to generate the input trace.The main contribution of this work is, to our best knowl-edge, the first method that can automatically and efficientlysynthesize concise abstract models from system communi-cation traces for SoC designs. What distinguishes this workfrom previous ones is that it targets traces generated fromconcurrently executing multiple system transactions, and aimsto infer system-level protocols that govern the executionsof those system transactions. As a result, it avoids findingpatterns in the extracted models without true dependenciesby incorporating readily available design information, thusleading to reduced and more understandable models. It isefficiently, and scalable to very long traces.
Related Work.
Specification mining aims to extract patternsfrom various artifacts. A model based approach
Synoptic [5]mines invariants from logs of sequential execution traceswhere concurrency is recorded in partial order. It then gener-ates an FSM that satisfies the mined invariants.
Perracotta [1]is another software execution log analysis tool that minestemporal API rules. It describes a chaining technique that canbe used to find long sequential patterns. The work
BaySpec [3]extracts LTL formulas from Bayesian networks trained withsoftware traces. It requires traces to be clearly partitioned withrespect to different functions. For mining hardware traces, theapproaches presented in [6]–[10] mine assertions from eithergate-level representations [6], or RTL models [7]–[11]. Thework in [2] describes an assertion mining approach usingepisode mining from the simulation traces of transaction level a r X i v : . [ c s . I R ] F e b (cpu0:cache:rd_req)2 (cache:cpu0:rd_resp)3 (cpu1:cache:rd_req)4 (cache:cpu1:rd_resp)5 (cache:mem:rd_req)6 (mem:cache:rd_resp) (a) (b) Fig. 1:
CPU downstream read flows. (a) Definitions of messages,(b) Messages sequence diagram for the flows. This diagram isparameterized with x which can be or . models. Those approaches often lack support for finding longerpatterns, thus not able to find complex communication patternsinvolving multiple components.Our work shares some similarities to the methods onsoftware model synthesis. The aim of model synthesis isto identify a model from system execution traces such thatthe resulting model can accept the input traces. In [12], thedeterministic finite automata inference based on the originalevidence-driven state merging method [13] is extended andformulated as a graph coloring problem, which is then solvedby a Boolean satisfiability solver. Recently, Trace2Model isintroduced in [4] that learns non-deterministic finite automata(NFA) models from software execution traces using C boundedmodel checking technique. Similar work can also be foundin [14] The above approaches do not consider the concurrentnature of communication traces of SoC designs, and they relyon temporal dependencies discovered from traces to identifymodels. However, temporal dependencies are often not sameas the true dependencies that our work aims to find.II. B
ACKGROUND
System-level protocols are often represented as messageflows in SoC architecture documents. Fig. 1 shows a verysimple yet representative example of message flows for amulticore SoC design. This example specifies memory readoperations for two CPUs via a shared cache. Message flowsspecify temporal relations for a set of messages. As shown inFig. 1(a), each message is a triple ( src : dest : cmd ) wherethe src denotes the originating component of the messagewhile dest denotes the receiving component of the message.Field cmd denotes the operation to be performed at dest .For example, message ( CPU _ : Cache : rd _ req ) is the readrequest from CPU _ to Cache . Each message flow is associatedwith an unique start message to indicate initiation of aninstance of such flow, and with one or multiple different end messages to indicate its completion. A flow may containmultiple branches describing different paths a system canexecute such a flow. For example, the flow in Figure 1(b)has two branches specifying read operations in cases of cachehit or miss.During the execution of an SoC design, instances of flowsare executed concurrently. When a flow instance is executedalong one of its paths, messages on that path are exchangedwith runtime information, e.g. memory addresses. Typically, multiple instances of different flows that are executed concur-rently are captured in the traces.
Definition 2.1:
An SoC execution trace ρ is ρ =( ε , ε , . . . , ε n ) where ε i = { m i, , . . . , m i,k } is a set ofmessages observed at time i , and m i,j is an message instanceof some flow instance active at time i , for every m i,j ∈ ε i .To simplify the presentation, hereafter flows (messages) andflow instances (message instances) are used interchangeably iftheir meanings are clear in the context.An example trace from executing the flows in Figure 1 is ( { , } , , , , , , , , , , (1)where the numbers in the trace are the message indices asshown in the Fig. 1(a). The idea of message sets helps torepresent the outcomes of these concurrently executing flows.Note that the ordering of the messages in the same set of atrace is unknown. Given two messages m i and m j and a trace ρ , we define m i < ρ m j , denoting that m i occurs before m j in ρ , if m i ∈ ε i , m j ∈ ε j , and i < j . For simplification, a set ofa single message { m } is written as m . Moreover, a sequenceof one message ( m ) is also written as m .Given a trace as shown above, we aim to infer a modelthat characterizes the underlying message sequence protocolsas shown in Fig. 1 to explain the generation of the trace. Weuse finite state automata to represent the extracted model. Definition 2.2:
A finite state automaton (FSA) is a tuple M = ( Q, q , Σ , F, ∆) where Q is a finite set of states, q ∈ Q the initial state, Σ a finite set of symbols, F ⊆ Q the set ofaccepting states, and ∆ : Q × Σ → Q the transition relation.In our method, each symbol in Σ denotes an uniquemessage found in the input trace, and F = { q } . Givena FSA M , a flow execution scenario is defined as a set X = { ( M i , q ij ) | ≤ i ≤ n } where M i is the i th instanceof M , and q ij is a current state of M i . Suppose ρ is aninput trace and M is the model inferred from ρ . Initially,all M i in X are in q . Then, for every message m in ρ from the beginning, we can find an ( M i , q ij ) ∈ X such that ∆( q ij , m, q ij +1 ) holds for some state q ij +1 ∈ Q . After accepting m , we get a new execution scenario X (cid:48) with ( M i , q ij ) beingreplaced with ( M i , q ij +1 ) . At the end of the trace ρ , thecorresponding execution scenario is the same as the initialexecution scenario. Multiple instances of the model M in anexecution scenario reflect the fact that the trace is the resultfrom concurrent execution of multiple message flows when aSoC design runs.The challenge of inferring models from communicationtraces as shown above is that such traces are results fromexecuting many message flows concurrently, thus correlatingmessages correctly is very difficult. Note that (1 , , , and (3 , , , are two message flows specified in Fig. 1. Considerthe trace (1 , , , , , , , , , , , resulting from execut-ing the above message flows two times each in an interleavedmanner. In this trace, messages and show strong temporaldependency, but they are actually unrelated. Existing methodsfail to extract true message flows because they mostly relyon temporal dependencies to find interesting patterns. For ig. 2: FSA model produced using the method in [4]
Algorithm 1: AutoModel Input:
A trace ρ Output: a FSA M Extract unique messages in ρ into M ; Build the causality graph G from M ; Generate P the set of consistency constraints from G ; Get a solution sol of P using a SMT solver; Derive a FSA M from sol ;example, using Perracotta in [1] we can extract a sequentialpattern (1 , , , , which is highly confusing. Fig. 2 showsthe model produced using the method in [4]. Even though thismodel fits the trace perfectly, it contains message sequencesthat do not make sense with respect to the ground truth flows.Note that the message flows in Fig. 1 specifies causalityrelations among messages in addition to their temporal rela-tions. For example, when message ( CPU _ : Cache : rd _ req ) occurs, it causes either ( Cache : CPU _ : rd _ resp ) or ( Cache : Mem : rd _ req ) to happen. Therefore, we define structural causality below based on the observation: anymessage in an SoC execution trace is an output of a componentin reaction to a previous input message.Definition 2.3: Message m j is causal to m i , denoted as causal ( m i , m j ) , if m i . src = m j . dest . The above causality is referred to as structural againstthe functional causality in the flow specifications. In ourmethod, message sequences represented by the FSA modelextracted from a trace are required to satisfy the structuralcausality relation for every two consecutive messages. Withthis requirement, sequence (1 , , , would not be extractedas a model of the above trace. Applying the structural causalityrelation during the model extraction process is straightforwardas it only depends on basic structural information of a SoCdesign, which can be readily captured in messages.III. M ODEL S YNTHESIS
Algorithm 1 shows the outline of our method. It takes asan input a trace of messages ρ , and produces a FSA model M such that executing M in a certain way can lead to ρ to be re-produced. This method involves three major steps,collecting messages and building a causality graph (lines3-4), generating constraint problem P from the causalitygraph (line 5), and extracting a model from P (lines 6-7).These steps are explained in the following sections. A. Building Causality Graph
Given an input trace ρ , it is scanned to collect all uniquemessages. A message is unique if at least one of its three M = { , , , , , } Start = { , } End = { , } Constraint Solving Approach
Trace
12 56 3422 2222 22 22 222 22
Message types (a) (b)
Fig. 3:
Messages and causality graph constructed from a trace. attributes is different from all other messages already col-lected. Recall that each message flow is initiated with a startmessage, and completed with an end message. During themessage collection process, start and end messages are alsoidentified. Start and end messages can be identified from atrace as follows. A message m is a start message if m. src (cid:54) = m (cid:48) . dest for all m (cid:48) < m in ρ. (2)A message is an end message if m. dest (cid:54) = m (cid:48) . src for all m < m (cid:48) in ρ. (3)Scanning the trace from the beginning, we can find all startmessages by checking condition (2). Similarly, all end mes-sages can be found by scanning the trace from the end andchecking condition (3).Let all the collected messages be M , start messages Start ⊂ M , and end messages End ⊂ M . Next, we constructa causality graph from those messages, which captures allpossible structural causalities among every pair of messages.A causality graph G is a directed graph. It has a set of rootnodes, each of which is labeled with a start message in Start ,and a set of terminal nodes, each of which is labeled with aend message in
End . The other nodes are labeled with withmessages that are not start or end messages.Once the causality graph is constructed, the trace is scannedagain to find the supports for nodes and edges. The support ofa node is the number of instances of the labeled message inthe trace. The edge support is the number of co-existences ofmessages at the head and tail nodes of that edge in the trace.Consider the trace ρ = (1 , , , , , , , , , , , as anexamples. The collected messages and the causality graphfor this trace is shown in Figure 3. In the causality graph,numbers in blue are node supports, and numbers in red areedge supports. For example, we can find two instances of (1 , in the above trace, therefore, the edge from node 1 to node 5in the causality graph is labeled with . B. Generating and Solving Consistency Constraints
The constructed causality contains potential models for theinput trace, however, it also contains a lot of inconsistencies.Consider node 1 and all its outgoing edges. The node supportis , and the total support of its outgoing edges is . Thisinconsistencies is due to the ambiguities when finding supportsfor edges. In this example, since we do not know what theother messages should be correlated with message 1, weconsider all possibilities by finding supports for all binary
12 56 342 22 22 222 22 q q q q q
56 4 (a) (b)
Fig. 4: (a) The modified causality graph showing a consistentsolution, and (b) the corresponding FSA model. sequences starting with message 1, i.e. , (1 , , (1 , , and (1 , . As a result, message 1 is counted more times than itshould be.The goal of this step is to find a set of edge supports suchthat they are consistent with node supports. First, let x → y denote an edge from node x to y , and sup ( · ) be the supportof either a node or an edge. Additionally, let c ( n → n (cid:48) ) bea variable about the support of n → n (cid:48) . From the causalitygraph, we derive the following constraints.1) For each node n , and all its outgoing edges n → n (cid:48) ,create a constraint sup ( n ) = (cid:88) all n → n (cid:48) c ( n → n (cid:48) )
2) For each node n (cid:48) and all its incoming edges n → n (cid:48) ,create a constraint sup ( n (cid:48) ) = (cid:88) all n → n (cid:48) c ( n → n (cid:48) )
3) For each edge n → n (cid:48) , create a constraint ≤ c ( n → n (cid:48) ) ≤ sup ( n → n (cid:48) ) The first two constraints require consistencies between everynode and its incoming and outgoing edges. The third constraintreflects the fact that it is unknown about the exact edgesupports when scanning the trace for instances of an edgeexcept it can be no more than the supports directly obtainedfrom the trace.
C. Deriving Model
After the constraint problem P is generated, it is fed into aconstraint solver to find a solution. A solution sol of P is aset of edges in the causality graph G such that their supportsare consistent with the node supports, { ( n → m ) | ( n → m ) in G, and c ( n → m ) > in sol } . The solution can be visualized as a modified causality graphwith the edge supports as returned from the solver. An examplesolution for the causality graph in Fig. 3 is shown in Fig. 4(a)and the corresponding FSA model is shown in Fig. 4(b). Notethat in Fig. 4(a), edges from Fig. 3 with zero-supports in thesolution are removed.For a set of constraints P generated in the previous step, alarge number of consistent solutions can be generated. Finding Algorithm 2: ModelExtractinput :
Constraints P input : Size limit of solutions sz output: A reduced solution sol C = ∅ ; Find S = { sol | sol | = P } of size sz ; foreach sol ∈ S do sol (cid:48) := ReduceModel ( P, sol ) ; C := C ∪ { sol (cid:48) } ; Let sol ∈ C with the minimal size; return sol ; Algorithm 3: ReduceModelinput :
Constraints P input : A solution sol output:
A reduced solution sol (cid:48) Get an edge ( n → m ) in sol ; P (cid:48) := P ∪ c ( n → m ) = 0 ; if P (cid:48) is unjustifiable then return sol Get a new solution sol (cid:48) | = P (cid:48) ; return ReduceModel( P (cid:48) , sol (cid:48) );the minimal solution is NP-hard. Therefore, the goal of thisstep is to generate a reduced, not necessarily minimal, solutionefficiently. In our method, we query the solver to return a setof solutions S = { sol | sol | = P } . Then, for each solution sol ∈ S , and for each edge ( n → m ) with non-zero supportin sol , a new constraint is generated where its support is setto . After adding this constraint into the solver, if the solverbecomes unjustifiable, sol is return as the candidate model.Otherwise, the above step repeats for the reduced solution sol (cid:48) .At the end, from the set of reduced solutions, we select the onewith the smallest number of edges with non-zero support, andreturn it to the user. The model extraction method is shown inAlgorithm 2. The model in Fig. 4 shows an example modelextracted using Algorithm 2. Note that sequence (1 , or (2 , is not included in the model.After a reduced solution is returned as described above, aFSA can be constructed from it. This step is straightforward,and we skip its explanation.IV. E XPERIMENTAL R ESULTS
We collect ten message flows which are abstracted fromsystem-level communication protocols used in real industrySoC designs. Each flow consists of a number of branches,resulting in a total number of message sequences tospecify various system communication scenarios such ascache-coherent memory accesses, upstream read/write, powermanagement, etc. Although greatly simplified, these messageflows capture essential communicating behaviors among typ-ical components in a SoC design, including CPUs, caches,interconnect, memory controller, and peripheral devices, etc. ABLE I:
Results from the simulation traces
Traces small 22
31 84
31 78
31 70large 60
92 75
87 72
100 62
We implement a transaction-level simulation model wherecomponents in the model communicate with each other ac-cording to the protocols specified by these message flows.During simulation, each master component randomly initiatesa message flow instance by generating a message, and sendsit to the next component as specified. Since the messagepayloads are not considered in the message flows, they arenot generated during the simulation, and each message onlycarries a command and the address of the destination com-ponent. In order to mimic the concurrent nature of modernSoC designs, the interconnect component of our simulationmodel is modeled as a switch network. This component modelallows messages from a source to go to all other destinationsas specified. In case when messages arriving from multiplesources simultaneously, they are interleaved using an internalarbiter before being sent out. All components run concurrentlywithout global synchronization.We simulate the model multiple times, collecting two setsof traces of different lengths. The first set of traces aregenerated when the model is restricted to only allow CPUsto initiate cache coherent downstream read flows while allother components are configured to only react to incomingmessages. This set of traces are referred to as small . Thesecond set of traces are generated with all components in themodel are enabled to initiate message flows. This set of tracesare referred to as large . For each configuration, we simulatethe model three times. In each run, a limit is imposed onthe number of instances of each flow allowed to be generatedduring simulation. We collect a total of six traces.We implement the method described in this paper in Python.The SMT solver for solving the constraint problems in ourmethod is the Python distribution of the Z3 solver [15]. Werun our tool on the sets of collected traces, and the resultsare shown in Table I. The first two columns show the types ofand the number of unique messages in each type of traces. Thethird column shows the lengths of the traces in terms of thetotal number of messages included. The fourth column showsthe number of states in the extracted FSA models, while thelast column shows the runtime in seconds.From Table I, the runtime for handling each trace takesabout 1 to 1.5 minutes, and it does not change much for tracesof different lengths. This phenomenon can be explained asfollows. The major portion of the total runtime ( > isspent on the SMT solving, which is dependent on the sizesof the causality graphs in terms of the numbers of edges withnon-zero support. The size of causality graphs depends on thenumber of unique messages in traces, and is much smaller than CPU 0
L1I L1D
Coherent BusL2 CacheCoherent BusMem_ctrl:DDR3_1600_8x8
CPU 1
L1I L1D
CPU 2
L1I L1D
CPU 3
L1I L1D
Fig. 5:
A quad-core simulation model developed in GEM5 System-Call Emulation mode. trace lengths. Additionally, causality graphs are relatively sim-ilar for traces of the same type. Therefore, solving constraintproblems generated from such causality graphs incurs similarcomplexity, and its runtime performance is largely independentof trace lengths. This observation contrasts our method againstprevious work such as [4].There are two other interesting observations from Table I.First, the runtime drops slightly for the traces of the same type;second, the runtime for the traces of different types is alsosimilar. These observations seem to contradict to the aboveanalysis. However, we believe these results are due to thenature of SMT solving. For traces of the same type, they arerandomly generated, resulting different constraint problems.As a result, the initial sets of solutions generated are different,They would lead to different amount of runtime needed toreduce every one of those initial solutions. Overall, the runtimetaken by invoking procedures in Algorithms 2 and 3 could bedifferent for the traces of the same type. The above analysiscan also explain why the runtime for traces of type
Large isclose to that for small traces.We compare our method with
Trace2Model described in [4].It is similar to our method in that both try to synthesize FSAmodels to fit input traces by using some forms of constraintsolving. However,
Trace2Model does not consider concurrencynature of the traces as our method does, and it extracts amodel only based on sequential dependencies in the traces.In experiments, we fix the size of the sliding window w in Trace2Model to as suggested in [4]. Trace2Model suffersfrom considerably long run time when being applies to ourtraces, and it does complete even for the small traces after minutes. Therefore, no results with Trace2Model are reported.
Experiments on a GEM5 Model.
We develop a realisticsystem model in GEM5, and gather communication tracesfor a real-workload. This model, developed in Syscall Emula-tion (SE) mode, consists of four x86 TimingSimpleCPUs, eachwith private Level 1 (L1) data (64kB) and instruction (16kB)caches. There is a shared Level 2 (L2) cache of size 256kB.L1 and L2 caches are interfaced with a coherent bus thatimplements MOESI-like coherent protocol provided in GEM5.There are also a memory bus and a DDR3_1600_8x8 memorycontroller with a memory of 512MB. A high-level view of thesimulation system is given in Figure 5.In this GEM5 model, we insert monitors, one for eachmaster-slave interface between two components. These moni-a) (b) Fig. 6: (a) A memory write protocol specification in GEM5 documentation showing the case of write miss in DCache; (b) A path in theextracted FSA model in a sequence diagram showing the memory write operations executed by the system simulation model.
Fig. 7:
Another example of message sequences for dirty memoryblock write-back operations from the extracted FSA model. tors observe and dump the packet s ( eq. messages) exchangedover those interfaces into a trace file. Each packet is capturedwith several attributes including master/context ids, command,packet type, and address, We simulate this model by runninga version of the Peterson’s algorithm with two threads, onefor each CPU core. A trace is collected using the embeddedcommunication monitors, and it has packets. Thereare unique packets identified for that trace.Using the method in this paper, we extract a model with states, which is one of models with the minimal numberof states. The process takes about minutes using MBmemory at peak. Again,
Trace2Model in [4] is not be able tofinish within minute time limit.Figure 6(b) shows an example of message sequences inthe FSA model deserved from the trace, while Figure 6(a)shows the similar memory write protocol from the GEM5system documentation [16]. Comparing Figure 6(b) to (a), ourmethod is able to find the majority portion of the protocol inFigure 6(a). The two messages missing in Figure 6(b) is theresult of incomplete search for solutions as described in theprevious section. Another example of the extracted model isshown in Figure 7. It shows another memory write protocolwhere a dirty block is written back to the L2 cache under aL2 miss. From this example, we can find out that the GEM5simulation model uses write-allocate policy on misses.V. C ONCLUSION
Model synthesis for communication traces from highlyconcurrent SoC executions is very challenging. We describea method that infers reduced and abstract models from suchtraces, and show that it is able to infer models efficiently, evenfor very long traces. The extracted models include meaningfulinformation about system-level protocols implemented in the target SoC designs. We plan to enhance the method to allowuser insights to be used easily to guide the search process.
Acknowledgment
The research presented in this paper waspartially supported by gifts from the Intel Corporation, and agrant from Cyber Florida.R
EFERENCES[1] Jinlin Yang, David Evans, Deepali Bhardwaj, Thirumalesh Bhat, andManuvir Das. Perracotta: Mining temporal api rules from imperfecttraces. In
Proceedings of the 28th International Conference on SoftwareEngineering , ICSE ’06, pages 282–291, 2006.[2] Lingyi Liu and Shobha Vasudevan. Automatic generation of systemlevel assertions from transaction level models.
Journal of ElectronicTesting , 29(5):669–684, Oct 2013.[3] Artur Mrowca, Martin Nocker, Sebastian Steinhorst, and Stephan Gün-nemann. Learning temporal specifications from imperfect traces usingbayesian inference. In
Proceedings of the 56th Annual Design Automa-tion Conference 2019 , DAC ’19, pages 96:1–96:6, 2019.[4] Natasha Jeppu, Tom Melham, Daniel Kroening, and John O’Leary.Learning concise models from long execution traces. In
DAC ’20 , June2020.[5] Ivan Beschastnikh, Yuriy Brun, Sigurd Schneider, Michael Sloan, andMichael D. Ernst. Leveraging existing instrumentation to automaticallyinfer invariant-constrained models. In
Proceedings of the 19th ACM SIG-SOFT Symposium and the 13th European Conference on Foundationsof Software Engineering , ESEC/FSE ’11, pages 267–277, 2011.[6] Wenchao Li, Alessandro Forin, and Sanjit A. Seshia. Scalable specifi-cation mining for verification and diagnosis. In
Proceedings of the 47thDesign Automation Conference , DAC ’10, pages 755–760, 2010.[7] Samuel Hertz, David Sheridan, and Shobha Vasudevan. Mining hard-ware assertions with guidance from static analysis.
Trans. Comp.-AidedDes. Integ. Cir. Sys. , 32(6):952–965, June 2013.[8] A. Danese, F. Filini, and G. Pravadelli. A time-window based approachfor dynamic assertions mining on control signals. In ,pages 246–251, Oct 2015.[9] Alessandro Danese, Tara Ghasempouri, and Graziano Pravadelli. Au-tomatic extraction of assertions from execution traces of behaviouralmodels. In
Proceedings of the 2015 Design, Automation, &Test inEurope Conference & Exhibition , DATE ’15, pages 67–72, 2015.[10] Alessandro Danese, Nicolò Dalla Riva, and Graziano Pravadelli. A-team:Automatic template-based assertion miner. In
Proceedings of the 54thAnnual Design Automation Conference 2017 , pages 37:1–37:6, 2017.[11] Po-Hsien Chang and Li.-C Wang. Automatic assertion extraction viasequential data mining of simulation traces. In
ASPDAC , pages 607–612, 2010.[12] Marijn J. Heule and Sicco Verwer. Software model synthesis usingsatisfiability solvers. 18(4), 2013.[13] Kevin J. Lang, Barak A. Pearlmutter, and Rodney A. Price. Results ofthe abbadingo one dfa learning competition and a new evidence-drivenstate merging algorithm. In
ICGI , page 1–12, 1998.[14] V. Ulyantsev and F. Tsarev. Extended finite-state machine inductionusing sat-solver. In