Patent Description:
<CIT> describes methods and apparatuses for verifying power state transitions within a device.

The embodiments described below are provided by way of example only and are not limiting of implementations which solve any or all of the disadvantages of known power analysis systems.

Described herein are methods, systems and hardware monitors for verifying that an integrated circuit defined by a hardware design meets a power requirement. The method includes detecting whether a power consuming transition has occurred for one or more flip-flops of the hardware design; in response to detecting that a power consuming transition has occurred, updating a count of power consuming transitions for the hardware design; and determining, whether the power requirement is met at a particular point in time by evaluating one or more properties that are based on the count of power consuming transitions.

The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Embodiments will be described, by way of example, with reference to the following drawings, in which:.

Common reference numerals are used throughout the figures to indicate similar features.

Embodiments are described below by way of example only. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

Described herein are methods and systems for verifying that an integrated circuit defined by a hardware design meets a power requirement. The power requirement may be, for example, that the integrated circuit defined by the hardware design consumes less power than an integrated circuit defined by another hardware design (e.g. a previous iteration of the same hardware design); or that the power consumption of the integrated circuit defined by the hardware design remains within predefined bounds. Some of the methods and systems described herein estimate the dynamic power consumption of the integrated circuit defined by the hardware design from the number of power consuming transitions and determine whether the power requirement is met based on the estimated dynamic power consumption (i.e. the number of power consuming transitions) using formal.

The term "hardware design" is used herein to refer to a description of an integrated circuit for all or part of an electronic system (e.g. a processor) which can be used to generate a hardware manifestation of the integrated circuit (e.g. the hardware design may be synthesized into silicon or used to program a field-programmable gate array (FPGA)). The hardware design may relate to a module, block, unit, sub-system, system or any combination thereof of the electronic system (e.g. processor).

A hardware design may be implemented in a high level hardware description language (HDL), such as, but not limited to, a register transfer language (RTL). Examples of register transfer languages include, but are not limited to, VHDL (VHSIC Hardware Description Language) and Verilog. It will be evident to a person of skill in the art that other high level hardware description languages may be used such as proprietary high level hardware description languages.

As described above, minimizing the power consumption of an integrated circuit defined by a hardware design is an ongoing challenge. Reducing the power consumption of the integrated circuit typically involves analyzing the power consumption of the integrated circuit described by the hardware design and modifying the hardware design based on the analysis to reduce the power consumption of the integrated circuit. There are many software tools that can aid in power analysis and measurement. However, once a hardware design has been modified, it is important to be able to determine exhaustively whether the integrated circuit defined thereby actually consumes less power than the integrated circuit described by the previous iteration of the hardware design and/or whether the power consumption of the integrated circuit defined by the modified hardware design remains within expected bounds.

There are two main components to the power consumed by an integrated circuit: static power and dynamic power. Static power is the power that is consumed when the integrated circuit is in a steady state (i.e. the integrated circuit is not switching or changing state). In other words the static power is the power that is consumed regardless of whether there is a state change. Static power typically comprises the standby or leakage power and may vary for different states of the clock(s), data and output. In contrast, dynamic power is the power that is consumed to invoke a state transition (i.e. power that is consumed when the integrated circuit is switching or changing state). Dynamic power is consumed when a transistor switches from one logic state to another. An integrated circuit is typically comprised of flip-flops and gates which each comprise one or more transistors. For example, a reset D-type flip-flop may have around twelve transistors and a two-input AND gate may have six transistors. The remainder of this application will be focused on estimating the dynamic power associated with flip-flop transitions, but similar principles could be applied to estimate the dynamic power of individual gates as well.

Dynamic power associated with a flip-flop comprises three sub-components: transition power, clock power, and data power. Transition power (also referred to as switching power) is the power that is consumed by a flip-flop when there is an output transition (e.g. the output of the flip-flop transitions from a "<NUM>" to a "<NUM>"). Clock power is the power that is consumed by a flip-flop when a transition on the clock trigger signal takes place (e.g. the clock input transitions from a "<NUM>" to a "<NUM>"). Data power is the power consumed by a flip-flop when there is an input transition (e.g. the input to the flip-flop transitions from a "<NUM>" to a "<NUM>"). The specific dynamic power consumed by a flip-flop is based on the switching (frequency), voltage and capacitance.

Reference is made to <FIG> which illustrates an example D-type flip-flop <NUM> which has a data input port ("D") which receives an input data signal (DATA_IN), a clock input port ("C") which receives a clock trigger signal (CLK_T), and an output port ("Q") which outputs a data signal (DATA_OUT). The clock trigger signal (CLK_T) controls or triggers when the data at the input port ("D") is latched or stored in the flip-flop, and when the data stored in the flip-flop is output. For example, in some cases when the clock trigger signal (CLK_T) is HIGH the value presently stored in the flip-flop will be output as DATA_OUT and the present value of the DATA_IN signal will be stored in the flip-flop.

The clock trigger signal (CLK_T) may be a clock signal, or it may be a clock signal combined with one or more other signals, such as an enable signal and/or a clock gating signal. The enable signal may be, for example, the output of a latch controlled from a power domain setting which may be controlled by software. Where the clock trigger signal (CLK_T) is a clock signal the D-type flip-flop implements a one cycle delay to the DATA_IN signal. Specifically, the value of DATA_IN will be seen on DATA_OUT one cycle later (e.g. the next clock cycle).

<FIG> illustrates a table <NUM> showing the type of power that is consumed for different states of the flip-flop <NUM>. It can be seen from the table <NUM> that regardless of the state of any of the signals or a transition thereof leakage power (LP) is consumed. If there is a transition on the DATA_IN signal then data power (DP) is consumed; if there is a transition on the clock trigger signal (e.g. CLK_T) then clock power (CP) is consumed; and if there is a transition on the DATA_OUT signal then transition power (TP) is consumed.

Typically the static power (e.g. leakage power (LP)) is minor and thus the power consumption of an integrated circuit can be accurately estimated from the dynamic power consumption. Accordingly, the power consumption of an integrated circuit may be estimated by counting one or more of the number of flip-flop transitions, clock trigger signal transitions, and/or input data signal transitions which will collectively be referred to herein as power consuming transitions.

Described herein are systems, methods, and hardware monitors for verifying that an integrated circuit defined by a hardware design meets a power requirement for a scenario by generating one or more properties that define the power requirement in terms of the number of power consuming transitions; counting one or more types of power consuming transitions for the scenario; and verifying the properties.

For example, the power requirement may be that the number of power consuming transitions for a particular flip-flop containing read data from a memory access does not exceed <NUM> for a particular scenario - e.g. any <NUM> reads that can occur in any order and in any combination. A property is generated which states that the counted number of power consuming transitions for the read flip-flop is less than <NUM>. A hardware monitor is generated and configured to count the number of power consuming transitions for the particular read flip-flop. The hardware design, the hardware monitor, the property, and the scenario are loaded into a formal verification tool. The formal verification tool then determines whether there is a combination of <NUM> reads which results in more than <NUM> power consuming transitions. In other words, the formal verification tool determines whether there exists a combination of up to <NUM> reads which causes the property to fail (i.e. for there to be more than <NUM> power consuming transitions).

