Power State Transition Verification For Electronic Design

Abstract

Various implementations of the invention may be applied to generate an auxiliary verification statement. The auxiliary verification statement defines properties that may be employed to check if the power domains are active at appropriate times. Particularly, the auxiliary verification statement checks to ensure that power domain transitions do not interfere with the operation of the device design. With various implementations of the invention, an auxiliary verification statement may be generated by first determining a set of properties instantiated in a verification statement and then synthesizing the auxiliary verification statement based upon the determined properties, the corresponding device design and the power domains. In some implementations, the auxiliary verification statement instantiates properties that check if the power domains related to the properties in the verification statement are active when the verifications statement is exercised. In various implementations, this is accomplished by substituting select ones of the properties in the verification statement with select properties corresponding to the power domain.

Description

RELATED PATENT APPLICATIONS

The present application claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 61/086,117, entitled “Formal Property Verification Of Low Power Designs,” filed on Aug. 4, 2008 and naming Paparao Kavalipati and Andrew Seawright as inventors and U.S. Provisional Patent Application No. 61/230,750, entitled “Formal Property Verification Of Low Power Designs,” filed on Aug. 3, 2009 and naming Paparao Kavalipati and Andrew Seawright as inventors, which applications are incorporated entirely herein by reference.

FIELD OF THE INVENTION

The invention relates to the field of electronic design verification. More particularly, various implementations of the invention are applicable to verifying transitions between power states in an electronic design.

BACKGROUND OF THE INVENTION

