CN112733478B - Apparatus for formal verification of a design - Google Patents

Abstract

An apparatus for formal verification of a design is provided. The device includes: an input module for receiving a state of a state machine corresponding to the design at runtime, a storage module coupled to the input module for storing a reference state provided by the input module according to an enable signal, a save module coupled to the storage module for receiving a save signal and generating the enable signal based on the save signal, and a comparison module coupled to the input module and the storage module, respectively, for comparing a current state provided by the input module and the reference state stored by the storage module, wherein the comparison module generates a cycle indication signal for indicating that a cycle exists in response to the current state and the base state being the same. Compared with the method for directly verifying the activity attribute, the device can be used for detecting the circulation and improving the form verification efficiency.

Description

Apparatus for formal verification of a design

Technical Field

The present application relates to the field of computer software technology, and more particularly, to an apparatus for formal verification of a design.

Background

Formal Verification (Formal Verification) refers to the complete mathematical demonstration or Verification of whether an implementation of a circuit actually implements the functionality described by a circuit design. However, in formal verification, there are some attributes that prove to be relatively difficult.

Disclosure of Invention

In view of the above, the present application proposes an apparatus for formal verification of a design.

The present application provides an apparatus for formal verification of a design, comprising: an input module for receiving a state of a state machine corresponding to the design at runtime, a storage module coupled to the input module for storing a reference state provided by the input module according to an enable signal, a save module coupled to the storage module for receiving a save signal and generating the enable signal based on the save signal, and a comparison module coupled to the input module and the storage module, respectively, for comparing a current state provided by the input module and the reference state stored by the storage module, wherein the comparison module generates a cycle indication signal for indicating that a cycle exists in response to the current state and the base state being the same.

The device for verifying the design form utilizes the storage module to generate the enable signal based on the storage signal, so that the storage module can store the reference state based on the enable signal, further can utilize the comparison module to compare the current state with the reference state, and can generate a cycle indication signal for indicating that a cycle exists when the current state is the same as the base state, thereby completing the detection of the cycle, and further can verify the activity attribute more easily. Compared with the method for directly verifying the activity attribute, the method for detecting the circulation can improve the form verification efficiency and save the calculation power.

Drawings

In order to more clearly illustrate the technical solutions in the present application or the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only the present application, and that other drawings can be obtained by those skilled in the art without inventive efforts.

Fig. 1 shows a schematic structural diagram of an exemplary electronic device provided in an embodiment of the present application.

FIG. 2A shows a schematic diagram of an exemplary formal verification tool according to embodiments of the present application.

FIG. 2B shows a diagram of a conversion from an RTL design to an abstract syntax tree.

Fig. 2C shows a schematic structural diagram of a backend according to an embodiment of the present application.

Fig. 3 illustrates a schematic diagram of an exemplary finite state machine according to an embodiment of the present application.

Fig. 4A shows a schematic structural diagram of an exemplary apparatus provided in an embodiment of the present application.

Fig. 4B shows a schematic structural diagram of a saving module provided in an embodiment of the present application.

Fig. 4C shows a schematic diagram of an exemplary state machine according to an embodiment of the application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings in combination with specific embodiments.

It is to be noted that, unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. As used in this application, the terms "first," "second," and the like do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items. The terms "connected" or "coupled" and the like are not restricted to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Fig. 1 shows a schematic structural diagram of an electronic device 100 provided in this embodiment. The electronic device 100 may be, for example, a computer host. The electronic device 100 may include: a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a bus 110. Wherein processor 102, memory 104, network interface 106, and peripheral interface 108 are communicatively coupled to each other within the device via bus 110.

The processor 102 may be a Central Processing Unit (CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits. The processor 102 may be used to perform functions associated with the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated into a single logic component. As shown in FIG. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102 c.

The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). For example, as shown in fig. 1, the stored data may include program instructions (e.g., for implementing aspects of the present application) as well as data to be processed (e.g., memory 104 may store temporary code generated during the compilation process). The processor 102 may also access stored program instructions and data and execute the program instructions to operate on the data to be processed. The memory 104 may include volatile memory devices or non-volatile memory devices. In some embodiments, the memory 104 may include Random Access Memory (RAM), Read Only Memory (ROM), optical disks, magnetic disks, hard disks, Solid State Disks (SSDs), flash memory, memory sticks, and the like.

The network interface 106 may be configured to provide communications with other external devices to the electronic device 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., Bluetooth, Wi-Fi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination of the above. It is to be understood that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.