Reference is now made to <FIG> which illustrates an example system <NUM> for exhaustively verifying that an integrated circuit defined by a hardware design meets a power requirement. The system <NUM> comprises a hardware design <NUM> for an integrated circuit that comprises or defines one or more flip-flops <NUM>; a power requirement <NUM>; a scenario <NUM> under which the power requirement <NUM> is to be met; a hardware monitor <NUM> for counting one or more types of power consuming transitions; one or more properties <NUM> which are used to determine whether the power requirement is met based on the count(s); and a formal verification tool <NUM> configured to use the hardware monitor <NUM> and properties <NUM> to determine if the integrated circuit described by the hardware design <NUM> meets the power requirement <NUM> for the defined scenario <NUM>.

The hardware design <NUM> describes or defines an integrated circuit with one or more flip-flops <NUM>. The exemplary hardware design <NUM> of <FIG> comprises two D-type flip-flops <NUM> as described above with respect to <FIG>, but it will be evident to a person of skill in the art that the methods and principles described herein can be equally applied to hardware designs describing integrated circuits with more or fewer flip-flops and/or different types of flip-flops. As described above, the hardware design <NUM> may define an integrated circuit for all or part of an electronic device (e.g. processor) and may be implemented in a hardware description language (HDL), such as but not limited, to a register transfer level (RTL) language.

The power requirement <NUM> defines the power consumption criteria that the integrated circuit defined by the hardware design <NUM> is expected to meet. In some cases, the power requirement <NUM> may specify that the dynamic power consumption is less than a predetermined threshold or maximum value. The predetermined threshold or maximum value may be expressed in terms of a number of power consuming transitions (or a specific type of power consuming transitions) or in terms of power. For example, the power requirement <NUM> may specify that the total number of power consuming transitions is less than a predetermined number (e.g. the total number of power consuming transitions is less than <NUM>) or that the total dynamic power consumption is less than a certain power value (e.g. the total dynamic power consumption is less than <NUM> nW).

In other cases the power requirement <NUM> may specify that the dynamic power consumption of the integrated circuit defined by the hardware design <NUM> is less than the dynamic power consumption of the integrated circuit defined by another hardware design (e.g. a previous version of the hardware design <NUM>). For example the power requirement <NUM> may specify that the number of power consuming transitions (or a specific type of power consuming transitions) for a hardware design is less than the counted number of power consuming transitions (or a specific type of power consuming transitions) for another hardware design under the same conditions or scenario <NUM>.

The scenario <NUM> defines (e.g. in a formal verification language) the circumstances under which the power requirement <NUM> is to be met. For example, the scenario <NUM> may define that the power requirement <NUM> is to be met for <NUM> reads of a particular read flip-flop done in any order and any combination.

The scenario <NUM> may define which flip-flops are to be monitored and the type of power consuming transitions to be counted for those flip-flops. In some cases the scenario <NUM> may directly identify which flip-flop(s) <NUM> are relevant. For example, the scenario <NUM> may identify a particular flip-flop, multiple selected flip-flops, or all the flip-flops. In other cases the scenario <NUM> may more generally specify a component and or aspect of the hardware design <NUM> which is used to identify the relevant flip-flops For example, the scenario <NUM> may specify that the read components are relevant and this may be used to identify the flip-flops that are considered read components.

The hardware monitor <NUM> is a module configured to monitor the inputs and/or outputs of one or more flip-flops of the hardware design <NUM> to count one or more types of power consuming transitions. The hardware monitor <NUM> may be implemented in software. For example, the hardware monitor <NUM> may be implemented using a hardware description language (HDL).

