The present invention generally relates to the field of hardware circuit verification by means of a software circuit model. More specifically, the present invention relates to verifying the behavior of a logic level circuit model to satisfy certain specified properties.
Recent increases in the complexity of modern integrated circuits has exacerbated the difficulty of verifying design correctness. The verification phase of a typical integrated circuit design project consumes approximately 70–80% of the total time and resources dedicated to a project. Flaws in the design that are not found during the verification phase have significant economic impact in terms of increased time-to-market and reduced profit margins.
A typical integrated circuit design flow includes many steps that proceed in a sequential manner, with each step depending on the results of the previous step. Consequently, when a flaw is discovered in a step, all the previous steps must be repeated, often at a significant cost. Hence, it is highly desirable to find and fix design flaws as early as possible in a design flow.
Traditionally, simulation-based techniques have been used to verify design correctness. Transistor-level simulation based techniques were used in the early 1970s and logic gate-level simulation based techniques were used in the late 1980s. As the complexity of designs increased with the passage of time, drawbacks associated with these techniques came into light. These techniques became less effective because of their inability to completely and quickly verify large designs. A popular alternative is the use of Register Transfer Language (RTL)-level simulation. Contemporary verification and debugging tools use various levels of abstractions for defining design specifications. These abstractions are expressed in high-level description languages. High-level description languages provide a number of functionalities for analyzing and verifying a design while performing simulation. For example, a designer can navigate the design hierarchy, view the RTL source code, and set breakpoints on a statement of an RTL source code to stop the simulation. Also, line numbers are provided in the RTL source code to identify different lines and statements. Further, the verification and debugging tools often support viewing and tracing variables and some times even signal values. These RTL-level simulation tools typically also offer these and other types of RTL debugging functionalities.
The verification tools as mentioned above typically follow a design flow. In the first step of the design flow, the conceptual nature of the integrated circuit is determined. The desired functionality of a circuit is expressed as a collection of properties or specifications, and possibly as a model of the behavior in a high-level language such as C++. The RTL model of the digital circuit is built based upon knowledge of the specifications or the high-level model. The RTL model is expressed in a hardware description language (HDL) such as Verilog available from Cadence Design Systems, Inc. of Santa Clara, Calif. or VHDL available from IEEE of New York, N.Y. Many other steps such as synthesis, timing optimization, clock tree insertion, place and route, etc., yield subsequent transformations of the design. These transformations eventually result in a set of masks that are fabricated into integrated circuits. The current invention is targeted at finding design flaws in the RTL model of the design, which is a very early phase of the design flow.
In the design flow, creation of RTL source code is followed by verification so as to check the compliance of the RTL source code to the design specifications. Three approaches commonly used to verify the design at the RTL level are simulation, emulation and formal methods.
Simulation is one of the most prevalent methods used to determine whether the design is in accordance with the specifications by simulating the behavior of the RTL model. The simulation process uses RTL source code and a “Test Bench” to verify a design. The Test Bench contains a subset of all possible inputs to the circuit/logic. For an ‘n’ input circuit, there are 2n possible inputs at any given time. For large n, e.g., for a complex design, the number of possible input sequences becomes prohibitively large. To simplify this, only a subset of all possible inputs is described in any given Test Bench. An example of such a tool is Ncverilog from Cadence Design Systems, Inc. of Santa Clara, Calif. To simulate the RTL model, a Test Bench must be created that provides appropriate input stimulus to the RTL model. Creating the Test Bench is a time consuming process. The process of simulating the Test Bench is also time consuming. Furthermore, it is effectively impossible to create enough test cases to completely verify that the specified properties of the design are true. This is because of the sheer number of possible inputs, and also because it requires in-depth knowledge and tremendous creativity on the part of the Test Bench creator to imagine the worst-case scenarios.
Emulation is similar to simulation, except that the design is mapped to special purpose hardware rather than simulating the design on a general-purpose computer. Emulation is significantly faster than simulation, but shares the same problems with Test Bench generation and creating worst-case scenarios.
An increasingly popular alternative is to use formal methods to completely verify properties of a design. Formal methods use mathematical techniques to prove that a design property is either always true, or to provide an example input sequence (referred to as a counterexample) demonstrating that the property is false. Tools using formal methods to verify properties are known as Model Checkers. An example of a conventional model checking tool is the Formal Check tool from Cadence Design Systems, Inc. of Santa Clara, Calif.
When the conventional method is applied to verify the property of a circuit model, there are three possible outcomes: (1) The system determines that the property is true for all input sequences that satisfy the set of environmental constraints. (2) The system is unable to make a determination due to lack of computing resource (time or memory). (3) The system determines that the property is false. In the latter case, the conventional system produces a counterexample that satisfies the set of environmental constraints, but for which the property fails to be true.
Two issues inhibit the widespread use of model checking. The first is performance. Resources used to perform verification are typically exponentially related to the number of registers in the circuit model. This is referred to as the “state space explosion” problem. Many conventional Model Checkers analyze the entire design before proving a particular property. The complexity and size of modern integrated circuits, combined with the state space explosion problem, make it impossible to use such Model Checkers on large designs.
Instead of analyzing the entire design, other conventional Model Checkers analyze a portion of the design relevant to a particular property. This includes all portions of the design between the signals relevant to the property and the primary inputs. An example of a conventional system that implements this property dependent design analysis is the COSPAN model checking engine referred to in R. P. Kurshan, “Formal Verification in a Commercial Setting”, Design Automation Conference, pp. 258–262, June 1997, Anaheim, Calif. However, even the property relevant portion of the design can be very large. Thus, in this case the state space explosion problem can result in severe performance problems.
No conventional system permits complete control over the region of the circuit model to be examined when verifying a particular property. The user typically resorts to manually modifying the design by removing and replacing parts of the design in order to determine if a property is true. An example of this design surgery is described in S. G. Govindaraju et al., “Counterexample-Guided Choice of Projections in Approximate Symbolic Model Checking”, IEEE International Conference on Computer-Aided Design, pp. 115–119, November 2000. This modification of the design introduces the possibility of human error and requires additional steps.
Another issue that inhibits widespread use of model checking is usability. In the conventional systems, it is impossible to express many practical environmental constraints and properties without either modifying the design, or without a detailed knowledge of the internal details of the design. The set of environmental constraints and properties of interface protocols can be encapsulated in an additional circuit model known as a monitor. An example of a monitor may be found in K. Shimizu et al., “Monitor-Based Formal Specification of PCI”, Proceedings of the 3rd International Conference of Formal Methods in Computer-Aided Design, November 2000. This additional circuit model allows users to easily express environmental constraints and related properties. But no conventional system permits the user to connect an additional circuit model such as an interface monitor to a circuit model without modifying the design.
Hence, there is a need for a system and a method that verifies a circuit model in a short duration of time. Further, there is a need for a system and a method that permits complete control over the region of the circuit model to be examined while checking for a particular property and that does not involve any modification of the design. There is also a need for a method and a system that permits the user to connect an additional circuit model representing the environmental constraints of a circuit model without modifying the design. Also, there is a need for a system and a method that verifies the design of a circuit model without modifying the design.
The present invention is directed to a system and a method for verifying properties of a circuit model.
An object of the present invention is to provide a system and a method to verify properties of a circuit model in context of a set of environmental constraints.
Another object of the present invention is to provide a system and a method that permits complete control over a region of the circuit model to be examined when verifying a specified property.
Another object of the present invention is to provide a system and a method to improve upon the existing property checking techniques to reduce computation time for verification.
Another object of the present invention is to provide a system and a method that permits the user to connect an additional circuit model to verify the properties of the circuit model.
Yet another object of the present invention is to provide a system and a method that permits the user to connect an additional circuit model to verify the properties of a circuit model without modifying the design of the circuit model.
To attain the above objectives, the first step is to choose a property to be verified in context of a circuit model under a set of environmental constraints. Thereafter, a region of the circuit model is selected to verify the property of the circuit model. The circuit model region is characterized by a property input boundary that defines the input to the selected circuit model region. Specifying the property input boundary allows the user to have complete control over the region of the circuit model being examined to prove the specified property. After the selection of the circuit model region, the property is verified. If the property is true, the process is stopped. If the property verification gives a false result, then the values of signals for which the property gives a false result are provided to the user. Based on the result provided, the user determines if the failure is due to design error. The process stops if the false result is due to the design error. Otherwise, the initially selected circuit model region is modified and the property is again verified. In this manner, the property of the circuit model is iteratively verified. Using this method, all properties of the circuit are verified considering one at a time. The selection of the initial property input boundary and the subsequent updates can be done automatically or interactively by the user. Thus, instead of analyzing the entire design, only a portion is analyzed for verification. This saves computation time for verification. Further, the present invention also allows the user to save and restore the property input boundaries in the form of data files on the computer system.
Additionally, the present invention provides a method to reduce the computation time for the verification method. The method uses the information regarding the Known Reachable and Known Unreachable states of the circuit model from the previous runs to reduce the iterations involved for verifying the properties.
The present invention also allows the user to verify a circuit model by changing the environmental constraints rather than expanding the property input boundary. This is achieved by adding new logic in the form of an additional circuit model outside the circuit model without making any modifications to the circuit model. The present invention permits the user to connect the additional circuit model to the existing circuit model in order to specify related properties and environmental constraints. This has the advantage that the user can define properties and environmental constraints entirely in terms of the primary inputs and outputs of the circuit model. The user does not need to understand the internal details of the circuit model being checked. Further, no modification in the circuit model is required to connect to the additional circuit model. Hence, the invention eliminates time consuming and error prone user modifications of the circuit model.
The preferred embodiments of the invention will hereinafter be described in conjunction with the appended drawings provided to illustrate and not to limit the invention, wherein like designations denote like elements, and in which:
The present invention provides a method and a system for verification of RTL-level circuit models using formal methods. For the purpose of clarity, the terms used for describing the present invention are defined below.
The term “formula” describes a Boolean formula consisting of signals and operators in a circuit model. Examples of operators are AND, OR, NOT and other operators related to time. An example of an operator related to time is one that refers to the previous value of a signal. Such operators are well known in the art such as that described in K. McMillan, “Symbolic Model Checking”, PhD. thesis, Carnegie Mellon University, May 1992. The formula can have either a true (1), or a false (0) value.
The term “property” defines a desirable behaviour of the circuit model in terms of a formula. The user wishes to check if a property is true or false in the context of a circuit model.
The term “environmental constraint” describes a constraint on the signals of a circuit model in terms of a formula. The term “environmental constraint” is also referred to as “assumption”. A property is verified in context of a set of environmental constraints, all the environmental constraints being true in the circuit model. The set of environmental constraints may be a null set (i.e. no environmental constraints) or may comprise one or more environmental constraints. Referring again to
The term “property input boundary” describes a collection of signals that are treated as inputs to check a property. For example in
The term “analysis region” comprises the following signals: (1) all signals referred to by a property (2) all signals in a property input boundary (3) all signals that lie on a signal path between a signal referred to by a property and a signal in the property input boundary. An analysis region corresponds to a particular property input boundary, and similarly, a property input boundary defines a corresponding analysis region. Hence, the two terms are herein used interchangeably in the description.
The term “counterexample” describes a sequence of values for inputs in a property input boundary that results in the property having a false value. The sequence of values must satisfy the set of environmental constraints.
The term “false negative” describes a case when a property is determined to be false in context of a property input boundary, but a different property input boundary exists in which the property can be shown to be true. An example of a false negative is furnished in
The term “Boolean decision diagram” (BDD) refers to graph based algorithms used for representing Boolean function manipulation. BDD is well known in the art. A description of the techniques used to create and manipulate BDDs may be found in R. E. Bryant, “Graph-Based Algorithms for Boolean Function Manipulation”, IEEE Transactions on Computers, Vol. C-35, No. 8, August 1986, pp. 677–691.
The term “design hierarchy” describes a collection of sub-designs and the manner in which they are interconnected. The design hierarchy has exactly one top-level design. The top-level design is further subdivided into sub-designs. A sub-design can be encapsulated into a single unit and repeatedly instantiated inside other designs.
The term “wide signal” describes a collection of single bit signals that are referred to collectively by a single name. For example, single bit signals X[0], X[1] and X[2] comprise a 3 bit wide signal named X.
The term “array signal” describes a selected bit of a wide signal. For example, signals X[0], X[1] and X[2] are all array signals corresponding to wide signal X.
The term “memory signal” describes a selected bit of a wide signal, where the selection is not a constant, but a variable. For example, X[Y] where ‘Y’ is a variable, refers to a memory signal.
The term “select operator” describes an operator whose output is a contiguous selection of bits from a list of input signals. For example, signal “indicator[counter]” describes the output of a select operator that selects single bit (as specified by “counter”) of the signal “indicator”. (This example is also referred to as a “bit select” since it selects a single bit of the input.) By way of another example, “indicator[15:8]” describes the output of a select operator that selects 8 bits (bit 8 through bit 15 inclusive) of the input signal “indicator”. (This example is often referred to as a “part select”.)
A circuit model is typically described in terms of a data structure.
The flowchart in
The method reads circuit model data in step 702, properties to be verified in step 704 and the set of environmental constraints in step 706. A synthesized netlist of the circuit model is then generated in step 708. A netlist is a list of components such as gates, flip-flops etc. A netlist describes the properties of the components and the connections between them. A check is made in step 710 to confirm whether all the properties have been verified. If all the properties have not been verified, the next property is verified in context of a set of environmental constraints in step 712. After verification, the result is provided to the user in step 714. After verification of all the properties, the method terminates.
The abovementioned conventional method only permits the property input boundary to be the primary inputs of the circuit model. Step 712 uses a method well known in the state-of-the-art to check if a property is true or false. For purposes of clarity, and to highlight the improvements made by the current invention, this method (hereon referred as Method A) is described using a flowchart in
The first step of Method A involves building a BDD in step 802 for each register in the specified circuit model. The BDD represents the next-state function of a register. These BDDs are functions of the primary inputs of the circuit model as well as the state variables of the circuit model. Here, each state variable represents the output of a register. Next step 804 involves building a BDD for the combinational condition that represents a violation of the specified property for the circuit model. Step 804 is followed by step 806 that involves building a BDD for initial state set. Initial state set is defined as the set of states that the circuit model can attain after the circuit model has been initialized or reset. Further, a current reachable set is defined in step 808. The current reachable set is defined as the set of states that the circuit model can attain at the time of observation. The current reachable set is initialized to the initial state set. This is followed by a check in step 810 to verify whether the current reachable set intersects the BDD built in step 804. If the check results in a true condition then it implies that the specified property is not verified for the specified circuit model. Hence, a counterexample is generated according to step 812 and it is reported that the property is false in step 814. The method then terminates. If the check in step 810 results in a false condition, it implies that the property has been verified. In this scenario, next reachable set is computed in step 816 using the BDD for next-state functions built in step 802. A check in step 818 is then performed to verify if the next reachable set equals the current reachable set. If the check results in true condition then the method moves to step 822. In step 822, the result is reported and the method terminates. If the false condition is generated in step 818, then in step 820 the current reachable set is set to the newly computed next reachable set of step 816. The control is then returned back to step 810. The process is thereafter repeated for the updated current reachable set.
The preferred embodiment describes a method that improves upon the conventional methods (as shown in
The preferred embodiment allows the user to run multiple different checks for each property using different analysis regions. The successive runs may have different analysis regions or set of environmental constraints. The analysis regions are typically a small fraction of the size of the entire design. Hence, the analysis region can be analyzed in significantly less time as compared to the entire design. This feature improves the run-time from days of computer time to seconds using present invention. Henceforth, all the steps of the flowchart described in
The preferred embodiment allows the user to specify an arbitrary property input boundary for a property. This is explained with reference to
For large circuit models, appropriate choice of an analysis region significantly reduces the parts of the circuit model that need to be examined to check a given property. This leads to a significant speedup in the amount of time taken to verify a property. Further, if a property check results in false, the analysis region can be iteratively modified to check the property with the modified analysis region. The user performs the modification either automatically or in an interactive manner. The method of automatic computation of initial analysis region is described hereinafter.
The method of determining an initial analysis region requires the concept of “State Machine” signals and “constant-driven” signals. The method to identify the set of constant-driven signals is described subsequently.
Constant-driven signals are defined by the following rules:
Based on the abovementioned rules, a constant-driven signal is computed according to the method described using flowchart shown in
The concept of a constant-driven signal is further highlighted using the following example, henceforth referred to as Example 1:
Example 1 is a Verilog program for a circuit model.
Constant-driven signals are used to identify State Machine signals. A State Machine is a set of registers from the design. A set of registers from the design are classified as a State Machine by one of the following three rules:
In Example 1, signal st 1116 is a State Machine signal. Further, st21146 is not identified as a State Machine signal according to the first two rules because it is not a constant-driven signal. Thus, according to rule 3, if the user does not specify st21146 as a State Machine signal, it does not become a State Machine signal.
The concept of constant-driven signals and State Machine signals are used to determine an initial analysis region. The initial analysis region is determined using the method shown in
After updating the candidate set and the current analysis region, the candidate set is again checked in step 1204. Thus, the initial analysis region is iteratively identified.
The method of generating the initial analysis region is further described using the following example, henceforth referred to as Example 2:
Example 2 is a Verilog program describing a circuit model. Suppose the property to be verified is “(inst1.light_st==′YELLOW)=>(inst1.phase==2′b00)”, and there are no environmental constraints. According to the method to determine the initial analysis region, the initial analysis region is the emphasized portion in Example 2.
To illustrate the method, consider an iteration of the method as follows. State Machine signals in Example 2 are inst1.st and inst2.phase. The current analysis region comprises signals inst1.light_st and inst1.phase. The candidate set also comprises signals inst1.light_st and inst1.phase. According to steps 1204–1208, signal inst1.light st is extracted from the candidate set. Step 1210 results in the addition of signal inst1.st to the candidate set as well as to the current analysis region. This implies that the current analysis region is now updated and comprises signals inst1.st, inst1.light_st and inst1.phase. Candidate set is also updated and comprises signals inst1.st and inst1.phase. Steps 1204–1210 are repeated by extracting another signal from the candidate set and updating the candidate set and the analysis region. The process is stopped when all the signals in the candidate set are exhausted.
The process results in the selection of initial analysis region represented by the portion of the Verilog program that is emphasized in Example 2. For instance, signal inst1.dismiss is not emphasized i.e. signal inst1.dismiss is not included in the initial analysis region because it is driven by the select of an array (signal inst1.indicator). Signal inst1.phase is not included in the initial analysis region because it is driven from a higher level of hierarchy.
Appropriate choice of initial analysis region reduces the run-time for checking a property. Another way of optimizing run-time of the property checking method is by using information computed in previous runs. This method involves use of a set of Known Reachable and Known Unreachable states computed in previous run.
To optimize the run-time, the set of initial states is initialized to a set of states that is known to be reachable, instead of using the initial set as described in step 808 (
As mentioned above, a set of Known Unreachable states in the previous run can also be used to optimize the run-time of the property checking method. The set of states in the design found to be unreachable during a property check are referred to as the set of Known Unreachable states.
The following are some of the conditions under which a set of Known Unreachable states from a previous run can be used to determine unreachable states for the current run:
The abovementioned third condition is further highlighted using
The set of Known Unreachable states for analysis region 1302 is ‘10’. Hence, the set of Known Unreachable states for analysis region 1316 that comprises the projection of the set of Known Unreachable states from the previous analysis region 1300, are ‘010’ and ‘110’ (register p can have values ‘0’ or ‘1’). It can be determined that these two states are unreachable even before reachability test is performed on analysis region 1316. State transition diagram 1318 verifies that the states ‘010’ and ‘110’ are unreachable for analysis region 1316.
The set of Known Unreachable states thus determined may be used in the following ways to speedup the step of computation of the next reachable state:
If none of the three conditions under which a set of states is unreachable during the current run are true, following approach is followed for efficient computation. If the set of unreachable states in the previous runs is known, these sets are used as guesses for the combinational replacement of next-state functions. This is because between runs that are close to each other, there is no substantial change in the design analysis region, and the set of environmental constraints. Hence, the replacement functions derived from the set of Known Unreachable states of the previous runs turn out to be the correct guesses.
Van Eijk et al. describe in their publication the idea of using guesses for combinational replacement functions during the step of computation of next reachable set (step 820 of Method A). In the conventional method as described using
Since the effectiveness of using Van Eijk's method relies on how often the guesses turn out to be true, using guesses based on Known Unreachable states from the previous runs allows present invention to have better performance than the conventional method described using
If the specified property is false in context of the current analysis region, then a modified analysis region is generated in the method in accordance with the present invention. The present invention allows for interactive expansion of the analysis region to generate the modified analysis region. For example, consider a circuit model in Verilog language referred henceforth as Example 3:
Suppose the property to be verified is (out==1′b1) and that the initial analysis region includes the signals out, qp and qn but not the signal in or its complement ˜in. Since, the signals driving the register signals qp and qn are not included in the analysis region, they are treated as inputs. This results in the property to be false, and a counterexample is generated. In Example 3, the counterexample is either (qp=1′b0 and qn=1′b0) or (qp=1′b1 and qn=1′b1).
The user may expand the analysis region by explicitly selecting registers qp and qn, and adding the combinational fan-in of these (in and ˜in respectively) to the analysis region. The property (out==1′b1) is then true in context of the modified analysis region.
Alternatively, instead of expanding the analysis region by explicitly selecting registers, the user may expand the analysis region by specifying a second property, and adding all signals and their combinational fan-in to the analysis region. In Example 3, the user can specify a second property (out==qn^qp). This expands the analysis region to include signals in and ˜in. The property (out==1′b1) is then true in context of the modified analysis region.
Another method of specifying a second property is to select signals (and the corresponding times) of the counterexample and requiring that at least one of the signals differs from the corresponding value in the counterexample. For example, suppose the counterexample selected when proving the original property (out==1′b1) is (qp=1′b0, qn=1′b0). The user could select signals qp and qn and require that at least one of the signals differs from the corresponding value in the counterexample. This is equivalent to specifying a second property ((qp!=1′b0)∥(qn!=1′b0)). As in the previous example, the property (out==1′b1) would then be true in the context of the modified analysis region.
The preferred embodiment allows for expansion of the analysis region to verify the property of the circuit model if the specified property is false in context of the current analysis region. This expansion is internal to the circuit model. An alternative way to verify the property of the circuit model is to add environmental constraints to the circuit model. This includes addition of a new logic corresponding to the environmental constraints in the form of an additional circuit model outside the circuit model into the analysis region. The addition of the new logic is performed without making any modifications to the description of the circuit model. The present invention permits the user to connect the additional circuit model to the existing circuit model in order to specify related properties and the set of environmental constraints. The present invention has the advantage that the user can define properties and environmental constraints entirely in terms of the primary inputs and outputs of the circuit model. The user does not need to understand the internal details of the circuit model being checked.
The method of connecting additional circuit model to the circuit model is further described using a flowchart shown in
The method by which the present invention permits the user to connect additional circuitry is described using the following example.
The communication protocol is illustrated by means of a timing diagram in
The formulas in
To check if BLOCK_11502 correctly implements the communication protocol, additional circuit model is connected to BLOCK_11502.
The connection between BLOCK_11502 and additional circuit model 1910 is represented as a data structure.
To check that BLOCK_11502 correctly implements the logic that drives signal REQ 1504, signal ACK_VALID 1804 is specified as an environmental constraint, and signal REQ_VALID 1802 is specified as a property to be checked.
Similarly, to check that BLOCK_21508 correctly implements the logic that drives signal ACK 1506, signal REQ_VALID 1802 is specified as an environmental constraint, and signal ACK_VALID 1804 is specified as a property to be checked.
For checking whether the combined circuit model correctly implements the logic that drives signals REQ 1504 and ACK 1506, both ACK_VALID 1804 and REQ_VALID 1802 signals are specified as properties.
In the preferred embodiment, the system of the present invention is executed on a general-purpose computer, for example, of the type commercially available from Sun Microsystems, Inc., of Mountain View, Calif. Various methods (as shown in
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.
This application claims priority to U.S. Provisional application Ser. No. 60/377,392 filed on May 3, 2002.
Number | Name | Date | Kind |
---|---|---|---|
6102959 | Hardin et al. | Aug 2000 | A |
6185516 | Hardin et al. | Feb 2001 | B1 |
6594804 | Hojati | Jul 2003 | B1 |
6725431 | Yang | Apr 2004 | B1 |
20040123254 | Geist et al. | Jun 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20030208730 A1 | Nov 2003 | US |
Number | Date | Country | |
---|---|---|---|
60377392 | May 2002 | US |