The peripheral interface 108 may be configured to connect the electronic device 100 with one or more peripheral devices to enable input and output of information. For example, the peripheral devices may include input devices such as keyboards, mice, touch pads, touch screens, microphones, various sensors, and output devices such as displays, speakers, vibrators, indicator lights, and the like.

The bus 110 may be configured to transfer information between various components of the electronic device 100 (e.g., the processor 102, the memory 104, the network interface 106, and the peripheral interface 108), such as an internal bus (e.g., a processor-memory bus), an external bus (a USB port, a PCI-E bus), and so forth.

It should be noted that although the above-described device only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the device may also include other components necessary to achieve normal operation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may also include only those components necessary to implement the embodiments of the present application, and not necessarily all of the components shown in the figures.

FIG. 2A shows a schematic diagram of an exemplary formal verification tool 200 according to an embodiment of the present application. In the field of chip design, the format verification tool 200 may be a GalaxFV format verification tool produced by seocho technologies, inc. The formal verification tool 200 may be a computer program running on the electronic device 100. In some embodiments, formal verification tool 200 may include components such as a simulator.

Formal verification tool 200 may perform formal verification on a system design to be verified based on the system design and an Assertion (Assertion) used to formally verify the system design. Inputs to formal verification tool 200 may include system design 208 and assertions 210.

System design 208 may be a hardware or software design. For example, system design 208 may be a design described by software languages such as C, C + +, Java, and the like, hardware description languages such as VHDL, Verilog, SystemVerilog, and the like, or Register Transfer Level (RTL) code, and the like. In the description of the present application, an integrated circuit design is illustrated as an example of system design 208.

In some embodiments, system design 208 may be an RTL design. In integrated circuit design, RTL (register-transfer level) is an abstraction level used to describe the operation of synchronous digital circuits. At the RTL level, the chip is made up of a set of registers and logical operations between the registers. This is so because most circuits can be viewed as storing binary data by registers, and processing data by logical operations between registers, and the flow of data processing is controlled by a sequential state machine, and these processes and controls can be described by a hardware description language.

Assertion 210 can be, for example, a SystemVerilog Assertion (SVA) described by SystemVerilog. Assertions 210 can be used to describe the desired behavior of system design 208. Proof or witness assertions 210 can be used to verify that system design 208 is correct. Thus, assertion 210 is a behavioral description associated with the correctness of system design 208.

As shown in FIG. 2A, the form verification tool 200 may include a front end 202, a middle end 204, and a back end 206. The system design 208 and the assertion 210 ultimately output verification results after processing via the front end 202, the middle end 204, and the back end 206.

The front end 202 may comprise a semantic analysis unit 2022 and an integration unit 2024.

Semantic analysis unit 2022 may be used to semantically analyze system design 208 to convert system design 208 described by a particular language into an expression form suitable for further synthesis. Semantic analysis may include lexical analysis (lexical analysis) and syntactic analysis (syntax analysis). Lexical analysis can convert a sequence of characters into a sequence of words (Token), and syntactic analysis can perform syntactic checks on the description of system design 208 to construct a data structure (typically a hierarchical data structure such as a parse tree, abstract syntax tree, etc.) consisting of the input words.

The system design 208 (e.g., RTL design) may be converted to an Abstract Syntax Tree (AST) after processing via the semantic analysis unit 2022.

FIG. 2B shows a diagram of the conversion of RTL design 208 into abstract syntax tree 212. As shown in FIG. 2B, the RTL design 208 of a top module can be converted into an abstract syntax tree 212 with always blocks as root nodes.

Returning to fig. 2A, synthesis unit 2024 may logically synthesize system design 208 based on an abstract syntax tree (e.g., syntax tree 212 of fig. 2B). For example, the synthesis unit 2024 may instantiate a module, identify the mechanics of the real circuit and convert to a circuit unit (e.g., register, adder, comparator, Multiplexer (MUX), etc.).

The synthesis unit 2024 may further convert the above circuit units into gates (e.g., AND gate, OR gate, XOR gate, etc.) AND flip-flops (e.g., flip-flop), optimize the circuit logic, AND finally generate a circuit netlist (netlist). The circuit netlist is typically gate-level, and thus the circuit netlist is also commonly referred to as a gate-level circuit netlist.

In some embodiments, synthesis unit 2024 may generate a generic netlist model at word-level (word-level), fully-expanded (full-view), and hierarchical (hierarchical structure). Such a generic netlist model may conveniently be subjected to a traversal operation using a traversal tool (e.g., a traversal function).