As described above, there are three types of power consuming transitions - flip-flop transitions (i.e. changes in the output signal of a flip-flop (e.g. DATA_OUT); clock signal transitions (i.e. changes in the clock trigger signal of a flip-flop (e.g. CLK_T)); and data transitions (i.e. transitions in the input data signal (e.g. DATA_IN)). The hardware monitor <NUM> may be configured to count one, or more than one, type of power consuming transitions based on the power requirement <NUM> and scenario <NUM>.

In some examples, as shown in <FIG>, the hardware monitor <NUM> may be configured to count the number of flip-flop transitions (i.e. the changes in output of the flip-flop(s)). In these examples the hardware monitor <NUM> is configured to monitor the output signal (e.g. "Q" output) of the one or more flip-flops <NUM>. In other examples, the hardware monitor <NUM> may be configured to count the number of clock trigger signal transitions (i.e. the changes in the clock trigger signal). In these examples the hardware monitor <NUM> is configured to monitor the clock trigger signal (e.g. "C" input) to the one or more flip-flops. In yet other examples, the hardware monitor <NUM> may be configured to count both the flip-flop transitions and the clock trigger signal transitions. In these examples the hardware monitor <NUM> is configured to monitor both the output signal (e.g. "Q" output) and the clock trigger signal (e.g. "C" input) to one or more flip-flops <NUM>.

The hardware monitor <NUM> may be configured to count power consuming transitions for one or more of the flip-flops in the integrated circuit defined by the hardware design <NUM> depending on, for example, the scenario <NUM>.

The hardware monitor <NUM> is bound to the corresponding input and output ports of the hardware design <NUM>. For example, where, as shown in <FIG>, the hardware monitor <NUM> is configured to monitor the flip-flop transitions of two flip-flops <NUM> of the hardware design <NUM> then the hardware monitor <NUM> is bound to the outputs (e.g. DATA_OUT_1 and DATA_OUT_2) of the flip-flops. Where the hardware monitor <NUM> is implemented in SV and the hardware design <NUM> is implemented in RTL, the SV code is bound to the RTL code.

The properties <NUM> express the power requirement in terms of the number of power consuming transitions. A determination of whether the power requirement is met can then be determined by evaluating the properties <NUM> to determine whether they are true based on the number of power consuming transitions counted by the hardware monitor <NUM>.

As is known to those of skill in the art a property is a statement or expression that captures design behavior. For example, a simple property may be a = b. Within HDL designs, a property is an executable statement that checks for specific behavior within the HDL design. For example if a design contains a FIFO (first in first out) buffer a property may be that neither overflow nor underflow of the FIFO may occur.

Properties are used to capture required or desired temporal behavior of the hardware design in a formal and unambiguous way. The design can then be verified to determine that it conforms to the required or desired behavior as captured by one or more properties.

Since properties capture the design behavior on a cycle-by-cycle basis they can be used to verify intermediate behaviors. In the examples described herein the one or more properties express the power requirement as evaluable expressions or statements based on the count of the power consuming transitions.

If, for example, the power requirement is that there must not be more than <NUM> power consuming transitions, there may be a property that states that the count of power consuming transitions is less than or equal to <NUM>. In this example, if the count is less than or equal to <NUM> then the property is valid or true and the power requirement is met; and if the count is greater than <NUM> then the property is invalid or false and the power requirement is not met.

In some cases the power requirement may be expressed in terms of actual power (e.g. Watts). In these cases the count of power consuming transitions may be converted to a power value (e.g. Watts) and the property is then defined to compare the converted power value (i.e. the power value the count represents) to the power value specified by the power requirement. For example, a table such as Table <NUM> shown below may be used to convert the count of power consuming transitions into power (e.g. Watts).

Properties are typically written in an assertion language. An assertion language, which also may be referred to as a property language captures the design behavior spread across multiple design cycles in a concise, unambiguous manner. While traditional hardware description languages (HDL), such as Verilog RTL, have the ability to capture individual cycle behavior, they are too detailed to describe properties at a higher level. In particular, assertion languages provide means to express temporal relationships and complex design behaviors in a concise manner. Assertion languages include, but are not limited to, System Verilog (SV), Property Specification Language (PSL), Incisive Assertion Library (IAL), Synopsys OVA (OpenVera Assertions), Symbolic Trajectory Evaluation (STE), Hardware Property Language (HPL), <NUM>-In, and Open Verification Library (OVL).

Each property <NUM> may be asserted or covered. When a property is asserted it must always be true. In contrast, when a property is covered the property must be true at least once, but is not required to be true always.

The one or more properties <NUM> may form part of, or be integrated with, the hardware monitor <NUM> as shown in <FIG> or they may be bound to the hardware monitor <NUM>.

Example implementations of the hardware monitor <NUM> and properties <NUM> are described below with reference to <FIG>, <FIG> and <FIG>.

The hardware design <NUM> (e.g. RTL), hardware monitor <NUM> (e.g. SV), properties <NUM>, bindings and scenario <NUM> are loaded into a formal verification tool <NUM>. The formal verification tool <NUM> is a software tool that is capable of performing formal verification of a hardware design. Formal verification is a systematic process that uses mathematical reasoning to verify a property in a hardware design. Formal verification can be contrasted to simulation-based verification in which a hardware design is tested by applying stimuli to the hardware design and monitoring the output of the hardware design in response to the stimuli.

In formal verification the hardware design (e.g. hardware design <NUM>) is transformed into a mathematical model (e.g. a state-transition system) and the properties (e.g. properties <NUM>) are expressed using mathematical logic using a precise syntax or a language with a precise mathematical syntax and semantics.

A property is verified by searching the entire reachable state space of the hardware design (e.g. state transition system) without explicitly traversing the state machine. The search is done by, for example, encoding the states using efficient Boolean encodings using Binary decision diagrams (BDDS), or using advanced SAT (satisfiability-based bounded model checking) based techniques. In some cases tools can be used to implement techniques, such as, but not limited to, abstraction, symmetry, symbolic indexing, and invariants to improve performance and achieve scalability.

A property that is covered is verified by searching the reachable state space of the hardware design (e.g. state transition system) for at least one state in which the property is true. Once a state is found in which the property is true then the searching ceases. In contrast, a property that is asserted is verified by confirming the property is true for all states. In other words an asserted property is verified by searching the reachable state space of the hardware design for a state in which the property is not true. Since formal verification of an asserted property algorithmically and exhaustively explores all input values over time, verifying an asserted property in this manner allows a property to be exhaustively proved or disproved for all states.

The formal verification tool <NUM> may output an indication of whether or not the power requirement is met. The output may be yes the power requirement is met; no the power requirement is not met; or the formal verification was inconclusive. The formal verification may be inconclusive, for example, because the computing-based device running the formal verification tool <NUM> has run out of memory or because the formal verification tool <NUM> has determined that a certain amount of progress has not been made after a predefined period of time.

Accordingly, in the system <NUM> of <FIG> the formal verification tool <NUM> evaluates states of the hardware design <NUM> that fall within the defined scenario <NUM> using the hardware monitor <NUM> to determine whether the properties <NUM> are true (i.e. each asserted property is true for all states and each covered property is true for at least one state).

Reference is now made to <FIG> which illustrates a flow chart of a method <NUM> of verifying that the integrated circuit described by a hardware design meets a power requirement for a defined scenario. The method <NUM> begins at block <NUM> where the power requirement <NUM> to be satisfied; and the scenario <NUM> (e.g. defined in a formal verification language) under which the power requirement <NUM> is to be satisfied are obtained. Once the power requirement <NUM> and scenario <NUM> have been obtained the method <NUM> proceeds to block <NUM>.

At block <NUM>, one or more properties (e.g. properties <NUM>) are defined which express the power requirement <NUM> in terms of the number of power consuming transitions. For example, if the power requirement is that the number of power consuming transitions should not exceed <NUM> then a property may be defined that states that the number of power consuming transitions is less than or equal to <NUM>. Once the one or more properties are defined the method <NUM> proceeds to block <NUM>.

At block <NUM>, a hardware monitor (e.g. hardware monitor <NUM>) is generated to count the number of power consuming transitions of relevant flip-flops based on the power requirement <NUM> and the scenario <NUM> obtained in block <NUM>. As described above, the hardware monitor may be configured to count the number of flip-flop transitions and/or clock transitions for one or more relevant flip-flops of the hardware design. Once the hardware monitor is generated the method <NUM> proceeds to block <NUM>.

At block <NUM>, a formal verification tool (e.g. formal verification tool <NUM>) uses the properties <NUM> defined in block <NUM>, the hardware monitor obtained in block <NUM>, and the scenario obtained in block <NUM> to formally verify that the integrated circuit defined by the hardware design meets the power requirement for the scenario. In particular, as described above, the formal verification tool assesses states of the hardware design, within the defined scenario <NUM>, using the hardware monitor <NUM> to determine whether the properties <NUM> are true.

Reference is now made to <FIG> which illustrates an example method <NUM> for determining whether an integrated circuit defined by a hardware design meets a power requirement using the hardware monitor <NUM> of <FIG> wherein the properties <NUM> are integrated therein. In some cases the method <NUM> may be executed by the hardware monitor <NUM> each clock cycle (e.g. upon the rising edge of the clock signal). However, in other cases the method <NUM> may be executed more or less frequently, or upon a different trigger or triggers.

The method <NUM> begins at block <NUM> where the hardware monitor <NUM> of <FIG>, monitors the inputs and/or output signals of one or more flip-flops of the hardware design based on the power requirement <NUM> and the scenario <NUM>. As described above, the hardware monitor <NUM> may be configured, for example, to monitor: (i) the output signal (e.g. DATA_OUT) of one or more flip-flops to detect a flip-flop transition; (ii) the clock trigger signal (e.g. CLK_T) to detect an clock transition; or (iii) both the output signal (e.g. DATA_OUT) and the clock trigger signal (e.g. CLK_T) of one or more flip-flops to detect both flip-flop transitions and clock transitions. The input and/or output signals that are monitored may be referred to herein as the relevant signals. In some cases monitoring the relevant signals comprises sampling the relevant signals. The method <NUM> then proceeds to block <NUM>.

At block <NUM> the hardware monitor <NUM> determines whether at least one power consuming transition has occurred. As described above, the hardware monitor <NUM> may determine that a power consuming transition has occurred if the current value of a monitored signal (e.g. the value of the signal in the current clock cycle) is different than the previous value of the monitored signal (e.g. the value of the signal in the previous clock cycle). If the hardware monitor <NUM> determines that no power consuming transitions have occurred then the method <NUM> may proceed to block <NUM>. If, however, the hardware monitor <NUM> determines that at least one power consuming transition has occurred then the method <NUM> proceeds to block <NUM>.

At block <NUM>, the hardware monitor <NUM> updates one or more counters to reflect the number of power consuming transitions that have occurred. For example, if in block <NUM> it is detected that two power consuming transitions have occurred then the hardware monitor <NUM> may increment a counter value by two to reflect the fact that two additional power consuming transitions have occurred. Once the counter(s) have been updated the method <NUM> proceeds to block <NUM>.

At block <NUM>, the hardware monitor <NUM> evaluates one or more properties that express the power requirement in terms of the number of power consuming transitions to determine whether a power requirement is met. For example, where the power requirement is that the power consuming transitions must not exceed <NUM> then the property may state that the count of the power consuming transitions is less than or equal to <NUM>. In this case evaluating the property may involve determining whether the count of power consuming transitions is less than or equal to <NUM>. Once the properties have been evaluated the method <NUM> proceeds to block <NUM>.

At block <NUM>, a message may be output based on whether or not the properties were evaluated to be true and whether the properties were asserted or covered. For example, if an asserted property was determined not to be true in block <NUM> then a message may be output indicating that the assertion failed. If, however, a covered property was determined to be true in block <NUM> then a message may be output indicating that the cover has been met.

Example implementations of the hardware monitor <NUM> of <FIG> and operation thereof will be described below with reference to <FIG>.

Reference is now made to <FIG> which illustrates a first example implementation of a hardware monitor <NUM>, which may be used as hardware monitor <NUM> of <FIG> in which the properties <NUM> are embedded therein. In this example implementation the hardware monitor <NUM> counts the number of output transitions of one or more flip-flops. In the example shown in <FIG>, the hardware monitor <NUM> is configured to count the number of output transitions of two flip-flops in a hardware design. However, in other examples, the hardware monitor may be configured to count the flip-flop transitions for more or fewer flip-flops depending on, for example, the number of flip-flops in the hardware design and the power requirement <NUM> and/or scenario <NUM>.

The hardware monitor <NUM> of <FIG> includes flip-flop transition detection logic units <NUM>, <NUM> for detecting a flip-flop transition, a counter <NUM> for storing a count of the number of flip-flop transitions, a counter update logic unit <NUM> for updating the counter <NUM> after a flip-flop transition detection logic unit <NUM>, <NUM> detects a flip-flop transition, and a property verification logic unit <NUM>.

Each flip-flop transition detection logic unit <NUM>, <NUM> monitors the output signal (e.g. DATA_OUT) of a particular flip-flop of the hardware design to determine when there is a change in the output signal of that flip-flop. In other words, each flip-flop transition detection logic unit <NUM>, <NUM> is configured to detect when there has been a flip-flop transition for a particular flip-flop.

Each flip-flop transition detection logic unit <NUM>, <NUM> may determine that there has been a change in the output of a particular flip-flop of the hardware design by sampling the output signal and comparing the sampled value of the output signal to the previous value of the output signal (e.g. comparing the value of the output signal in a current clock cycle to the value of the output signal in the previous clock cycle). If the current value is different than the previous value then a flip-flop transition has been detected. If, however, the current value of the output signal is the same as the previous value of the output signal then a flip-flop transition is not detected.

In some cases, the flip-flop transition detection logic unit <NUM>, <NUM> may be configured to use a formal verification language system function to obtain the previous value of the output signal (e.g. DATA_OUT). For example, SVA has the system function $past (x) which returns the value of an expression, x, in a previous clock cycle. In other cases, the flip-flop transition detection logic unit <NUM>, <NUM> may be configured to store the current value of the output signal (e.g. DATA_OUT) in a memory unit, such as a register, and then in the subsequent clock cycle the previous value of the output signal (e.g. DATA_OUT) can be obtained from the memory unit (e.g. register).

When a flip-flop transition detection logic unit <NUM> or <NUM> detects a flip-flop transition it notifies the counter update logic unit <NUM>. For example, the flip-flop transition detection logic unit <NUM> or <NUM> may output an update signal that is received by the counter update logic unit <NUM>.

Although the hardware monitor <NUM> of <FIG> has a separate flip-flop transition detection logic unit <NUM>, <NUM> for each flip-flop that is being monitored, it will be evident to a person of skill in the art that there may be a single flip-flop transition detection logic unit that is configured to monitor multiple flip-flops for flip-flop transitions. In these cases the flip-flop transition detection logic unit may be configured to output the number of transitions detected in each clock cycle as part of the update signal; or the flip-flop transition detection logic unit may be configured to output multiple update signals (e.g. one per monitored flip-flop).

The counter <NUM> is used to store the count of the number of flip-flop transitions that have been detected. As described above, the number of flip-flop transitions represents the transition power consumption of the relevant component or part of the integrated circuit defined by the hardware design. The counter <NUM> may be implemented using any suitable memory module, such as a register. The counter <NUM> is updated by the counter update logic unit <NUM>.

Although the hardware monitor <NUM> of <FIG> has a single counter <NUM> for storing a total count of the flip-flop transitions for all monitored flip-flops, in other cases there may be a counter for each monitored flip-flop that is used to store the count or number of flip-flop transitions for that particular flip-flop. In these cases there may be a single counter update logic unit that is configured to update all counters or there may be a counter update logic unit for each counter that is responsible for updating that counter.

The counter update logic unit <NUM> monitors the notifications (e.g. update signal(s)) received from the flip-flop transition detection logic units <NUM>, <NUM> to determine if they indicate a flip flop transition has occurred. If the counter update logic unit <NUM> detects that at least one flip-flop transition has occurred then the counter update logic unit <NUM> increments the counter <NUM> value by the number of flip-flop transitions. For example, if the update signal(s) indicate that one flip-flop transition has occurred then the counter update logic unit <NUM> increments the counter <NUM> by one; and if the update signal(s) indicate that two flip-flop transitions have occurred then the counter update logic unit <NUM> increments the counter <NUM> by two.

Where the counter update logic unit <NUM> receives an update signal for each monitored flip-flop then the counter update logic unit <NUM> may be configured to identify the number of flip-flop transitions that have occurred by counting the number of update signals that indicate a flip-flop transition has occurred. Where, however, there is a single update signal which comprises information that indicates the number of flip-flop transitions detected, the counter update logic unit <NUM> may be configured to identify the number of flip-flop transitions that have occurred from the information in the update signal itself.

The property verification logic unit <NUM> periodically assesses one or more properties to verify that the integrated circuit defined by the hardware design meets the specified power requirement. Each property defines an expression related to the counter that indicates whether the hardware design meets the specified power requirement. For example, if the power requirement is that the number of flip-flop transitions does not exceed <NUM> then the property may state or express that the counter is less than or equal to <NUM>. As described above a property may be asserted or covered. If the property verification logic unit <NUM> determines that an asserted property is not true then the property verification logic unit <NUM> may output an error message. Conversely, if the property verification logic unit <NUM> determines that a covered property is true then the property verification logic unit <NUM> may output a message indicating the property is true.

Although, not shown in <FIG>, it will be evident to a person of skill in the art that the logic units (e.g. flip-flop transition detection logic units <NUM>, <NUM>; counter update logic unit <NUM>; and property verification logic unit <NUM>) may be triggered by a clock. For example, one or more of the logic units may be triggered by the rising or positive edge of the clock. Furthermore, it will be evident to a person of skill in the art that one or more of the logic units (e.g. flip-flop transition detection logic units <NUM>, <NUM>; counter update logic unit <NUM>; and property verification logic unit <NUM>) may be combined or their functionality may divided between logic units in another manner.

Reference is now made to <FIG> which illustrates an example method <NUM> for verifying that an integrated circuit defined by the hardware design meets a power requirement using the hardware monitor <NUM> of <FIG>. The example method <NUM> comprises two processes <NUM> and <NUM> which may be executed in parallel. The first process <NUM> monitors the output signal of the relevant flip-flops and updates the counter when a transition on a monitored output signal is detected. The second process <NUM> periodically evaluates one or more properties that express the power requirement in terms of the counter value(s) to determine whether the power requirement is met.

In the first process <NUM>, which may be executed by the flip-flop transition detection logic units <NUM>, <NUM> and the counter update logic <NUM>, the output signals of the relevant flip-flops are monitored at block <NUM>. If a change in at least one of the monitored output signals is detected at block <NUM> then the counter (or counters) are updated at block <NUM> to indicate the number of flip-flop transitions detected. A change in a particular flip-flop output signal may be detected by comparing the current value of the output signal (e.g. the value of the output signal in the current clock cycle) to the previous value of the output signal (e.g. the value of the output signal in the previous clock cycle). As described above, the previous value of a particular flip-flop output signal may be obtained from a formal verification language system function, such as $past, or may be stored in a memory unit, such as a register. If no change is detected at block <NUM> the output signals of the relevant flip-flop(s) continue to be monitored at block <NUM>.

In the second process <NUM>, which may be executed by the property verification logic unit <NUM>, blocks <NUM> to <NUM> are executed to evaluate the one or more properties to determine whether the integrated circuit described by the hardware design meets the power requirement. In particular, in block <NUM> one or more properties which express the power requirement in terms of the number of flip-flop transitions are evaluated. At block <NUM> it is determined whether a notification is to output. For example, as described above, if the property verification logic unit <NUM> determines in block <NUM> that an asserted property is not true then the assertion is not valid and an error message may be output. If however, the property verification logic <NUM> determines in block <NUM> that a covered property is true then the cover is true and a notification message may be output. If no notification is to be output the method <NUM> proceeds back to block <NUM>. Otherwise, the process <NUM> proceeds to block <NUM> where the appropriate notification is output. In some cases block <NUM> may be triggered upon detecting the rising edge of a main clock. However, in other cases the block <NUM> may be triggered by another event.

Reference is now made to <FIG> which illustrates a second example implementation of a hardware monitor <NUM>, which may be used as hardware monitor <NUM> of <FIG>. In this example implementation the hardware monitor <NUM> counts the number of transitions of the clock trigger signal (e.g. CLK_T) of one or more flip-flops of a hardware design. In this example, the hardware monitor <NUM> is configured to count the number of transitions of the clock trigger signals of two flip-flops in a hardware design. However, in other examples, the hardware monitor <NUM> may be configured to count the clock trigger signal transitions for more or fewer flip-flops depending on, for example, the number of flip-flops in the hardware design, the power requirement <NUM> and scenario <NUM>.

The hardware monitor <NUM> of <FIG> includes clock trigger signal transition detection logic units <NUM>, <NUM> for detecting a transition in the clock trigger signal of a flip-flop, a counter <NUM> for storing a count of the number of clock trigger signal transitions, a counter update logic unit <NUM> for updating the counter <NUM> after a clock trigger signal transition detection logic unit <NUM>, <NUM> detects a clock trigger signal transition, and a property verification logic unit <NUM> for evaluating one or more properties that define the power requirement in terms of the number of clock trigger signal transitions to verify the integrated circuit defined by the hardware design meets the power requirement.

Each clock trigger signal transition detection logic unit <NUM>, <NUM> monitors the clock trigger signal (e.g. CLK_T) of a particular flip-flop to determine when there is a change in the clock trigger signal of that flip-flop. In other words, each clock trigger signal transition detection logic unit <NUM>, <NUM> is configured to detect when there has been a clock trigger signal transition for a particular flip-flop.

Each clock trigger signal transition detection logic unit <NUM>, <NUM> may determine that there has been a change in the clock trigger signal for a particular flip-flop by comparing the current value of the clock trigger signal (e.g. the value of the clock trigger signal in the current clock cycle) to the previous value of the clock trigger signal (e.g. the value of the clock trigger signal in the previous clock cycle). If the current value is different than the previous value then a change in the clock trigger signal has been detected. If, however, the current value is the same as the previous value then a change is not detected.

In some cases, the clock trigger signal transition detection logic units <NUM>, <NUM> may be configured to use a formal verification language system function to obtain the previous value of the clock trigger signal (e.g. CLK_T). For example, as described above, SVA has the system function $past (x) which returns the value of an expression, x, in a previous clock cycle. In other cases, the clock trigger signal transition detection logic units <NUM>, <NUM> may be configured to store the current value of the clock trigger signal (e.g. CLK_T) in a memory unit, such as a register, and then in the subsequent clock cycle the previous value of the clock trigger signal (e.g. CLK_T) can be obtained from the memory unit (e.g. register).

When a clock trigger signal transition detection logic unit <NUM> or <NUM> detects a clock trigger signal transition it notifies the counter update logic unit <NUM>. For example, the clock trigger signal transition detection logic unit <NUM> or <NUM> may output an update signal that notifies the counter update logic unit <NUM> that a clock trigger signal transition has occurred.

Although <FIG> shows a separate clock trigger signal transition detection logic unit <NUM>, <NUM> for each flip-flop that is being monitored, it will be evident to a person of skill in the art that there may be a single clock trigger signal transition detection logic unit that is configured to monitor multiple flip-flops for clock trigger signal transitions. In these cases the clock trigger signal transition detection logic unit may be configured to output the number of clock trigger signal transitions detected in each clock cycle as part of the update signal; or the clock trigger signal transition detection logic unit may be configured to output multiple update signals (e.g. one per monitored flip-flop).

The counter <NUM> is used to store a count of the number of clock trigger signal transitions of the monitored flip-flops that have been detected. As described above, the number of clock trigger signal transitions can be used as a representation of the clock power consumed by the relevant component or part of the integrated circuit defined by the hardware design. The counter <NUM> may be implemented using any suitable memory module, such as a register. The counter <NUM> is updated by the counter update logic unit <NUM>.

Although <FIG> shows a single counter <NUM> for storing a total count of the clock trigger signal transitions for all monitored flip-flops, in other cases there may be a counter for each monitored flip-flop that is used to store the count or number of clock trigger signal transitions for that particular flip-flop. In these cases there may be a single counter update logic unit that is configured to update all counters, or there may be a counter update logic unit for each counter that is responsible for updating that counter.

The counter update logic unit <NUM> works in the same manner as the counter update logic unit <NUM> of <FIG> except instead of monitoring the notifications from the clock trigger signal transition detection logic units <NUM> and <NUM> to determine if they indicate a flip flop transition has occurred the counter update logic unit <NUM> of <FIG> monitors the notifications to determine if they indicate a clock trigger signal transition. Accordingly, the description of the counter update logic unit <NUM> given above with reference to <FIG> equally applies to the counter update logic unit <NUM> of <FIG>.

The property verification logic unit <NUM>, like the property verification logic unit <NUM> of <FIG>, periodically assesses one or more properties to verify that the integrated circuit defined by the hardware design meets the specified power requirement. The one or more properties define evaluable expressions related to the number of clock trigger signal transitions that indicate whether the power requirement is met. For example, if the power requirement is that the number of clock trigger signal transitions does not exceed <NUM> then the property may state that the number of clock trigger signal transitions is less than or equal to <NUM>.

Although, not shown in <FIG>, it will be evident to a person of skill in the art that the logic units (e.g. clock trigger signal transition detection logic units <NUM>, <NUM>; counter update logic unit <NUM>; and property verification logic unit <NUM>) may be triggered by a clock. For example, one or more of the logic units may be triggered by the rising or positive edge of the clock. It will be also be evident to a person of skill in the art that the logic units may be combined into a single logic unit or their functionality may be divided between logic units in another manner.

Reference is now made to <FIG> which illustrates an example method <NUM> for verifying that an integrated circuit defined by the hardware design meets a power requirement using the hardware monitor <NUM> of <FIG>. The example method <NUM> comprises two processes <NUM> and <NUM> which may be executed in parallel. The first process <NUM> monitors the clock trigger signals (e.g. CLK_T) of the relevant flip-flops and updates the counter(s) when a clock trigger signal transition has been detected. The second process <NUM> periodically evaluates one or more properties that define the power requirement in terms of the number of clock trigger signal transitions to verify that the power requirement is met.

In the first process <NUM>, which may be executed by the clock trigger signal transition detection logic units <NUM>, <NUM>, and the counter update logic unit <NUM> the clock trigger signal input to the relevant flip-flop(s) are monitored at block <NUM>. If a change in at least one of the monitored clock trigger signals is detected at block <NUM> then the counter(s) are updated at block <NUM>. A change in a particular flip-flop clock trigger signal may be detected by comparing the current value of the clock trigger signal (e.g. the value of the clock trigger signal in the current clock cycle) to the previous value of the clock trigger signal (e.g. the value of the clock trigger signal in the previous clock cycle). As described above, the previous value of a particular flip-flop clock trigger signal may be obtained from a formal verification language system function, such as $past, or may be stored in a memory unit, such as a register. If no change is detected at block <NUM> the clock trigger signals of the relevant flip-flops continue to be monitored at block <NUM>.

In the second process <NUM>, which may be executed by the property verification logic unit <NUM>, blocks <NUM> to <NUM> are executed to evaluate one or more properties to determine whether the integrated circuit described by the hardware design meets the power requirement. In particular, in block <NUM> one or more properties which define the power requirement in terms of the number of clock trigger signal transitions are evaluated. At block <NUM> it is determined whether a notification is to be output based on the evaluation in block <NUM>. For example, if an asserted property is found to be false in block <NUM> then a notification may be output indicating the assertion is not valid. If, however, a covered property is found to be true in block <NUM> then a notification may be output indicating the cover has been met. If no notifications are to be output the process <NUM> proceeds back to block <NUM>. Otherwise, the process <NUM> proceeds to block <NUM> where the appropriate notification is output. In some cases block <NUM> may be triggered upon detecting the rising edge of a main clock. However, in other cases the block <NUM> may be triggered by another event.

Reference is now made to <FIG> which illustrates a third example implementation of a hardware monitor <NUM>, which may be used as hardware monitor <NUM> of <FIG>. In this example implementation the hardware monitor <NUM> is configured to count two types of power consuming transitions. In particular, the hardware monitor <NUM> is configured to count both the number of clock transitions (i.e. clock trigger signal transitions) and the number of flip-flop transitions (i.e. output signal transitions). In the example shown in <FIG>, the hardware monitor <NUM> is configured to count the number of clock transitions and flip-flop transitions for two flip-flops in a hardware design. However, in other examples, the hardware monitor <NUM> may be configured to count the number of flip-flop and clock transitions for more or fewer flip-flops in a hardware design based on, for example, the number of flip-flops in the hardware design, the power requirement <NUM> and/or the scenario <NUM>.

The hardware monitor <NUM> of <FIG> includes flip-flop transition detection logic units <NUM>, <NUM> for detecting a flip-flop transition, a counter <NUM> for storing a count of the number of flip-flop transitions, and a counter update logic unit <NUM> for updating the counter <NUM> after a flip-flop transition detection logic unit <NUM>, <NUM> detects a flip-flop transition. The flip-flop transition detection logic units <NUM>, <NUM>, counter <NUM> and counter update logic unit <NUM> may operate and may be configured as described above with reference to <FIG> to count the number of flip-flop transitions for the one or more flip-flops.

The hardware monitor <NUM> of <FIG> includes clock trigger signal transition detection logic units <NUM>, <NUM> for detecting a clock trigger signal transition, a counter <NUM> for storing a count of the number of clock trigger signal transitions, and a counter update logic unit <NUM> for updating the counter <NUM> after a clock trigger signal transition detection logic unit <NUM>, <NUM> detects an clock trigger signal transition. The clock trigger signal transition detection logic units <NUM>, <NUM>, counter <NUM> and counter update logic unit <NUM> may operate and may be configured as described above with reference to <FIG> to count the number of clock trigger signal transitions for the one or more flip-flops.

The hardware monitor <NUM> of <FIG> also includes a property verification logic unit <NUM> which is configured to periodically evaluate one or more properties to verify that the integrated circuit defined by the hardware design meets the specified power requirement. The one or more properties express the power requirement in terms of the number of flip-flop transitions and/or clock trigger signal transitions. For example, if the power requirement is that the total number of flip-flop transitions and clock trigger signals does not exceed <NUM> then a property may state that the sum of the two counters <NUM> and <NUM> is less than or equal to <NUM>. The property verification logic unit <NUM> may output a notification based on whether or not the property is true and whether the property is asserted or covered. For example, if the property verification logic unit <NUM> determines that an asserted property is false then the property verification logic unit <NUM> may be configured to output a notification indicating the assertion failed. If, however, the property verification logic unit <NUM> determines that a covered property is true then the property verification logic unit <NUM> may be configured to output a notification that the cover is true.

The hardware monitor <NUM> of <FIG> may be configured to identify flip-flops where the number of clock transitions (i.e. clock trigger signal transitions) is greater than the number of flip-flop transitions (i.e. output signal transitions) to identify any flip-flops that are consuming too much power. For example, a cover property may be defined for each relevant flip-flop that the number of clock trigger signal trigger signal transitions is greater than the number of flip-flop transitions. The hardware monitor <NUM> will then output a notification for any flip-flop for which this is true at least once. The hardware design may then be modified to add clock gating and/or flip-flop enables to reduce the number of clock trigger signal transitions to be closer to the number of flip-flop transitions. As described below in reference to <FIG> and <FIG> the total number of power consuming transitions for the modified hardware design can then be compared to the total number of power consuming transitions for the original hardware design to verify that the integrated circuit described by the modified hardware design does in fact consume less power than the integrated circuit described by the original hardware design.

Although, not shown in <FIG>, it will be evident to a person of skill in the art that the logic units (e.g. flip-flop transition detection logic units <NUM>, <NUM>; counter update logic unit <NUM>; clock trigger signal transition detection logic units <NUM>, <NUM>; counter update logic unit <NUM>; and property verification logic unit <NUM>) may be triggered by a clock. For example, one or more of the logic units may be triggered by the rising or positive edge of the clock.

The system <NUM> of <FIG> can be used to verify different types of power requirements. For example, the system <NUM> of <FIG> may be used to verify that the power consumption of an integrated circuit defined by a hardware design remains within expected bounds. In these cases the property used by the hardware monitor <NUM> may compare the count of power consuming transitions (or a power equivalent thereof (e.g. where the count is converted to Watts) to a fixed value. For example, the property may state or assert that the count of power consuming transitions is less than or equal to the fixed value (e.g. count <= <NUM>).

The system <NUM> of <FIG> may also be used to compare the power consumption of an integrated circuit defined by a first hardware design to the power consumption of an integrated circuit defined by a second hardware design (e.g. a previous iteration of the first hardware design). <FIG> and <FIG> illustrate two example ways in which the system of <FIG> may be used to compare the power consumption of two integrated circuits defined by two different hardware designs.

Reference is now made to <FIG> which illustrates a block diagram of a first example system <NUM> for comparing the power consumption of an integrated circuit defined by a first hardware design <NUM> to the power consumption of an integrated circuit defined by a second hardware design <NUM>. The system <NUM> of <FIG> is configured to determine whether each hardware design <NUM> and <NUM> meets a power requirement for a defined scenario <NUM>.

In particular, the system <NUM> of <FIG> comprises a hardware monitor <NUM> and <NUM> (such as hardware monitor <NUM> described above) for each hardware design <NUM> and <NUM> that is configured to count the number of power consuming transitions of the relevant flip-flops for that hardware design <NUM> or <NUM>, and evaluate one or more properties based on the count to verify that the power requirement is met. For example, the property in each hardware monitor <NUM> and <NUM> may state that the count of power consuming transitions is less than a fixed value (e.g. <NUM>) defined by the power requirement.

A formal verification tool <NUM> then uses the hardware monitors <NUM> and <NUM> and the properties defined therein to determine, for the defined scenario <NUM>, whether the power requirement is met for the two hardware designs <NUM> and <NUM>. Failure of one of the hardware designs and not the other to meet the power requirement may indicate that one hardware design will produce an integrated circuit that has better power consumption (i.e. consumes less power) than the other.

In some cases the first and second hardware designs may represent an optimized and un-optimized version of the same hardware design respectively. For example, in <FIG>, the first or un-optimized hardware design <NUM> comprises a set of control flip-flops <NUM> being driven by a number of inputs controlled by an OR gate <NUM>; and the second or optimized hardware design <NUM> is reduced to a single flip-flop <NUM> that is controlled through an AND gate <NUM>.

Reference is now made to <FIG> which illustrates a block diagram of a system <NUM> according to an embodiment of the present invention for comparing the power consumption of an integrated circuit defined by a first hardware design <NUM> to the power consumption of an integrated circuit defined by a second hardware design <NUM>. The system <NUM> of <FIG> is configured to verify that the power consumption of one integrated circuit is less than the other integrated circuit for a defined scenario <NUM>.

In particular, the system <NUM> of <FIG> comprises a hardware monitor <NUM> and <NUM> (such as hardware monitor <NUM> described above) for each hardware design <NUM> and <NUM>. Each hardware monitor <NUM> and <NUM> is configured to count the number of power consuming transitions of the relevant flip-flops for the associated hardware design <NUM> or <NUM>. The second hardware monitor <NUM> then provides the count to the first hardware monitor <NUM> and the first hardware monitor <NUM> evaluates a property that compares the two counts. For example, a property in the first hardware monitor <NUM> may state that the count of power consuming transitions for the first hardware design <NUM> is less than the count of the power consuming transitions for the second hardware design <NUM>. There may also be a second property that states that the count of the power consuming transitions for the second hardware design <NUM> is greater than or equal to the count of the power consuming transitions for the first hardware design <NUM>.

A formal verification tool <NUM> then uses the hardware monitors <NUM> and <NUM> and the properties defined therein to determine, for the defined scenario <NUM>, whether the power requirement is met. If the properties are asserted then the formal verification tool <NUM> can exhaustively prove that the integrated circuit defined by the first hardware design <NUM> always consumes less power than the integrated circuit defined by the second hardware design <NUM> for the defined scenario <NUM>.

In some cases the first and second hardware designs <NUM> and <NUM> may represent an optimized and un-optimized version of the same hardware design respectively. For example, in <FIG>, the first or un-optimized hardware design <NUM> comprises a set of control flip-flops <NUM>; and the second or optimized hardware design <NUM> has fewer flip-flops <NUM>.

<FIG> illustrates various components of an exemplary computing-based device <NUM> which may be implemented as any form of a computing and/or electronic device, and in which embodiments of the systems, hardware monitors and methods described herein may be implemented.

Computing-based device <NUM> comprises one or more processors <NUM> which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to verify that an integrated circuit defined by a hardware design meets a power requirement. In some examples, for example where a system on a chip architecture is used, the processors <NUM> may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system <NUM> or any other suitable platform software may be provided at the computing-based device to enable application software (e.g. a formal verification tool <NUM>) to be executed on the device.

The computer executable instructions may be provided using any computer-readable media that is accessible by computing-based device <NUM>. Computer-readable media may include, for example, computer storage media such as memory <NUM> and communications media. Computer storage media (i.e. non-transitory machine readable media), such as memory <NUM>, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Although the computer storage media (i.e. non-transitory machine readable media, e.g. memory <NUM>) is shown within the computing-based device <NUM> it will be appreciated that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface <NUM>).

The computing-based device <NUM> also comprises an input/output controller <NUM> arranged to output display information to a display device <NUM> which may be separate from or integral to the computing-based device <NUM>. The display information may provide a graphical user interface. The input/output controller <NUM> is also arranged to receive and process input from one or more devices, such as a user input device <NUM> (e.g. a mouse or a keyboard). This user input may be used to create the hardware monitor <NUM>, scenario <NUM> and/or hardware design <NUM>. In an embodiment the display device <NUM> may also act as the user input device <NUM> if it is a touch sensitive display device. The input/output controller <NUM> may also output data to devices other than the display device, e.g. a locally connected printing device (not shown in <FIG>).

<FIG> shows an example of an integrated circuit (IC) manufacturing system <NUM> which comprises a layout processing system <NUM> and an integrated circuit generation system <NUM>. The IC manufacturing system <NUM> is configured to receive an IC definition dataset (e.g. a hardware design as described in any of the examples herein), process the IC definition dataset, and generate an IC according to the IC definition dataset. The processing of the IC definition dataset configures the IC manufacturing system <NUM> to manufacture an integrated circuit. More specifically, the layout processing system <NUM> is configured to receive and process the IC definition dataset to determine a circuit layout.

In other examples, processing of the integrated circuit definition dataset at an integrated circuit manufacturing system may configure the system to manufacture an integrated circuit without the IC definition dataset being processed so as to determine a circuit layout. For instance, an integrated circuit definition dataset may define the configuration of a reconfigurable processor, such as an FPGA, and the processing of that dataset may configure an IC manufacturing system to generate a reconfigurable processor having that defined configuration (e.g. by loading configuration data to the FPGA).

In some examples, an integrated circuit definition dataset could include software which runs on hardware defined by the dataset or in combination with hardware defined by the dataset.

The term 'processor' and 'computer' are used herein to refer to any device, or portion thereof, with processing capability such that it can execute instructions. The term 'processor' may, for example, include central processing units (CPUs), graphics processing units (GPUs or VPUs), physics processing units (PPUs), radio processing units (RPUs), digital signal processors (DSPs), general purpose processors (e.g. a general purpose GPU), microprocessors, any processing unit which is designed to accelerate tasks outside of a CPU, etc. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes set top boxes, media players, digital radios, PCs, servers, mobile telephones, personal digital assistants and many other devices.

Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

The methods described herein may be performed by a computer configured with software in machine readable form stored on a tangible storage medium e.g. in the form of a computer program comprising computer readable program code for configuring a computer to perform the constituent portions of described methods or in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable storage medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

The hardware components described herein may be generated by a non-transitory computer readable storage medium having encoded thereon computer readable program code.

It is also intended to encompass software which "describes" or defines the configuration of hardware that implements a module, functionality, component or logic described above, such as HDL (hardware description language) software, as is used for designing integrated circuits, or for configuring programmable chips, to carry out desired functions. That is, there may be provided a computer readable storage medium having encoded thereon computer readable program code for generating a processing unit configured to perform any of the methods described herein, or for generating a processing unit comprising any apparatus described herein. That is, a computer system may be configured to generate a representation of a digital circuit from definitions of circuit elements and data defining rules for combining those circuit elements, wherein a non-transitory computer readable storage medium may have stored thereon processor executable instructions that when executed at such a computer system, cause the computer system to generate a processing unit as described herein. For example, a non-transitory computer readable storage medium may have stored thereon computer readable instructions that, when processed at a computer system for generating a manifestation of an integrated circuit, cause the computer system to generate a manifestation of a processor of a receiver as described in the examples herein or to generate a manifestation of a processor configured to perform a method as described in the examples herein. The manifestation of a processor could be the processor itself, or a representation of the processor (e.g. a mask) which can be used to generate the processor.

Memories storing machine executable data for use in implementing disclosed aspects can be non-transitory media. Non-transitory media can be volatile or non-volatile. Examples of volatile non-transitory media include semiconductor-based memory, such as SRAM or DRAM. Examples of technologies that can be used to implement non-volatile memory include optical and magnetic memory technologies, flash memory, phase change memory, resistive RAM.

A particular reference to "logic" refers to structure that performs a function or functions. An example of logic includes circuitry that is arranged to perform those function(s). For example, such circuitry may include transistors and/or other hardware elements available in a manufacturing process. Such transistors and/or other elements may be used to form circuitry or structures that implement and/or contain memory, such as registers, flip flops, or latches, logical operators, such as Boolean operations, mathematical operators, such as adders, multipliers, or shifters, and interconnect, by way of example. Such elements may be provided as custom circuits or standard cell libraries, macros, or at other levels of abstraction. Such elements may be interconnected in a specific arrangement. Logic may include circuitry that is fixed function and circuitry can be programmed to perform a function or functions; such programming may be provided from a firmware or software update or control mechanism. Logic identified to perform one function may also include logic that implements a constituent function or sub-process. In an example, hardware logic has circuitry that implements a fixed function operation, or operations, state machine or process.

Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and an apparatus may contain additional blocks or elements and a method may contain additional operations or elements. Furthermore, the blocks, elements and operations are themselves not impliedly closed.

The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The arrows between boxes in the figures show one example sequence of method steps but are not intended to exclude other sequences or the performance of multiple steps in parallel. Where elements of the figures are shown connected by arrows, it will be appreciated that these arrows show just one example flow of communications (including data and control messages) between elements. The flow between elements may be in either direction or in both directions.

Claim 1:
A system (<NUM>) configured to verify that an integrated circuit defined by a first hardware design (<NUM>) meets a power requirement (<NUM>), the system (<NUM>) comprising:
a first hardware monitor (<NUM>) for the first hardware design (<NUM>);
a second hardware monitor (<NUM>) for a second hardware design (<NUM>);
wherein each of the first and second hardware monitors (<NUM>, <NUM>) comprises:
one or more transition detection logic units (<NUM>, <NUM>, <NUM>, <NUM>), the one or more transition detection logic units (<NUM>, <NUM>, <NUM>, <NUM>) configured to detect whether a power consuming transition has occurred with one or more flip-flops (<NUM>, <NUM>) of the respective hardware design (<NUM>, <NUM>); and
one or more counter update logic units (<NUM>, <NUM>) in communication with the one or more transition detection logic units (<NUM>, <NUM>, <NUM>, <NUM>), the one or more counter update logic units (<NUM>, <NUM>) configured to count a number of power consuming transitions detected by the one or more transition detection logic units (<NUM>, <NUM>, <NUM>, <NUM>);
wherein the first hardware monitor (<NUM>) further comprises a property verification logic unit (<NUM>, <NUM>, <NUM>) configured to determine whether the power requirement is met at a particular point in time by evaluating one or more properties based on the number of power consuming transitions counted by each of the one or more counter update logic units (<NUM>, <NUM>), wherein each of the one or more properties is written in an assertion language so that the property can be formally verified by a formal verification tool (<NUM>), the one or more properties comprising a property that compares the count of power consuming transitions for the first hardware design to the count of power consuming transitions for the second hardware design;
a scenario (<NUM>) defined in a formal verification language; and
the formal verification tool (<NUM>) configured to formally verify whether the integrated circuit defined by the first hardware design (<NUM>) meets the power requirement (<NUM>) for the scenario (<NUM>) using the first and second hardware monitors (<NUM>, <NUM>) and the one or more properties.