Electronic circuits, such as integrated microcircuits, are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating microcircuit devices typically involves many steps, sometimes referred to as the “design flow.” The particular steps of a design flow often are dependent upon the type of microcircuit, its complexity, the design team, and the microcircuit fabricator or foundry that will manufacture the microcircuit. Typically, software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators. These steps aid in the discovery of errors in the design, and allow the designers and engineers to correct or otherwise improve the design. These various microcircuits are often referred to as integrated circuits (IC's).

Several steps are common to most design flows. Initially, the specification for a new circuit is transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the circuit. With this logical design, the circuit is described in terms of both the exchange of signals between hardware registers and the logical operations that are performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as the Very high speed integrated circuit Hardware Design Language (VHDL). The logic of the circuit is then analyzed, to confirm that it will accurately perform the functions desired for the circuit, i.e. that the logical design conforms to the specification. This analysis is sometimes referred to as “formal verification.”

After the logical design is verified, it is converted into a device design by synthesis software. The device design, which is typically in the form of a schematic or netlist, describes the specific electronic devices (such as transistors, resistors, and capacitors) that will be used in the circuit, along with their interconnections. This device design generally corresponds to the level of representation displayed in conventional circuit diagrams. The relationships between the electronic devices are then analyzed, often mathematically, to confirm that the circuit described by the device design conforms to the logical design, and as a result, the specification. This analysis is also sometimes referred to as formal verification. Additional verifications, such as for example timing and power verifications are often made at this stage, and may be included in the formal verification process.

Once the components and their interconnections are established, the design is again transformed, this time into a physical design that describes specific geometric elements. The geometric elements, which typically are polygons, define the shapes that will be created in various layers of material to manufacture the circuit. This type of design often is referred to as a “layout” design. The layout design is then used as a template to manufacture the integrated circuit. More particularly, the integrated circuit devices are manufactured, by for example an optical lithographic process, using the layout design as a template. During an optical lithography process, a photo-mask is used to transfer a geometric pattern from the photo-mask onto a substrate via a photo-resistive material. The geometric pattern in the photo-mask is designed such that the image or pattern transferred onto the substrate matches the geometric pattern of the layout design.

As indicated above, formal verification is used to ensure the device design complies with the device specification. The specification often defines properties and directives that collectively describe the expected behavior of the device. The specification of properties and directives is often done semantically. Various languages exist for defining properties and directives, such as for example Sugar, ForSpec, Property Specification Language (PSL), and System Verilog Assertions (SVA), among others. As stated above, the device design is often in the form of a hardware description language. Formal verification then either proves or disproves the properties and directives with respect to the design and the specification.

As modern device designs and specification are extremely complicated, computing devices, executing a formal verification toolset are often employed. These formal verification tools typically report out to the user which properties are proven true, and what properties can fail as well as what sequences of states in the design can cause the properties to fail.

As those of skill in the art can appreciate, different power supplies are often used for powering different parts of the a design. For example, a cell phone may include a camera in addition to the other components needed to transmit and receive voice communications. During times that the camera is not in use it may be desirable to turn off power to the image capture potions of the device, so as not to prematurely drain the battery or use excessive power. As a result, the device would need multiple power supplies or power switches capable of delivering power to one portion of the device while shutting of power delivery to another portion of the device. Often when a portion of a device is supplied power by a particular power supply, it is said that the portion of the device is “driven” by that particular power supply.

Portions of a device being “driven” by different power supplies are said to be in different power domains. Accordingly, the image capture portions of the design above would be in a different power domain than other portions of the design. Power domains, as well as other low power design techniques are further described in Low Power Methodology Manual For System-On-Chip Design, by M. Keating et al., Springer 2007, which book is incorporated entirely herein by reference.

Various standards exist for the specification of low power design features. For example, the Unified Power Format (UPF) and the Common Power Format (CPF) are two such standards. Designs with multiple power supplies, and low power designs in particular have a functional specification and a power specification. The functional specification defines the behavior of the device while the power specification defines the power domains and power controller information. For low power designs, the basic functionality of the design as well as the low power features must be verified. The verification considers how the power supply network is created, how power supply nets behave as well as ensures that various scenarios of powering up and powering down different power domains do not interfere with the intended functionality of the design.

Various approaches to verifying low power designs are discussed in Assertion-Based Verification For Power Cycled Systems-On-Chip, by T. Anderson et al., Design and Verification Conference and Exhibition Proceedings, San Jose, Calif., Feb. 19-21, 2008, To Retain Or Not To Retain: How Do I Verify The State Elements Of My Low Power Design?, by S. Bailey et al., Design and Verification Conference and Exhibition Proceedings, San Jose, Calif., Feb. 19-21, 2008, Upping Verification Productivity Of Low Power Designs, by G. Chidolue et al., Design and Verification Conference and Exhibition Proceedings, San Jose, Calif., Feb. 19-21, 2008, Power Assertions And Coverage For Improving Quality Of Low Power Verification Closure Of Power Intent, by N. Khan et al., Design and Verification Conference and Exhibition Proceedings, San Jose, Calif., Feb. 19-21, 2008, and Static And Formal Verification Of Power Aware Designs At The RTL Using UPF, by R. Mukherjee et al., Design and Verification Conference and Exhibition Proceedings, San Jose, Calif., Feb. 19-21, 2008, which articles are all incorporated entirely herein by reference.

Some approaches to verifying low power designs mentioned above require modification to the functional specification. For example, the properties defined by the functional specification may be altered to explicitly state the power state information. However, this approach clutters the functional specification and particularly the properties of the functional specification. Additionally, this approach requires further time and energy from the designer to modify the functional specification according to the power specification. Other approaches described above require that the power state information is manually proven, such as for example at the gate level.

SUMMARY OF THE INVENTION

Implementations of the invention provide methods and apparatuses for verifying power state transitions within a device design. In various implementations of the invention, a device design having multiple power domains is identified. Additionally, a verification statement corresponding to the device design is identified. Subsequently, an auxiliary verification statement defining properties to check if the power domains are active at appropriate times is generated. The auxiliary verification statement may be used in conjunction with the verification statement to verify correct operation of the device design. Particularly, the auxiliary verification statement may be used to ensure that the power domain transitions do not interfere with the operation of the device design.

With various implementations of the invention, an auxiliary verification statement may be generated by first determining a set of properties instantiated in a verification statement and then synthesizing the auxiliary verification statement based upon the determined properties, the corresponding device design and the power domains. In some implementations, the auxiliary verification statement instantiates properties that check if the power domains related to the properties in the verification statement are active when the verification statement is exercised. In various implementations, this is accomplished by substituting select ones of the properties in the verification statement with select properties corresponding to the power domain.

These and additional implementations of the invention will be further understood from the following detailed disclosure of illustrative embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of illustrative embodiments shown in the accompanying drawings in which like references denote similar elements, and in which:

FIG. 1 shows an illustrative formal verification tool;

FIG. 2 a device design;

FIG. 3 illustrates a clock signal;

FIG. 4 shows an illustrative computing device

FIG. 5 illustrates a method of generating an auxiliary verification property;

FIG. 6 illustrates the method of FIG. 5 in greater detail;

FIG. 7 illustrates the method of FIG. 6 in greater detail;

FIG. 8 illustrates an electronic system;

FIG. 9 illustrates a description of a portion of the electronic system of FIG. 8;

FIG. 10 illustrates a description of the power domains of the electronic system of FIG. 8;

FIG. 11A illustrates logic states for the electronic system of FIG. 8; and

FIG. 11B illustrates logic states for the electronic system of FIG. 8.

DETAILED DESCRIPTION OF ILLUSTRATIVE IMPLEMENTATIONS

Although the operations of the disclosed techniques are described in a particular sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangements, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the disclosed flow charts and block diagrams typically do not show the various ways in which particular techniques can be used in conjunction with other techniques. Additionally, the detailed description sometimes uses terms like “determine” to describe the disclosed techniques. Such terms are high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms will vary depending on the particular implementation and are readily discernible by one of ordinary skill in the art.

Some of the techniques described herein can be implemented by software stored on a computer readable storage medium and executed on a computer. Additionally, some of the disclosed techniques may be implemented as part of a computer implemented electronic design automation (EDA) tool. The selected techniques could be executed on a single computer or a computer networked with another computer or computers. For clarity, only those aspects of the tools or computer germane to these disclosed techniques are described; product details well known in the art are omitted.

Formal Verification

As the described techniques apply to formally verifying a low power device design, a general formal verification tool and process are described here. FIG. 1 illustrates a formal verification tool 101. The formal verification tool 101 may be employed to prove or disprove that the device design 103 conforms to the specification 105. As can be seen from this figure, the specification 105 includes a set of properties 107 and a set of directives 109. The set of properties 107 is a collection of logical and temporal relationships that combined represent a set of behavior, rules, or characteristics about the design 103. The set of directives 109 specify the specific actions to be taken to “check” the set of properties. For example, a common directive is the assert directive. The assert directive states that a given property is required to hold in a given set of states, and directs the formal verification tool 101 to verify that the property does hold the given states. Various other directives, such as for example the cover directive or the assume directive, are available for checking selected properties. Those of skill in the art are familiar with properties and directives and the various languages available for declaring properties and directives. Accordingly, these are not reviewed here.

As further illustrated in FIG. 1, the formal verification tool 101 includes a design processing unit 111, a specification processing unit 113, a formal verification engine 115, and an output generation unit 117. The design processing unit 111 may access the design 103 and generate a finite state machine 119. In some implementations, other mathematical descriptions of the design, such as for example non-deterministic automata may be generated. The specification processing unit 113 may access the specification 105 and relate the set of properties 107 to selected portions of the finite state machine 119. The formal verification engine 115 takes the processed properties and directives and determines, often mathematically, if a directive is satisfied or not. More particularly, the formal verification engine 115 either proves or disproves ones of the set of directives 109 for the corresponding properties of the set of properties 107, based on the finite state machine 119. The output generation unit 117 generates a report 121 that may be made available to the user, by for example storing it to a memory storage location or outputting to a visual display device. In various implementations, the report 121 lists the specific directives and which were proven true and which were proven false. In further implementations, for the directives proven false, a listing of the states that caused the directive to fail may be included in the report 121. In still various implementations, the directives that could not be proven or disproven may be included in the report 121.

As FIG. 1 illustrates, formal verification is typically applied to device designs. However, formal verification may be applied to already manufactured devices, such as for example a prototype device. The techniques described herein for verifying the power state transition of a device design are equally applicable to verification of a physical design. However, for purposes of brevity and clarity, a distinction between verification at the design level and at the physical level is not made in the balance of this disclosure. Furthermore, the term device may be used interchangeably to refer to a physical embodiment of the device as well as to models or representations of the device.

Low Power Designs

As discussed, many modern electronic designs may be classified as “low power” designs. More particularly, many device designs may provide for different portions of the design to be supplied power at different times as well as to be supplied power at different levels. As used herein, the term “low power” refers to designs having the above described functionality. FIG. 2 illustrates a low power design 201. As can be seen form this figure, the low power design 201 includes a hardware component 203 and a power component 205. The hardware component 203 further includes a power controller component 207. As described above, device designs, such as the design 201, are often specified in a hardware description language.

As those of skill in the art can appreciate, the components within electronic designs are often “triggered” or controlled by a clock. A modern device will typically include multiple clocks to control the different components within the design, such as for example the power controller components. FIG. 3 illustrates a clock 301. As can be seen from this figure, the clock 301 has 6 cycles (i.e. t=0 to t=6), with each cycle having a first clock edge 303 and a second clock edge 305. The first clock edges 303 are often referred to as the rising edge while the second clock edges 305 are often referred to as the falling edges. Clocks are used to both trigger elements within the device design as well as to synchronize the operation of various components within the design. A clock is said to be active if there exists elements within the design that are triggered on either of that clocks edges. Some clocks are active on both their rising and falling edges. Additionally, some elements may be triggered on both the rising and falling edges of a clock. For each clock edge within the design, a group of elements triggered on that particular clock edge may be identified. This group of elements may be referred to as belonging to the same “clock domain”. Accordingly, a device design will typically have a plurality of clock domains.

As stated above, different parts of a design may be driven by different power sources. Additionally, different parts of a design may operate at different voltage levels. Furthermore, portions of a design may operate at different voltage levels at different times during the operation of the device. Accordingly, these portions of the design will be switched between different voltage levels. Often this switching takes place dynamically as described by the power component 207 of the device design 201. The act of switching the voltage levels is often referred to as “power switching,” “voltage switching,” or simply “switching.” The set of all clock domains that are always switched together is referred to herein as a “voltage domain”.

As further stated above, different parts of the design are powered on and off dynamically. Each sub-portion of these different parts of the design may operate at different voltage levels. The set of all voltage domains that are always powered on and off together is referred to herein as a “power domain”. Returning to FIG. 2, as stated above, the power controller component 207 describes logic that controls the switching of power and voltages to the different parts of the design. The power component 205 specifies intended behavior of the different power and voltage domains.

Formal Verification Directives And Properties

Returning to FIG. 1, as detailed above, the set of directives 109 are checks of various ones of the properties 107 that relate to the device design 103. Particularly, the directives relate to various elements within the hardware component 203 of the device design. In various implementations of the invention, ones of the directives 109 will be “clocking directives.” As used herein, clocking directives are directives that apply to properties of a clock domain or clock domains. In various implementations, the clocking directive specifies a peak number of register transitions for a given clock domain. Subsequently, an estimate of a lower bound of the peak dynamic power needed for that domain may be estimated, by for example determining the number of register transitions within the given clock domain.

As detailed above, device functionality depends upon whether the clocks continue to “tick.” Accordingly, scenarios where low power optimization and clock gating conditions make a clock stop ticking are of particular interest. In various implementations, ones of the set of directives 109 specify that a clock for a particular domain ticks faster than another domain. With various implementations, ones of the set of directives 109 specify that if a clock in a particular domain is ticking then another clock in an alternate domain must tick.

In various implementations, ones of the set of directives 109 will be “voltage directives.” As used herein, voltage directives are directives that apply to properties of a voltage domain or voltage domains. In some implementations, electronic signals defined by the design 103 that transition the voltage domains, go through level shifters. If the level shifter is such that its lower voltage end is fixed, then it is often desirable that the domain connected to that end of the level shifter be at a lower voltage that the signal as the system dynamically switches through voltage transitions targeted for lower power. Accordingly, a voltage directive may be defined to verify such operation. With some implementations, ones of the set of directives are “power directives” and apply to properties of the power domains. Various power directives may verify that the power domains turn on and off in correct sequence.

Those of skill in the art can appreciate that in formal verification, properties and directives are used in conjunction with each other to verify a design. More particularly, directives, which are sometimes referred to as verification statements, are instructions that specify what to do with the properties. For example, a simple verification statement is assert property (a ##1 b). As can be seen, this statement is an assert directive, which instructs the verification tool to verify that the property statement (i.e. a ##1 b) holds. In this case the tool is instructed to verify that every occurrence of a is followed by b. As used herein, the term verification statement refers to a property definition and a corresponding verification directive. Additionally, as those of skill in the art can appreciate, a specification for use in formal verification includes both property definitions and corresponding directives.

As stated above, various languages exist for defining the properties and directives that make up the specification. One such language is the system verilog assertion language. Most languages used to define properties and directives can be translated into a temporal logic form, such as for example linear temporal logic. Linear temporal logic is a modal form of temporal logic, where the modalities refer to time. Linear temporal logic is built from a set of propositional variables, logical connections, and modal operators. For example, X pv1 states that the variable pv1 has to hold in the next state. Additionally, pv1 U pv2 states that the variable pv1 has to hold at least until pv2. Furthermore, various operators may be classified as “weak” or “strong”. As used herein a strong operator requires that the terminating condition (i.e. the occurrence of pv2 in the above example) occur. Often, a strong operation may be indicated by the symbol “!”, for example pv1 U! pv2. An example of a weak operator is pv1 W pv2, which is the equivalent of (pv1 U pv2) V G pv1, which means that either pv1 has to hold at least until pv2 or pv1 holds indefinitely.

In addition to the weak and strong operators. Linear temporal logic properties of “liveness” and “safety” are often used. The safety property specifies that “nothing bad happens,” while the liveness property specifies that “something good will happen.” In general these two properties are actually aspects of the properties and directives of the specification. Accordingly, as those of skill in the art can appreciate, there are various “classes” of properties, such as for example the liveness class of properties. The details of performing formal verification by using the liveness and safety classes of properties are familiar to those of skill in the art and as such will not be further covered in detail here.

Illustrative Computing Environment

As the techniques of the present invention may be implemented using software instructions, the components and operation of a generic programmable computer system on which various implementations of the invention may be employed is described. Accordingly, FIG. 4 shows an illustrative example of a computing device 401. As seen in this figure, the computing device 401 includes a computing unit 403 with a processing unit 405 and a system memory 407. The processing unit 405 may be any type of programmable electronic device for executing software instructions, but will conventionally be a microprocessor. The system memory 407 may include both a read-only memory (ROM) 409 and a random access memory (RAM) 411. As will be appreciated by those of ordinary skill in the art, both the read-only memory (ROM) 409 and the random access memory (RAM) 411 may store software instructions for execution by the processing unit 405.

The processing unit 405 and the system memory 407 are connected, either directly or indirectly, through a bus 413 or alternate communication structure, to one or more peripheral devices. For example, the processing unit 405 or the system memory 407 may be directly or indirectly connected to one or more additional memory storage devices, such as a “hard” magnetic disk drive 415, a removable magnetic disk drive 417, an optical disk drive 419, or a flash memory card 421. The processing unit 405 and the system memory 407 also may be directly or indirectly connected to one or more input devices 423 and one or more output devices 425. The input devices 423 may include, for example, a keyboard, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera, and a microphone. The output devices 425 may include, for example, a monitor display, a printer and speakers. With various examples of the computer 401, one or more of the peripheral devices 415-425 may be internally housed with the computing unit 403. Alternately, one or more of the peripheral devices 415-425 may be external to the housing for the computing unit 403 and connected to the bus 413 through, for example, a Universal Serial Bus (USB) connection.

With some implementations, the computing unit 403 may be directly or indirectly connected to one or more network interfaces 427 for communicating with other devices making up a network. The network interface 427 translates data and control signals from the computing unit 403 into network messages according to one or more communication protocols, such as the transmission control protocol (TCP) and the Internet protocol (IP). Also, the interface 427 may employ any suitable connection agent (or combination of agents) for connecting to a network, including, for example, a wireless transceiver, a modem, or an Ethernet connection. Such network interfaces and protocols are well known in the art, and thus will not be discussed here in more detail.

It should be appreciated that the computer 401 is illustrated as an example only, and it not intended to be limiting. Various embodiments of the invention may be implemented using one or more computing devices that include the components of the computer 401 illustrated in FIG. 4, which include only a subset of the components illustrated in FIG. 4, or which include an alternate combination of components, including components that are not shown in FIG. 4. For example, various embodiments of the invention may be implemented using a multi-processor computer, a plurality of single and/or multiprocessor computers arranged into a network, or some combination of both.

Auxiliary Verification Statement Generation

As stated above, various implementations of the invention may be employed to generate auxiliary verification statements. More particularly, auxiliary properties, which define intended power state transitions for the device design, may be generated. These auxiliary properties may then be used in conjunction with the specification and corresponding directives to formally verify that the device design does not have any unintended errors due to improper power state transitions. Generation of auxiliary verification statements will be further described by reference to FIG. 5, FIG. 6, and FIG. 7.

FIG. 5 illustrates a method 501 that may be implemented according to various embodiments of the present invention to generate a set of auxiliary verification statements 503. As can be seen from this figure, the method 501 includes an operation 505 for accessing a low power device design 507 and a verification specification 509. The method 501 further includes an operation 511 for identifying any power domains within the low power device design 507, an operation 513 for identifying any properties instantiated in the specification 509, and an operation 515 for synthesizing the set of auxiliary verification statements 503 from the identified power domains and instantiated properties.

In various implementations of the invention, the operation 511 identifies the power domains based upon the power component portion (i.e. see FIG. 2) of the device design. In alternative implementations, the power domains are identified by synthesizing the device design and corresponding power controller component (i.e. see FIG. 2) and deriving the set of power domains from the synthesis.

FIG. 6 illustrates a method 601 for synthesizing an auxiliary verification statement.

In various implementations, the operation 515 synthesizes the auxiliary verification statements according to the method 601. As can be seen from FIG. 6, the method 601 includes an operation 603 for translating a property P. In various implementations, P is a one of the instantiated properties identified by the operation 513. With some implementations, P is translated into the linear temporal logic form. With further implementations, P is translated into linear temporal logic form having a single until operator. With still further implementations, the single until operator is positive. In still further implementations of the invention, P is translated into the linear temporal logic form having a single next operator.

The method 601 additionally includes an operation 605 for identifying a variable pv2 from the translated property P. As stated above, in some implementations, the translated property is of the form pv1 U! pv2, while in other implementations, the translated property is of the form X! pv2. The method 601 further includes an operation 607 for identifying the “fan-in-cone of logic” for pv2, and an operation 609 for identifying a set of power domains D that “drive” pv2. Subsequently, an operation 611 for forming an auxiliary verification statement based upon the identified set of power domains D.

In various implementations, the operation 607 identifies the elements of the device design 507 that are logically connected to the variable pv2. For example, if the variable pv2 were a state of a particular signal line within the device design 507, then the operation 607 may identify those elements logically connected to that signal line. Alternatively, the operation 607 may identify those elements within the device design 507 that may logically affect pv2. With other implementations of the invention, the operation 607 identifies the elements of the device design 507 that are immediately connected to the signal line. With some implementations, the operation 609 identifies D as the entire chain of power domains that drive the elements identified by the operation 607. Still, in some implementations, the operation 609 identifies D as those power domains that immediately drive the elements corresponding to the variable pv2.

With various implementations, the operation 611 forms an auxiliary verification statement according to the method 701 of FIG. 7. In some implementations, an auxiliary verification property Pd will be generated for each power domain d within the set of power domains D. Accordingly, the method 701 may be repeated for each power domain d. As can be seen from this figure, the method 701 includes an operation 703 for identifying a condition c that indicates d is in the “active” power state. In various implementations, the operation 703 identifies the condition c from the power controller portion of the device design 507. For example by synthesizing the hardware description language such that the condition c may be derived. The method 701 further includes an operation 705 for constructing the property Pd. In various implementations of the invention, Pd is formed by letting Pd equal c W pv2. With other implementations, Pd is formed by letting Pd equal X c. Subsequently, an operation 707 for constructing an auxiliary verification statement is performed. In various implementations, the operation 707 constructs the verification directive by associating the property Pd with the same verification directives as the property P.

Illustrative Application

FIG. 8 illustrates an example system 801. As can be seen from this figure, the system 801 includes a first module 803 and a second module 805. The first module 803 is a staged pipeline for processing incoming data. For certain data, the first module needs the second module 805 to compute a blocking computation, which causes the first module 803 to stall. As can be seen from this figure, the first module 803 includes first in first out (FIFO) buffers 803a. The buffers 805 provide a mechanism for the first module 803 to preserve data, such that data is not lost during the stall and enables a return to full performance after the stall.

As can be further seen from this figure, the first module 803 has an output 807, named a_rdy, which indicates when the first module 803 is ready to accept data. Valid data may then be sent to the first module 803 on an input 809, named a_data_in, while keeping another input 811, named a_valid_in high. As stated, some of the data needs to be processed by the second module 805. Data may be sent from the first module 803 to the second module 805 on a line 813, named a_b_data. In order to initiate the transfer of data, the first module 803 needs to drive a line 815, named a_b_valid, high and wait till a line 817, named b_a_rdy, is high. Once the first module 803 sends the data along the line 813, the second module 805 may perform the blocking computation and after several cycles send the computed data back on a line 819, named b_a_data. The first module 803 receives the data coming from the second module 805 as well as other data and processes it through the pipeline and provides its output on an output 821, named a_data_out. The first module 803 and the second module 805 have additional inputs and outputs whose use is either explained below or apparent from the present disclosure.

Conventional Verification

Verification of this example is first described without reference to a power controller. Accordingly, the first module 803 and the second module 805 are treated as if in the same power domain. A portion of a specification may be defined that constrains the inputs so that valid inputs do not come in when it either module is not ready or when either module is in a reset state. The following are illustrative assumptions, written in the property specification language format that satisfies the above stated constraints.

assume always
(!a_rdy−>!a_valid_in);
assume always
(a_rst −>!a_valid_in);
assume always
(a_sign−>!a_data_in[WIDTH−1]);
assume always
(a_sign−>next !rst);

Given the data stream Val_In on the intput a_data_in, it is desirable that the data stream Val_Out be seen at the output a_data_out. This behavior may be checked by the following assertion, also written in the property specification language format.

assert always (
((a_valid_in && (a_data_in == Val_In))
−>
((next a_sign) until!
(a_data_out == Val_Out))) abort a_rst);

Given the above assumptions and verification statement, conventional verification techniques may be employed to verify correct operation of the example system 801. However, if the first module 803 and the second module 805 were in different power domains, then the correct operation could not be completely verified using conventional techniques alone.

Power State Transition Verification

The example system 801 may further include a power controller 823. FIG. 9 illustrates a description 901 for the power controller 823, written in the hardware description language Verilog. FIG. 10 illustrates a portion of the power component 1001 of the example system 801, written in the unified power format. As can be seen from this figure, the power domain for the first module 803 is defined. Those of skill in the art can appreciate that the power description for the second module 805 will be similar to the portion of the power component 1001 shown in FIG. 10. Accordingly, a power component description for the second module 805 is not described here. As can be seen from FIG. 9 and FIG. 10, the first module 803 and the second module 805 are in different power domains.

As can be further seen from FIG. 9 and FIG. 10, the power controller 823 drives outputs 825 and 827, named a_pwr_on and b_pwr_on respectively. The power controller 823 monitors the outputs a_busy and b_busy, which are driven low when the respective modules not busy. When a module is not found to be busy (i.e. the output a_busy or b_busy is low) for a given number of cycles, the power controller 823 switches off power to that module. As the first module 803 and the second module 805 are now defined to be in different power domains, it is possible that they may be switched at different times during the operation of the example system 801. Accordingly, the first module 803 may be turned off when the second module 805 is performing the blocking computation, resulting in a disruption of the pipeline.

The above described methods, for example the method 501 of FIG. 5 may be employed to generate an auxiliary verification statement to formally verify the operation of the example system 801. The following auxiliary verification statements, which may be generated by the methods described above, may be employed to check the example system 801.

assert always (
((a_valid_in && (a_data_in == Val_In))
−>
(b_pwr_on until
(a_data_out == Val_Out))) abort a_rst);
assert always (
((a_valid_in && (a_data_in == Val_In))
−>
(a_pwr_on until
(a_data_out == Val_Out))) abort a_rst);

FIGS. 11A and 11B illustrates undesirable power state transitions that would not be detected by the assertions used in conventional verification, but are detected by the auxiliary verification statements generated above. FIG. 11A illustrates the condition where the second module 805 is powered down before data arrives at the first module 803, while FIG. 11B illustrates the condition where the second module 805 is powered down after data arrives at the first module 803.

CONCLUSION

Various techniques for verifying power state transitions within a device design have been described. Particularly, techniques for generating an auxiliary verification statement have been detailed. In various implementations of the invention, a device design having multiple power domains is identified. Additionally, a verification statement corresponding to the device design is identified. Subsequently, an auxiliary verification statement defining properties to check if the power domains are active at appropriate times is generated. The auxiliary verification statement may be used in conjunction with the verification statement to verify correct operation of the device design. Particularly, the auxiliary verification statement may be used to ensure that the power domain transitions do not interfere with the operation of the device design.

With various implementations of the invention, an auxiliary verification statement may be generated by first determining a set of properties instantiated in a verification statement and then synthesizing the auxiliary verification statement based upon the determined properties, the corresponding device design and the power domains. In some implementations, the auxiliary verification statement instantiates properties that check if the power domains related to the properties in the verification statement are active when the verification statement is exercised. In various implementations, this is accomplished by substituting select ones of the properties in the verification statement with select properties corresponding to the power domain.

Although certain devices and methods have been described above in terms of the illustrative embodiments, the person of ordinary skill in the art will recognize that other embodiments, examples, substitutions, modification and alterations are possible. It is intended that the following claims cover such other embodiments, examples, substitutions, modifications and alterations within the spirit and scope of the claims.

Claims

1. A computer implemented method for synthesizing a set of auxiliary verification statements comprising:

accessing by a computer a device design;

accessing by the computer a verification statement corresponding to the device design;

identifying a plurality of power domains in the device design;

identifying first property instantiated in the verification statement;

synthesizing on the computer a set of auxiliary verification statements based in part upon the plurality of power domains and the first property;

saving the set of auxiliary verification statements to a memory storage location.

2. The computer implemented method recited in claim 1, the method act of synthesizing on the computer a set of auxiliary verification statements based in part upon the plurality of power domains and the first property comprising:

determining on the computer a plurality of driving power domains corresponding to the first property, the plurality of driving power domains being a subset of the plurality of power domains; and

for the plurality of driving power domains, determining a condition wherein the driving power domain is active; generating an auxiliary property based on the condition and the first property; generating an auxiliary verification statement based on the auxiliary property and the verification statement; and adding the auxiliary verification statement to the set of auxiliary verification statements.

3-8. (canceled)

9. The computer implemented method recited in claim 2, the method act of identifying a first property instantiated in the verification statement comprising:

selecting a property from the verification statement; and

translating the property into the linear temporal logic form.

10. The computer implemented method recited in claim 9, the device design having a plurality of design elements; and

the method act of determining on the computer a plurality of driving power domains corresponding to the first property comprising: identifying ones of the plurality of design elements corresponding to the first property; and identifying ones of the plurality of power domains corresponding to the ones of the plurality of design elements.

11. The computer implemented method recited in claim 10, the translated property having the form pv1 U! pv2.

12. The computer implemented method recited in claim 11, the method act of generating an auxiliary property based on the condition and the first property comprising:

identifying pv2 from the translated property; and

forming the auxiliary property from the condition and pv2.

13. The computer implemented method recited in claim 12, the auxiliary property having form c W pv2, where c represents the condition.

14. The computer implemented method recited in claim 13, further comprising:

identifying a second property instantiated in the verification statement; and

wherein the method act of synthesizing a set of auxiliary verification statements is further based in part upon the second property.

15. The computer implemented method recited in claim 14, further comprising making the set of auxiliary verification statements available to a formal verification engine.

16. The computer implemented method recited in claim 10, the translated property having the form X! pv2.

17. The computer implemented method recited in claim 16, the method act of generating an auxiliary property based on the condition and the first property comprising;

identifying the operator from the translated property; and

forming the auxiliary property from the condition and operator.

18. The computer implemented method recited in claim 17, the auxiliary property having the form X c, where c represents the condition.

19. An article of manufacture for synthesizing a set of auxiliary verification statements comprising:

software instructions for enabling a computer to perform a set of predetermined operations; and

a computer readable medium bearing the software instructions;

the set of predetermined operations including: accessing a device design; accessing a verification statement corresponding to the device design; identifying a plurality of power domains in the device design; identifying a first property instantiated in the verification statement; synthesizing a set of auxiliary verification statements based in part upon the plurality of power domains and the first property; saving the set of auxiliary verification statements to a memory storage location.

20. The article of manufacture recited in claim 19, the predetermined operation for synthesizing a set of auxiliary verification statements based in part upon the plurality of power domains and the first property comprising:

determining a plurality of driving power domains corresponding to the first property, the plurality of driving power domains being a subset of the plurality of power domains; and for the plurality of driving power domains, determining a condition wherein the driving power domain is active; generating an auxiliary property based on the condition and the first property; generating an auxiliary verification statement based on the auxiliary property and the verification statement; and adding the auxiliary verification statement to the set of auxiliary verification statements.

21. The article of manufacture recited in claim 20, the predetermined operation for identifying a first property instantiated in the verification statement comprising:

selecting a property from the verification statement; and

translating the property into the linear temporal logic form.

22. The article of manufacture recited in claim 21, the device design having a plurality of design elements; and

the predetermined operation for determining a plurality of driving power domains corresponding to the first property comprising: identifying ones of the plurality of design elements corresponding to the first property; and identifying ones of the plurality of power domains corresponding to the ones of the plurality of design elements.

23. The article of manufacture recited in claim 22, the translated property having the form pv1 U! pv2.

24. The article of manufacture recited in claim 23, the predetermined operation for generating an auxiliary property based on the condition and the first property comprising:

identifying pv2 from the translated property; and

forming the auxiliary property from the condition and pv2.

25. The article of manufacture recited in claim 24, the auxiliary property having the form c W pv2, where c represents the condition.

26. The article of manufacture recited in claim 25, the set of predetermined operations further comprising:

identifying a second property instantiated in the verification statement; and

wherein the method act of synthesizing a set of auxiliary verification statements is further based in part upon the second property.

27. The article of manufacture recited in claim 26, the set of predetermined operations further comprising making the set of auxiliary verification statements available to a formal verification engine.

28. The article of manufacture recited in claim 22, the translated property having the form X! pv2.

29. The article of manufacture recited in claim 28, the predetermined operation for generating an auxiliary property based on the condition and the first property comprising:

identifying the operator from the translated property; and

forming the auxiliary property from the condition and operator.

30. The article of manufacture recited in claim 29, the auxiliary property having the form X c, where c represents the condition.

31. A formal verification tool for synthesizing a set of auxiliary verification statements comprising:

a design processing unit capable of accessing a device design;

a specification processing unit capable of accessing a verification specification;

an auxiliary verification statement generation unit capable of synthesizing a set of auxiliary verification statements based upon the device design and the verification specification; and

a formal verification engine capable of verifying the device design according to the verification specification and the set of auxiliary verification statements.