The middle end 204 may include a modeling unit 2042 to generate a formal verification data model from the assertion 210 and the circuit netlist.

In some embodiments, modeling unit 2042 may convert the input assertion 210 into a verification target. As described above, assertions 210 describe behavior expected by system design 208, and such behavior may generally correspond to one or more formal verification properties. In other words, the assertion 210 may be equivalently transformed into a formal verification property that is desired to be certified or fake, i.e., into a verification target. The verification target may include assertion verification (assert), space-universal verification (vacuum), witness verification (witness), and the like.

In some embodiments, modeling unit 2042 may generate a formal verification data model based on the verification target and the circuit netlist provided by front end 202, and back end 206 may then perform formal verification based on the formal verification data model. In some embodiments, modeling unit 2042 may represent the verification target or circuit netlist by an expression (e.g., a regular expression, a sequential expression, etc.), and thus, the formal verification data model may be an expression-based data model.

In still other embodiments, the middle end 204 can also generate state data (e.g., the initial state of the functional module to be verified) needed for formal verification from the assertion 210 and the circuit netlist.

The back-end 206 may distribute the formal verification data model to a corresponding verification engine for formal verification.

Fig. 2C shows a schematic diagram of the back end 206 according to an embodiment of the application. As shown in fig. 2C, the backend 206 may include a task distributor 2062, at least one adapter 2064 (e.g., adapters 2064(a), 2064(b), 2064(C), …, 2064(n)), and at least one solver 2066 (e.g., solvers 2066(a), 2066(b), 2066(C), …, 2066 (n)). The solvers may also be referred to as engines.

The task allocator 2062 may be configured to determine a set of adapters and solvers corresponding to a validation target based on the validation target.

The adapter 2064 (e.g., 2064(a)) may generate an input for the solver 2066 based on the formal verification data model. For example, an expression (e.g., a regular expression, a sequential expression, etc.) may be expanded by the adapter 2064. Based on the expression, the adapter 2064 may further build a corresponding state machine, for example.

Solver 2066 may be used to certify or verify a pseudo-verification target based on the formal verification data model. For example, system design 208 is property verified (e.g., security property verified, liveness property verified, etc.) based on the state machine to which the assertion corresponds. Solver 2066 may include a Satisfiability (SAT) solver, a binary decision diagram (BDB) solver, a Quantized Boolean Formula (QBF) solver, and so on.

In formal verification, there are some attributes that prove to be relatively difficult. For example, the activity attribute (s _ eventualy (p)) requires that a certain state p occurs at least once in all cycles before being judged as true. I.e. in the operation of the logic system design, the state p must eventually occur.

If the liveness attribute is to be verified, the logic system design needs to be run continuously until state p occurs or eventually no state p occurs, according to the definition of the liveness attribute. It can be appreciated that such a proof is difficult due to the need to continuously run the logic system design.

In some embodiments, converting the activity attribute to an attribute that is easier to document can facilitate the document of the activity attribute.

For example, the liveness property may be converted to a security property. The security property means that bad event q does not occur. For example, one important security attribute is that the final state of the logic system design is correct, i.e., no bad state has occurred. As another example, a security attribute may be that every state of the logic system design is correct.

The security attributes are relatively easy to prove. For example, event q may be attested using an assertion (q). If the event q is true, the logic system design problem is shown, because a bad event q occurs; if the event q is false, the logic system design is correct.

Fig. 3 illustrates a schematic diagram of an exemplary finite state machine 300 according to an embodiment of the present application.

As shown in FIG. 3, state S of Finite State Machine (FSM)300 may include states S0, S1, S2, S3, S4. Taking states S0-S2 as an example, the next state for each state may be itself or its next state (e.g., the next state for state S0 may be state S0 or state S1). Similarly, the next state of state S3 may be state S4 or state S1. As can be seen, in the finite state machine 300, there may be at least four cycles, i.e., cycles L0-L3.

Assume that formal verification tool 200 needs to prove an activity attribute of p = S _ eventualy (S2), i.e., that state machine 300 will eventually reach state S2. It should be noted that state S4 is not a circuit internal signal (signal) and there is no way to assert the internal state of formal verification tool 200.

Each state of system design 208 (e.g., states S0-S4) may be a mapping of a set of one or more signals (signals) of system design 208 at a time. At some point, when a state occurs, the state may be considered true (true) at that point; otherwise, the state is considered false (false) at this time.

