Abstract:
A power verification system requires a combination of design and its power intent. A power intent (PI) input specifies the power architecture of a design through specification of power/voltage domains, their corresponding power supplies and a collection of power management devices. Power state tables (PSTs) specified in PI capture the legal combinations of power states (voltage values) for the various sets of supply nets or supply ports of a design. A power verification system requires determining the power supply relationships of voltage/power domains which requires merging of PSTs. The system described efficiently merges PSTs by iteratively selecting only a subset of PSTs that are relevant to the supply pair of interest, that are pruned initially and as the merge progresses. This provides orders of magnitude speedup and resource reduction. A user interface allows display of identified power verification failures and may include an input device for facilitating correction of at least one of the electronic circuit design and the power intent file.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit under 35 U.S.C. 119(e) from prior U.S. provisional application No. 62/140,386 filed Mar. 30, 2015. 
     
    
     TECHNICAL FIELD 
       [0002]    This invention relates to the field of integrated circuits verification and in particular to verification of powers subsystems. 
       BACKGROUND ART 
       [0003]    Low power consumption in a Soc (System on Chip) is increasingly important. The designs of Socs incorporate many techniques to reduce power consumption. One technique is for the designer to use multiple voltage levels, since the voltage needs to be high only for high frequency modules of the SoC, and low voltage levels reduce power consumption. Modules of a Soc that have voltages powering them that are different from the voltages powering some other module to which they are connected are called Voltage Domains. Another technique to reduce power consumption is to turn power off completely from a module during the time that it does not need to be powered. Voltage domains one or more of whose supply voltages is dynamically turned ON/OFF are called Power Domains. Turning power OFF completely is becoming more effective compared to clock disabling as circuit design rules shrink and the leakage current increases compared to the switching current. These modern techniques along with others create new requirements in the Soc design. Some of these requirements are:
       A level shifter is needed between the output port of a module that is connected to the input port of another module whenever the two ports (that is, the logic connected to the two ports) are powered with a different voltage.   A register-state retention and restore circuit may be needed for critical registers of a module when the power to a module is removed.   Isolation circuits are needed following an output port of a module whose power is turned off (port floats) and the port is connected to an input port of a module that is powered.   Logic circuits for dynamically turning power on/off on some or all of the power ports of some or all the modules need to be added.       
 
         [0008]    A power verification tool needs to determine when such additional circuits are required and when they are not required. Power State Tables (PSTs) have key information that helps decipher this requirement. A global power state table contains different power supplies used in a SoC as columns, and all possible combinations of ON/OFF and other possible states (voltage values) that may occur during SoC operation as rows. Given a connection between an output port and an input port, and knowing which power supplies power these 2 ports, the power state table shows for example which of the ON/OFF combinations for the 2 power supplies can •occur, whether there are different voltage levels between the supplies, and therefore what additional circuitry if any is needed between the input and output ports. 
         [0009]    SoC developers normally specify the power architecture (definition of voltage/power domains, use of retention registers and more) in separate files from the logic design specification. The power architecture specification is usually called the “power intent” (PI) and is, expressed in languages like Unified Power Format (UPF); described in the IEEE Standard for Design and Verification of Low-Power Integrated Circuits. This IEEE standard establishes a format used to define the power intent for electronic systems and electronic intellectual property (IP) The format provides the ability to specify the power supply network, switches, isolation, retention, and other aspects relevant to power management of an electronic system. The standard defines the relationship between the power intent specification and the logic design specification captured via other formats [e.g., standard hardware description languages (HDLs)]. 
         [0010]    Electronic design automation (EDA) tools like Spyglass from the assignee verify the power architecture of an electronic design by comparing the power intent specification to the logic design and checking for coherence, correctness and the existence of necessary power-interface components. 
         [0011]    Traditional power verification systems create one large power state table containing all the power supplies of the SoC. As Socs increase in size and complexity, the number of power supplies and voltage domains increase and can become several scores in number, all so that power consumption can be kept down. But this causes an explosion in the size of the power state table (PST), the time needed to create it, and the resources needed to store it. 
         [0012]    As Soc designs continue to grow in terms of complexity and number of transistors, the verification times increase and the memory requirements of the EDA tools grow. Power verification is one of the last development activities before tape-out, so SoC developers are under pressure to complete it quickly. Soc developers would benefit greatly if the verification time could be reduced from days to hours. 
       SUMMARY DISCLOSURE 
       [0013]    The Efficient Power Verification System (EPVS) infers relationships between power supplies in a Soc that has more than one voltage or power domain. A power intent (PI) input specifies the power architecture of a design through the specification of power domains, supply networks and through a collection of devices such as isolation logic, level shifters, retention registers, and power switches. Power state tables (PSTs) capture the legal combinations of power states for the various sets of supply nets or supply ports of a design. To determine power supply relationships, the EPVS efficiently merges PSTs by iteratively selecting only a subset of PSTs that are reduced in size. This merging involves a sanitization step to remove any inconsistent power state in the design. After considering power supplies whose relationship need to be scrutinized, the EPVS finds a subset of PSTs that may need to be merged in order to determine their relationships. PSTs may be repeatedly merged two at a time starting by selecting the two PSTs that have the greatest number of power supplies in common. When a pair of PSTs is merged, their rows and columns are pruned to retain only the most relevant information. The process results in an overall merged PST that is small in size and quick to construct. The supply pair relationship is retrieved by examining the merged PST; a key aspect of the power verification system. 
         [0014]    The overall process entails choosing only a subset of PSTs that are relevant to the supply pair at hand, which are pruned initially and as the merge progresses. Accordingly, the EPVS provides orders of magnitude speedup and resource reduction. The speedup facilitates an interactive human interface for querying the EPVS about the power supply relationships it has determined, e.g., allowing a user to view one or more PSTs at a user-specified hierarchical scope and to view port states of a user-specified port at a user-specified scope. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0015]      FIG. 1  shows a flowchart of the steps used by the EPVS for creating a PST. 
           [0016]      FIG. 2A  shows a flowchart of the sanitization step of the EPVS. 
           [0017]      FIG. 2B  shows a flowchart of the “Selective PST Mergen. 
           [0018]      FIG. 3A  shows an example of a scope tree of the modules and submodules of a Soc. 
           [0019]      FIGS. 3B, 3C, and 3D  show a small example of the sanitization step. 
           [0020]      FIG. 4A  shows an example of 4 PSTs being merged to produce a combined PST using a previous method of PST merging. This is contrasted with the EPVS approach using selective PST merging in  FIGS. 4B, 4C, 4D, and 4E . 
           [0021]      FIGS. 5A and 5B  show an example circuit and its corresponding power intent, which is then used to illustrate the EPVS. 
           [0022]      FIGS. 6A, 6B, 6C, 6D, and 6E  show key merging steps to find the power relationship between two switched supplies of instances inst 1  and inst 2  of the example circuit in  FIG. 5 . The final merged PST shows that isolation circuits are needed for any connect between portions of inst 1  and inst 2  that are powered by switched supplies. 
           [0023]      FIG. 7  shows a system for efficient power verification. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    The Efficient Power Verification System (EPVS) verifies the power implementation of an electronic design by efficiently deriving relationships between power supplies. The EPVS accepts as inputs a Power Intent written using a format such as Unified Power Format 
         [0025]    (UPF), and a circuit design provided in a netlist or written in a hardware description language such as RTL (such as Verilog). The EPVS can accept queries via a GUI widget and can provide determination of power relationships interactively in real-time. 
         [0026]    A Soc may have many independent modules, each powered by several different power supplies, many of which are common to more than one module. The EPVS determines the power supplies for each module, and all allowed combinations of ON/OFF an possibly other states (voltage values) for the power supplies of each module. This information is represented by a power state table for the module (PST). A PST has a column for each of the different power supplies powering the module. Each entry in the PST is ON or OFF or some other value such as SLEEP, ACTIVE, IDLE etc., each of which corresponds to a specific voltage value. Each row in the PST represents an allowed combination of states (ON/OFF or other values) for the supplies powering the module. 
         [0027]    A Soc PST is a table with columns for all the voltages powering all the modules of the SoC, and rows for all the allowed combinations of states. Previous power verification systems created it from the individual module PSTs by repeatedly merging two PSTs, and merging the resulting PST with one of the unmerged PSTs. Many merges of increasing complexity are needed in general. From such a merged table all the power circuit requirements for all module interconnects can be readily derived at the Soc level. However, the typical PST finally obtained is extremely large, and constructing it requires many repetitive and tedious steps. 
         [0028]    A typical power verification system uses the information extracted from the Soc PST to analyze 2 voltage supplies at a time that power a particular output/input port pair of modules that are interconnected. All information needed can be obtained from the one Soc PST for all voltage pairs, but the EPVS obtains the same information far more efficiently. 
         [0029]      FIG. 1  is an exemplary and non-limiting flowchart  100 . Flowchart  100  shows the steps for efficient determination of SoC power supply relationships. 
         [0030]    In step S 110  the EPVS reads the design and power intent. 
         [0031]    In step S 120  the EPVS removes inconsistent power states in the PSTs of the design, a process called sanitization that is described in detail in  FIG. 2   a.    
         [0032]    In step S 130  the EPVS performs selective PST merging. Selective PST merging is the process in which the EPVS finds the relationship between two supplies by merging a relevant subset of the PSTs. This step is repeated for all supply pairs of interest. This is elaborated in  FIG. 2   b.    
         [0033]      FIG. 2 a    is an exemplary and non-limiting flowchart S 120 . Flowchart  120  shows the sanitization step that flags and removes inconsistent power states in the design. An example is a module whose power intent includes a state (e.g. ON or OFF) that is not specified in the power intent of another module that uses the same power supply. 
         [0034]    In step S 121  the EVPS creates a scope tree with the root node being the top scope, i.e. the Soc. The modules of the Soc are naturally organized in a hierarchy since every modules is a submodule either of a higher level module or of the Soc. 
         [0035]    In step S 122  the EVPS does a post order traversal (child first, parent next) of the scope tree. 
         [0036]    In step S 123  at every scope, the EVPS does the following: 
         [0037]    1. Creates a list of all the PSTs defined in that scope. 
         [0038]    2. For every pair of PSTs:
       a. Finds the common supplies.   b. Finds and keeps the unique power states for the common supplies.   c. Removes any power states that are present in only one PST.       
 
         [0042]    3. If there is a PST list of child scope, then adds PSTs from those lists to the current PST list. Go to step 2. 
         [0043]    4. Save this consolidated PST list at this scope. 
         [0044]    At the end, PST at each scope is replaced by the sanitized version of it. This step leads to an overall reduction in the size of the PSTs at hand. By removing inconsistent power states of the PSTs of the design. 
         [0045]      FIG. 3 a    is an exemplary and non-limiting diagram  300  showing the scope relationships between voltage domains in a SoC. 
         [0046]    Box  310  is a representation of the nested hierarchical relationships between the Soc  310  and 4 modules labeled Inst 1   320 , Inst 2   321 , Inst 3   322 , and Inst 4   323 . Inst 3   322  is a module contained in module Inst 1   320  which is contained in the top level in the Soc  310 . Inst 4   323  is a module contained in module Inst 2   321  which is contained in the top level in the SoC  310 . 
         [0047]    Tree  305  is a representation of the derived scope tree representing the nesting of the modules. Sanitization is done by traversing the tree post order, child first. The tree is traversed as follows:
       In Node  322 : Sanitize PST at Inst 3 .   In Node  320 : Sanitize PST at Inst 1 , bring list of PSTs from child scope at this level and sanitize.   In Node  323 : Sanitize PST at Inst 4 .   In Node  321 : Sanitize PST at Inst 2 , bring list of PSTs from child scope at this level and sanitize.   In Root  310 : Sanitize PST at Top scope, bring list of PSTs from child scope at this level and sanitize. The final list contains all the PST in the design       
 
         [0053]      FIG. 3 b    shows two PSTs, PST  330  and PST  331  that are to be pairwise sanitized. 
         [0054]      FIG. 3 c    shows PST  340  and PST  341 , the unique power states having only common supplies VDDA and VSS of PST  330  and PST  331 . 
         [0055]    State ON 2  in PST  340  is not present in PST  341 , so the EPVS will remove this state. 
         [0056]      FIG. 3 d    shows PST  350  and PST  351 , which are PST  330  and PST  331  after removal of the inconsistent states. In this example, PST  330  has had the state with ON 2  removed, while PST  331  is unchanged. 
         [0057]      FIG. 2 b    is an exemplary and non-limiting flowchart of  8130 . Flowchart S 130  shows the selective PST merging that is done for every supply pair whose relationship needs to be determined. The relationship between the supply pair helps determine if isolation, level-shifting or other circuit additions are needed between the modules—a key aspect of the power verification. 
         [0058]    Step S 131  first clearly establishes the two supplies whose relationship needs to be scrutinized. 
         [0059]    Step S 132  determines if the two supplies are related or not using the following steps. The broad approach is to start with one of the supplies (Supply A) and see if the other supply (Supply B) can be reached through a set of PSTs. 
         [0060]    A. Create a supply list S and add the first supply (Supply A) to it. 
         [0061]    B. Loop through all supplies in the supply list S (adding new supplies along the way)
       a. For each supply ‘sup’ in list S do the following: (This step handles the next supply, which has not been processed yet)
           i. Find the list of PSTs (list P′) in which supply ‘sup’ exists   ii. Add all the supplies present in PSTs of list P′ to list S   iii. If the second supply (Supply B) exists in list S, this means the two supplies A and B are related. Return true, and exit from the loop. Go to the next step—Step  133 .   iv. Mark the presently processed supply ‘sup’ as processed/visited   
           b. Since the second supply was never added to supply list S, this means the two supplies are not related.       
 
         [0068]    Step  133  builds the merged PST of unrelated supply pairs. If there is no relationship between the two supplies (checked in step  132 ), then take all the possible combinations of port states of the two supplies used in their PSTs to build the merged PST. 
         [0069]    Step S 134  is to identify a relevant PST list of related supply pairs. This is done as follows. If there exists a relationship between the two supplies then identify the list of PSTs that need to be merged in order to find the relationship, using the following steps:
       a. Find a list of all PSTs which have one or both the candidate supplies (list A).   b. Create a unique list of extra supplies (Supply list S) that are part of the list A PSTs. Find all additional PSTs with these extra supplies. Call this list of PSTs list B.   c. Take the union of list A and list B into list A   d. Check if new PSTs are added in list A after step c. If yes go to step b. Otherwise exit, as we have identified the PST list to be merged; return this list—list A.       
 
         [0074]    In step S 135  all relevant PSTs identified in the previous step  134  are merged. The EPVS repeatedly merges two PSTs at a time, ultimately to build one final Merged State Table (MST). In this step the EPVS tries to keep the size of the merged PST minimal after every merge, for best performance. Details of the step are as follows: 
         [0075]    1. Review the List of PSTs to be merged (list A from the previous step S 134 ). Merge two PSTs at a time, by selecting the two PSTs that have the most number of common supplies. This helps in keeping the size of merged PST minimal at every step.
       a. The merging for each pair of PSTs is as follows:
           i. Find the common supplies in the 2 PSTs.   ii. Find unique power states (rows) having only the common supplies.   iii. On the basis of common power states, find the port states (column values) of uncommon supplies in the respective PST. That is, for each common power state (partial row of a PST), find the port state combinations of uncommon supplies in the respective PST.   iv. Create combinations of port state values for uncommon supplies corresponding to every common power state.   v. The states created in step d comprise the merged PST.   
           b. During merging, remove the supplies that are present only in one PST among the set of PSTs chosen for merge. However do not remove the supply whose relationship you wish to identify.   c. After every merging step, remove any power states that are identical.       
 
         [0084]    Step S 136  is the final step, where based on the merged PST, also known as the Merged State Table (MST), the relationship between the pair of supplies is determined. 
         [0085]    To find the power relationship between any two supplies the previous non-selective PST merge approach merges all PSTs in the design to create a system level MST. It then examines the large MST to look for the relationship between the supplies (columns in MST). 
         [0086]      FIG. 4 a    is an exemplary and non-limiting diagram. Diagram  400  shows the non-selective merging of several PSTs to produce a merged PST. 
         [0087]    PST  410 , PST  420 , PST  430 , PST  440  are merged, producing the merged PST  450 . To find the relationship between say two supplies VDDA and VDDB one has to examine the large merged PST  450 . For instance, one can safely ascertain that there is no need for isolation logic between VDDA and VDDB as they are either both ON or both OFF at the same time. 
         [0088]    The selective PST merging of EPVS follows a different approach. To find the relationship between VDDA and VDDB the merging is done as follows: 
         [0089]    Step 1: Consider VDDA &amp; VDDB as the supplies whose relationship needs to be identified. PST 1 , PST 2 , PST 3 , PST 4  refer to PSTs in the  FIG. 4 a    namely  410 ,  430 ,  420 ,  440 . 
         [0090]    Step 2: Check if VDDA and VDDB are related or not.
       i. Create a supply list S having VDDA;   ii. Iteration 1:
           1. Take the first supply in S i.e. VDDA;   2. Create list of PSTs in which VDDA exists P′=[PST 1 ];   3. Identify the supplies in PSTs of list P′=[VDDA, VDDD, VDDX];   4. Update supply List S=[VDDA, VDDD, VDDX];   5. Supply VDDB does not exist in list S   
           iii. Iteration 2:
           1. Take second supply in S which is VDDD;   2. Create list of PSTs in which VDDD is present P′=[PST 1 , PST 3 ];   3. Identify the supplies in PSTs of P′=[VDDA, VDDD, VDDX, VDDC];   4. Update supply list S=[VDDA, VDDD, VDDX, VDDC];   5. VDDB does not exist in list S   
           iv. Iteration 3:
           1. Take next supply in S which is VDDX;   2. Create list of PSTs in which VDDX is present P′=[PST 1 ];   3. Identify the supplies in PSTs of P′ [VDDA, VDDD, VDDX];   4. Update supply list S=[VDDA, VDDD, VDDX, VDDC];   5. VDDB does not exist in list S   
           v. Iteration 4:
           1. Take next supply in S i.e. VDDC;   2. Create list of PSTs in which VDDC is present P′=[PST 2 , PST 3 ];   3. Identify supplies in PST of P=[VDDA, VDDC, VDDB, VDDE];   4. Update supply list S=[VDDA, VDDD, VDDX, VDDC, VDDB, VDDE];   5. VDDB exists in S which means a power relationship can be found between VDDA and VDDB by merging PSTs   
               
 
         [0116]    Step 3: It has been established that VDDA, VDDB are related (so there is no need to process as though unrelated). 
         [0117]    Step 4: Identify PSTs that need to be merged
       i. Iteration 1:
           1. Make a list of PSTs in which either of the two supplies are present; list A=[PST 1 , PST 2 ];   2. The supply list S contains [VDDA, VDDD, VDDX, VDDC, VDDB, VDDE];   3. Find the list of additional PSTs corresponding to extra supplies in supply list S;   4. This is list B=[PST 3 ];   5. Make a union of list A and list B, updating list A=[PST 1 , PST 2 , PST 3 ];   
           ii. Iteration 2:
           1. List A=[PST 1 , PST 2 , PST 3 ];   2. The supply list S contains [VDDA, VDDD, VDDX, VDDC, VDDB, VDDE];   3. Find the list of additional PSTs corresponding to extra supplies of supply list S;   4. This is List B=[ ];   5. Make a union of list A and list B, updating List A=[PST 1 , PST 2 , PST 3 ];   6. No new PSTs are added in list A. This means list A contains all the PSTs that need to be merged to find the relationship between the supplies at hand.   
               
 
         [0131]      FIG. 4 b    shows the selective merging of PSTs—PST 1 , PST 2 , and PST 3  (PST  410 ,  430 ,  420  respectively in  FIG. 4 a   ). The order of merging is chosen so that the PSTs with the largest number of common supplies are merged first. 
         [0132]    Combination PST 1  and PST 2  have 0 common supplies. 
         [0133]    Combination PST 1  and PST 3  have 1 common supplies. 
         [0134]    Combination PST 2  and PST 3  have 1 common supplies. 
         [0135]    So start the merging with PST 1   460  and PST 3   461 . 
         [0136]      FIG. 4 c    shows the merging of PST 1  and PST 3 . Supply VDDX is discarded as it is present in only one PST (PST 1 ), producing PST 1 +PST 3 , that is, PST  470 . 
         [0137]      FIG. 4 d    shows the merging of PST 1 +PST 3   480  and PST 2   481 . Supply VDDE is discarded as it is present only in PST 2 . 
         [0138]      FIG. 4 e    shows the final merged PST  490 . 
         [0139]    The final merged PST (MST) with the selective merging of PSTs is a considerably smaller table which establishes the relationship between the supplies VDDA and VDDB, which was the original supply relationship that was being sought. 
         [0140]      FIG. 5  is an exemplary and non-limiting diagram showing an example of a circuit design Sa on the left and the power intent of that circuit Sb on the right. 
         [0141]    Power Switched Circuits in  FIG. 5 a   ,  510 ,  511 ,  512 ,  513  are identical circuits Inst 1 , Inst 2 , Inst 3 , Inst 4 , connected together. They switch voltage VDD on and off for each module. 
         [0142]    The Power Intent View of circuit Sa is shown in  FIG. 5 b   . The power intent is expressed using a language such as the Unified Power Format (UPF) language. The power intent view shows the same four modules and their power connectivity. Inst 1   510  is connected to power supply VDD  520 , and VSS  523 . Inst 2   511 , Inst 3   512  and Inst 4   513  are similarly connected. The top level of the SoC is connected to power supplies VDD  520 , VDDA  521 , VDDB  522  and VSS  523 . VDDg  524  is the switched output of VDD inside Inst 1 . 
         [0143]      FIG. 6  is an exemplary and non-limiting diagram that shows stages of the application of EPVS to the design and power intent of  FIG. 5 . EPVS here analyzes the power relationship of interconnected ports one of which is powered by switched-output of Inst 1 (Inst 1 /Vddg) and the other by switched output of Inst 2 (Inst 2 /Vddg) power supplies. 
         [0144]    PST  610  shows the PST of the top module. PST  611  shows the PST of the 4 modules Inst 1 , Inst 2 , Inst 3  and Inst 4  (all 4 modules have identical PSTs in this example). Top level supply VDD is connected to Inst 1 /VDD, Inst 2 /VDD, Inst 3 /VDD and Inst 4 /VDD. Top level supply VSS is connected to Inst 1 /VSS, Inst 2 /VSS, Inst 3 /VSS and Inst 4 /VSS. VDDg is the gated output from each switch with input supply VDD. 
         [0145]      FIG. 6 b    shows the scope tree corresponding to the circuit arid power intent of the example. It shows the top module  620  and the 4 modules Inst 1   621 , Inst 2   622 , Inst 3   623 , and Inst 4   624  as children on independent branches. Inst 1   621 , Inst 2   622 , Inst 3   623 , and Inst 4   624  all have 1 PST each. Since there are no child scopes for these, no sanitization is required at these scopes. 
         [0146]    At the top scope, there is only one PST. Bring the PST list from first child viz. Inst 1  to this level. 
         [0147]    The top scope now consists of 2 PSTs—/PST and Inst 1 /PST. Do sanitization as follows:
       1. Identify the common supplies: VDD and VSS.   2. Create a table with all unique power states of common supplies.       
 
         [0150]      FIG. 6 a    shows the top PST  610  and Inst 1 /PST  611  at this point:
       3. There is no power state that is present in only one PST. So there is no need to remove any state, from either of the PSTs.   4. Take the PST list of the next child—Inst 2     5. The Top scope will now have 3 PSTs [/PST, Inst 1 /PST, Inst 2 /PST].   6. Again sanitization will not remove any states.   7. Repeat the above steps till all the PSTs are at the Top scope.   8. At the end, the Top scope will have all 5 PSTs: [/PST, Inst 1 /PST, Inst 2 /PST, Inst 3 /PST, Ins 4 /PST]       
 
         [0157]    Selective merging is now done:
       i. Find the relationship between Inst 1 /VDDg and Inst 2 /VDDg;   ii. Based on the steps described, the PST list will contain all the 5 PSTs;   iii. All the PSTs have 2 supplies in common, so we can start from any 2 PSTs;   iv. Merge Inst 3 /PST and Inst 4 /PST;   v. Identify the common supplies: VDD and VSS;   vi. While merging remove supplies Inst 3 /VDDg and Inst 4 /VDDg as they exist in only 1 PST each. After merging remove any duplicate power states, resulting in the merged PST  635  in  FIG. 6 c     2 ;   vii. Merge [Inst 3 /PST+Inst 4 /PST] with Ipst 2 /PST;   viii. Identify the common supplies: VDD and VSS;   ix. While merging we cannot remove Inst 2 /VDDg although this exists in only one PST, since this is the supply for which we need to find the solution.       
 
         [0167]    PST  640  shows the PST after merging the PSTs of Inst 2 , Inst 3  and Inst 4 . Continue with selective merging:
       i. Merge [Inst 2 /PST+Inst 3 /PST+Inst 4 /PST] with Inst 1 /PST;   ii. Merge [Inst 1 /PST+Inst 2 /PST+Inst 3 /PST+Inst 4 /PST] with the Top PST;   iii. Identify common supplies: VDD and VSS;   iv. While merging, remove supplies VDDA and VDDB.       
 
         [0172]    PST  650  shows the final PST for Inst 1  and Inst 2  powered ports. Since there is a row where Inst 1  is ON and Instant 2  is OFF, and there is a row where Inst 1  is OFF and Instant 2  is ON, isolation circuits {for example) are needed for all interconnects between ports one of which is powered from Inst 1  and one of which is powered from Inst 2 . This illustrates how to find relationship between specific supplies of interest. 
         [0173]    The embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. 
         [0174]      FIG. 7  is an exemplary and non-limiting diagram  700  showing the EPVS. 
         [0175]    Design  710  contains electronic circuit module hierarchy information, module ports and interconnects. The design  710  is written in a language such as RTL (Verilog), or is provided as a netlist. The design  710  is typically stored as a file on a storage medium. 
         [0176]    EPVS  720  reads the Soc Circuit  710  and the Power Intent  730  and produces the Power Verification report  760 . During the RTL design phase EPVS  720  reads the design in RTL format and during the logic implementation phase EPVS  720  reads the design in netlist format. In one embodiment the EPVS  720  is a standalone software application running on a computer. In one embodiment the EPVS  720  is a component within an EDA tool. 
         [0177]    Power Intent  730  describes the power supplies and power architecture for each of the modules in the SoC. The power intent  730  is described in a language such as UPF (Unified Power Format) language. The power intent  730  is typically stored as a file on a storage medium. 
         [0178]    Device  740  and Device  750  are input and output devices for manually controlling the EPVS  720  and viewing the results the EPVS  720  produces. Input devices can be a keyboard and mouse, and output devices can be a video display and printer. The EPVS  720  supports an interactive mode where it accepts specific power-related queries and provides timely and relevant results. Designers request power information about specified supplies, ports, scopes or nets. The EPVS generates the following:
       i. Error messages during the sanitization step, when an incomplete power intent is input to the EPVS;   ii. A viewer of the PSTs provided in the UPF input;   iii. A viewer of a port (voltage supply) state, showing the port name, state and voltage value in any scope;   iv. A viewer of the isolation, level-shifter and hierarchical relationships between two supplies.       
 
         [0183]    Power verification report  760  lists power verification failures. The EPVS  720  displays the Power verification report  760  on the video device, and stores it as a file on a storage media.