Thus, for such an activity attribute p = S _ eventually (S2) (i.e., S2 must eventually occur), we can decompose it into the following 3 cases.

In the first case: when there is no loop, state S2 is true. At this time, the activity property p is true.

In the second case: there is a loop and state S2 occurs. At this time, the activity property p is true.

In the third case: there is a loop and state S2 has never been passed. At this time, the activity attribute p is false.

It follows that for the activity property p only the counter-example of the third case exists. Thus, a unique counter-example is found compared to the first and second cases of certification, thus proving that the third case is a simpler way of certification.

As can be seen from the foregoing description of the security attribute, the "never-past state S2" in the third case is a security attribute.

Thus, we can convert the activity attribute to a safety attribute. Formal verification of the activity attribute is correspondingly converted into the existence of a verification loop and the presence of state S2 is determined (e.g., using assertion statement alert (S2)).

Since assertion of the security attributes is a basic function of the formal verification tool 200, it is easy to determine whether the state S2 appears, and thus verification of the activity attributes mainly needs to solve how to verify the existence of the loop.

In order to verify the existence of cycles, the embodiment of the application provides a device for performing formal verification on a design, which comprises: an input module for receiving a state of a state machine corresponding to the design at runtime, a storage module coupled to the input module for storing a reference state provided by the input module according to an enable signal, a save module coupled to the storage module for receiving a save signal and generating the enable signal based on the save signal, and a comparison module coupled to the input module and the storage module, respectively, for comparing a current state provided by the input module and the reference state stored by the storage module, wherein the comparison module generates a cycle indication signal for indicating that a cycle exists in response to the current state and the base state being the same.

According to the device for verifying the design form, the storage module is used for generating the enabling signal based on the storage signal, so that the storage module can store the reference state based on the enabling signal, the comparison module can be used for comparing the current state with the reference state, and the cycle indicating signal for indicating that the cycle exists can be generated when the current state is the same as the basic state, so that the detection of the cycle is completed, and the verification of the activity attribute can be easily performed. Compared with the method for directly verifying the activity attribute, the method for detecting the circulation can improve the form verification efficiency and save the calculation power.

Fig. 4A shows a schematic structural diagram of an exemplary apparatus 400 for formal verification of a design provided by an embodiment of the present application. Formal verification tool 200 may execute code corresponding to apparatus 400 to implement apparatus 400 in device 100 and perform formal verification on a design (e.g., system design 208 of fig. 2A).

As shown in fig. 4A, the apparatus 400 may include an input module 404, a storage module 406, a save module 408, a comparison module 410, and an output module 412.

Input module 404 may receive a state 414 of state machine 402 at runtime corresponding to a design (e.g., system design 208 of FIG. 2A). As described above, a state may be a mapping of a set of one or more signals of system design 208 at a time. Thus, in some embodiments, input module 404 may obtain state 414 by reading values of registers internal to design 208. The state 414 may be stored in a storage module 406 or may be input to a comparison module 410.

The storage module 406 may be coupled to the input module 404, the saving module 408, and the comparison module 410, respectively, and may receive the state 414 obtained by the input module 404 and the enable signal 416 sent by the saving module 408. Also, the storage module 406 may store the state 414 provided by the input module 404 at one time as a reference state 418 under the influence of the enable signal 416, and may provide the reference state 418 to the comparison module 410 for comparison with the state 422 at another time.

In some embodiments, the storage module 406 may include an enable terminal 4062. The enable terminal 4062 may be configured to receive the enable signal 416 to cause the memory module 406 to latch the reference state 418 under the effect of the enable signal 416, so that the memory module 406 may subsequently provide the reference state 418 to the comparison module 410 for comparison with the state 422 at another time.

The save module 408 may receive a save signal (save signal)420 and generate the enable signal 416 based on the save signal 420. In some embodiments, the save signal 420 may be a random signal, such as a "1" or a "0".

Fig. 4B shows a schematic structural diagram of the saving module 408 provided in the embodiment of the present application.

As shown in fig. 4B, in some embodiments, the saving module 408 may further include an or gate unit 4082, a register unit 4084, a not gate unit 4086, and an and gate unit 4088. A first input of or-gate unit 4082 may be adapted to receive save signal 420, a second input of or-gate unit 4082 may be connected to an output of register unit 4084 and an input of not-gate unit 4086, and an output of or-gate unit 4082 may be connected to an input of register unit 4084. The output of the not gate unit 4086 may be connected to a first input of the and gate unit 4088. A second input of the and gate unit 4088 may be configured to receive the save signal 420, and an output of the and gate unit 4088 may be configured to output the enable signal 416.

The comparison module 410 may compare the current state 422 provided by the input module 404 to the reference state 418 stored by the storage module 406, and when the current state 422 and the base state 418 are the same, the comparison module 410 may generate a loop indication signal 424 indicating that a loop (e.g., the loops L0-L3 of fig. 3) is present. In some embodiments, the loop may be a loop obtained after converting an activity attribute assertion that verifies a design (e.g., system design 208 of FIG. 2A) into a security attribute assertion, such that by verifying the existence of the loop, the activity attribute may be verified in combination with the determination of the corresponding security attribute assertion.

The output module 412 may be configured to receive the output signal 426 of the register unit 4084 and the output signal of the comparison module 410. Also, the output module 412 may output a cycle indication signal 424 from the comparison module 410 when the current state 422 and the base state 418 are the same. In some embodiments, as shown in fig. 4B, the output module 412 may include an and gate unit 4122, a first input of the and gate unit 4122 being connected to the output of the register unit 4084, and a second input of the and gate unit 4122 being connected to the output of the comparison module 410.

As shown in FIGS. 2B and 4B, formal verification tool 200 may convert a design into a state machine 402, and then the state 414 of state machine 402 at runtime is extracted by input module 404 and sent to storage module 406 and comparison module 410, respectively.

At the same time, the save module 408 may receive a save signal 420. The save signal 420 may be a random signal (e.g., "1" or "0"). In some embodiments, the save signal 420 may be generated by a random signal generator (not shown). When the save signal 420 is "0", the register unit 4084 saves this "0" because the output of the register unit 4084 is connected to the second input of the or gate unit 4082. When the save signal 420 jumps from "0" to "1", since the register unit 4084 saved "0" at the previous time, the input of the not gate unit 4086 is "0", the output is "1", the not gate unit 4086 outputs "1" to the first input terminal of the and gate unit 4088, and at the same time, the second input terminal of the and gate unit 4088 receives the save signal 420 jumped to "1" and outputs "1". The enable terminal 4062 of the storage module 406 receives the "1" output from the and gate unit 4088 and is enabled, thereby locking and saving the state 414 it currently receives from the input module 404 as the reference state 418.

At this time, since the first input terminal of the or gate unit 4082 receives the save signal 420 which jumps to "1", the register unit 4084 is set to "1", and the output of the register unit 4084 is simultaneously the input of the second input terminal of the or gate unit 4082, so that the input of one of the input terminals of the or gate unit 4082 is kept at "1". Therefore, even if the save signal 420 jumps from "1" to "0" again, since the output of the register unit 4084 is locked to "1", the output of the or gate unit 4082 is always "1", and the output of the not gate unit 4086 is always "0". Further, the output of the AND gate 4088 is always "0", such that the enable terminal 4062 of the memory module 406 cannot be enabled again, and thus remains locked in the memory module 406, i.e., the reference state 418. Meanwhile, since the output of the register unit 4084 is always 1, the value of the output signal of the and gate unit 4122 is determined by the output of the comparing module 410, that is, when the comparing module 410 outputs the cycle indicating signal 424, the output module 412 outputs the cycle indicating signal 424.

Thus, by saving one transition of signal 420, one state 414 can be locked out in memory block 406 as reference state 418. Since the comparison module 410 is coupled to the input module 404 and the storage module 406, respectively, the state 414 (or the current state 422) received by the input module 404 can be continuously collected, and thereafter, when the state 414 changes continuously, the newly input state 422 can be continuously compared with the reference state 418 latched by the storage module 406. When the new state 422 is the same as the locked state 418, the comparison module 410 outputs a "1" indicating that the newly entered state 422 is the same as the locked state 418. That is, a cycle exists. This completes the detection of the cycle and thus the activity profile can be easily verified.

Fig. 4C shows a schematic diagram of an exemplary state machine 402 according to an embodiment of the application.

The save signal 420 also serves as a random state excitation signal for driving a change of state of the state machine 402. As shown in FIG. 4C, there are two states at time t0 for state machine 402, resulting from the actuation of the values "0" and "1" respectively of save signal 420. Similarly, at time t1, the state machine may generate four states based on the state at time t0 based on the value of the hold signal 420, and further, at time t2, the state machine may generate eight states based on the four states at time t1 based on the value of the hold signal 420. It can be seen that this replication process results in an exponential increase in the number of states, which is computationally expensive.

The purpose of loop detection is whether a state following one will return to that state. After one state (e.g., state "0") at time t0 is locked in the storage module 406, the other state corresponding to that state (e.g., state "1" at time t0 in FIG. 4C) has no effect on the operation results. Thus, in some embodiments, further replication of state machine 402 may be avoided by imposing constraints.

Thus, in some embodiments, the state 414 may be a state resulting from applying a constraint signal to the state machine 402, wherein the constraint signal is used to prune a derivative state machine resulting from copying the state machine 402 based on the save signal 420 after the output signal of the register unit 4084 is locked, thereby avoiding further copying of the state machine 402.

Thus, in some embodiments, as shown in fig. 4C, state machine 402 includes a first branch 4022 and a second branch 4024, where first branch 4022 and second branch 4024 have the same parent node. Assuming that the first branch is rooted at the base state 418 (e.g., the state is "0"), pruning the state machine 402 may further include: the state machine 402 is disabled from generating the second branch 4024, thereby avoiding unnecessary replication processes by the state machine 402.

In some embodiments, the state machine may be pruned by generating a constraint signal by adding a hypothetical statement "assign | = > $ stable (save)".

According to the device for verifying the design form, the storage module is used for generating the enabling signal based on the storage signal, so that the storage module can store the reference state based on the enabling signal, the comparison module can be used for comparing the current state with the reference state, and the cycle indicating signal for indicating that the cycle exists can be generated when the current state is the same as the basic state, so that the detection of the cycle is completed, and the verification of the activity attribute can be easily performed. Compared with the method for directly verifying the activity attribute, the method for detecting the circulation can improve the form verification efficiency and save the calculation power. It is to be understood that the respective modules included in the apparatus in the embodiments of the present application may be functional modules implemented by a computer.

The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of brevity.

In addition, well known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures for simplicity of illustration and discussion, and so as not to obscure the application. Furthermore, devices may be shown in block diagram form in order to avoid obscuring the application, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the application is to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the application, it should be apparent to one skilled in the art that the application can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.

While the present application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.

The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the application are intended to be included within the scope of the application.

Claims (7)

1. An apparatus for formal verification of a design, comprising:

an input module for receiving a state of a state machine corresponding to the design at runtime,

a storage module coupled to the input module for storing a reference state provided by the input module according to an enable signal,

a save module coupled to the storage module for receiving a save signal and generating the enable signal based on the save signal, an

A comparison module coupled to the input module and the storage module, respectively, for comparing the current state provided by the input module and the reference state stored by the storage module,

wherein, in response to the current state and the reference state being the same, the comparison module generates a cycle indication signal indicating that a cycle is present;

the storage module further comprises an or gate unit, a register unit, a not gate unit and a first and gate unit, wherein a first input end of the or gate unit is used for receiving the storage signal, a second input end of the or gate unit is connected with an output end of the register unit and an input end of the not gate unit, an output end of the or gate unit is connected with an input end of the register unit, an output end of the not gate unit is connected with a first input end of the first and gate unit, a second input end of the first and gate unit is used for receiving the storage signal, and an output end of the first and gate unit is used for outputting the enable signal.

2. The apparatus of claim 1, wherein the memory module comprises an enable terminal configured to receive the enable signal to cause the memory module to latch the reference state under the effect of the enable signal.

3. The apparatus of claim 1, further comprising an output module to receive an output signal of the register cell and an output signal of the comparison module and to output the cycle indication signal from the comparison module in response to the current state and the reference state being the same.

4. The apparatus of claim 3, wherein the output module comprises a second AND gate unit, a first input of the second AND gate unit being connected to the output of the register unit, a second input of the second AND gate unit being connected to the output of the comparison module.

5. The apparatus of claim 1, wherein the loop is a loop resulting from converting an active attribute assertion that verifies the design into a security attribute assertion.

6. The apparatus of claim 1, wherein the state is a state resulting from applying a constraint signal to the state machine, wherein the constraint signal is to prune a derivative state machine resulting from copying the state machine based on the save signal after the output signal of the register unit is locked.

7. The apparatus of claim 6, wherein the state machine comprises a first branch and a second branch, wherein the first branch and the second branch have a same parent node, the first branch is a root node from the reference state, and the pruning further comprises:

inhibiting the state machine from generating the second branch.

Images