System and method for hierarchical power verification
Abstract
A hierarchical power verification system and method creates abstract models of power behavior of modules that it successfully verifies. The abstract models simplify the module definition by omitting internal module details but provide sufficient information for power verification of higher level modules that incorporate this abstracted module. Design blocks are replaced with these abstract power models, resulting in reduced run-time and memory requirements. The power models can include power switches inside the block, related supplies of logic ports, supply power states, system power states, power management devices such as isolation logic and level shifters, feed-through and floating ports. The power model may be expressed either in UPF or as a combination of liberty model and UPF. After replacing modules with abstracted models the HPVS can quickly verify an entire SoC with a small memory footprint. When a user modifies a module, the HPVS need only verify the changed module and related modules at higher levels of module hierarchy.
Claims
exact text as granted — not AI-modifiedWhat is claimed is:
1 . A method implemented for a hierarchical power verification tool in a computing system for constructing and using abstract models of power behavior of circuit modules in a high level power verification of an electronic circuit design, the method comprising:
receiving, and storing in a storage medium accessible to a processor, (a) a description of at least a portion of an electronic circuit design, and (b) a power intent file that specifies a power architecture of power/voltage domains, their power supplies and any corresponding power devices of the electronic circuit design; creating, by the processor, from the stored design description and power intent file, a set of abstract models for verified circuit modules by performing in any order one or more of: (1) capture interface supplies, (2) create power domains, (3) identify related supplies, (4) establish power state tables, (5) model isolation logic, (6) model level shifters, (7) model feed-through floating ports, and (8) model power switches; successively reading a corresponding abstract model for each lower-level module referenced by a circuit module to be verified, and performing, by the processor, a power verification of each module using its lower-level abstract models; and displaying on a computer display any errors identified by the power verification, and using an input device to facilitate correction and storage of at least one of the electronic circuit design and the power intent file.
2 . The method as in claim 1 , wherein the method receives one or more of a) a list of circuit modules to be verified, and b) a list of circuit modules to be abstracted.
3 . The method as in claim 1 , wherein circuit modules to be verified comprise only a) those modules in the electronic circuit design that have been updated since a previous power verification, and b) any modules that reference those modified modules.
4 . The method as in claim 1 , wherein abstract models of power behavior are constructed for all circuit modules in the electronic circuit design.
5 . The method as in claim 1 , wherein abstract models of power behavior are constructed only for those circuit modules that have been updated since a previous construction of abstract models for such modules.
6 . The method as in claim 1 , wherein abstract models are represented in any one or more of: (a) liberty files with auxiliary attributes, including power state tables, being specified in a power specification language, or (b) a full power-specification-language based file.
7 . The method as in claim 1 , wherein capturing interface supplies is performed by identifying supply ports or pins, generating port states for each supply port, voltage map for supply pins, and creating supply nets.
8 . The method as in claim 1 , wherein creating power domains includes specifying a top domain and specifying key supply nets for the top domain.
9 . The method as in claim 1 , wherein identifying related supplies is performed by a depth first traversal from a top level interface port, skipping all nested domain boundary ports that do not have a level shifter strategy specified; if the destination is a leaf cell, setting the related supply as that powering the leaf cell; and if the destination is a nested domain boundary port having a level shifter strategy, setting the related supplies as those supplying that boundary port's level shifter on input and output sides.
10 . The method as in claim 1 , wherein establishing power state tables only contains supplies generated during the identification of related supplies.
11 . The method as in claim 10 , wherein the power state tables are merged for each complete module.
12 . The method as in claim 1 , wherein modeling isolation logic entails specifying isolation strategies, attributes at the logic port for isolation present at top level logic ports, or both; for isolation present at nested domain boundary ports, modeling performed by: a depth first traversal from a top-level logic port, skipping every nested domain boundary port that has neither level shifter nor isolation strategy specified; if a nested domain boundary port is found with a level shifter strategy than moving onto a next logic port; and if a nested domain boundary port is found with isolation strategy specified, then setting an isolated attribute for that port to true.
13 . The method as in claim 1 , wherein modeling level shifters is performed for each top level logic port having a level strategy specified.
14 . The method as in claim 1 , wherein modeling feed-through and floating ports is performed by a backward depth first traversal, skipping nested domain boundary ports that have neither level shifter nor isolation strategy specified; if a destination is not an interface port, then doing nothing; if a destination is an interface input port with level shifter or isolation strategy specified on any port in the traversal path, then doing nothing; otherwise set interface input port attribute function as feedthrough; and if a port is not connected to a net, then creating a corresponding pin and setting related supplies to the primary supply of its power domain.
15 . The method as in claim 1 , wherein modeling power switches includes specifying input supply port, output supply port and switch control port; together with specifying the port states of the output supply port; and is done only when an interface port has a related supply which is the output of a power switch.
16 . A power verification system, comprising:
a storage medium for receiving and storing a description of at least a portion of an electronic circuit design, and for receiving and storing a power intent file specifying a power architecture of power/voltage domains, their power supplies and any corresponding power devices of the electronic circuit design, and also for storing a report of power verification failures; a processor having access to the storage medium and executing an application program for a hierarchical power verification tool that constructs, from the stored design description and power intent file, a set of abstract models of power behavior of circuit modules for use in high level power verification of an electronic circuit design; and a user interface including a computer display for displaying identified power verification failures and an input device for facilitating correction of at least one of the electronic circuit design and the power intent file; wherein the processor executing the application program (a) creates abstract models for verified circuit modules by performing in any order one or more of: (1) capture interface supplies, (2) create domains, (3) identify related supplies, (4) establish power state tables, (5) model isolation logic, (6) model level shifters, (7) model feed-through floating ports, and (8) model power switches; (b) successively reads a corresponding abstract model for each lower-level module referenced by a circuit module to be verified, and performs a power verification of each module using, its lower-level abstract models; (c) displays, on a computer display, any errors identified by the power verification; and (d) facilitates, using an input device, correction and storage of at least one of the electronic circuit design and the power intent file.
17 . The system as in claim 16 , wherein the processor creates abstract models and performs a power verification for circuit modules identified in a received list of modules.
18 . The system as in claim 16 , wherein circuit modules to be verified comprise only (a) those modules in the electronic circuit design that have been updated since a previous power verification, and (b) any modules that reference those modified modules.
19 . The system as in claim 16 , wherein abstract models of power behavior are constructed for all circuit modules in the electronic circuit design.
20 . The system as in claim 16 , wherein abstract models of power behavior are constructed only for those circuit modules that have been updated since a previous construction of abstract models for such modules.
21 . The system as in claim 16 , wherein abstract models are represented in any one or more of: (a) liberty files with auxiliary attributes, including power state tables, being specified in a power specification language, or (b) a full power-specification-language based file.
22 . The system as in claim 16 , wherein capturing interface supplies is performed by identifying supply ports or pins, generating port states for each supply port, voltage map for supply pins, and creating supply nets.
23 . The system as in claim 16 , wherein creating power domains includes specifying a top domain and specifying key supply nets for the top domain.
24 . The system as in claim 16 , wherein identifying related supplies is performed by a depth first traversal from a top level interface port, skipping all nested domain boundary ports that do not have a level shifter strategy specified; if the destination is a leaf cell, setting the related supply as that powering the leaf cell; and if the destination is a nested domain boundary port having a level shifter strategy, setting the related supplies as those supplying that boundary port's level shifter on input and output sides.
25 . The system as in claim 16 , wherein establishing power state tables only contains supplies generated during the identification of related supplies.
26 . The system as in claim 25 , wherein the power state tables are merged for each complete module.
27 . The system as in claim 16 , wherein modeling isolation logic entails specifying isolation strategies, attributes at the logic port for isolation present at top level logic ports, or both; for isolation present at nested domain boundary ports, modeling performed by: a depth first traversal from a top-level logic port, skipping every nested domain boundary port that has neither level shifter nor isolation strategy specified; if a nested domain boundary port is found with a level shifter strategy than moving onto a next logic port; and if a nested domain boundary port is found with isolation strategy specified, then setting an isolated attribute for that port to true.
28 . The system as in claim 16 , wherein modeling level shifters is performed for each top level logic port having a level strategy specified.
29 . The system as in claim 16 , wherein modeling feed-through and floating ports is performed by a backward depth first traversal, skipping nested domain boundary ports that have neither level shifter nor isolation strategy specified; if a destination is not an interface port, then doing nothing; if a destination is an interface input port with level shifter or isolation strategy specified on any port in the traversal path, then doing nothing; otherwise set interface input port attribute function as feedthrough; and if a port is not connected to a net, then creating a corresponding pin and setting related supplies to the primary supply of its power domain.
30 . The system as in claim 16 , wherein modeling power switches includes specifying input supply port, output supply port and switch control port; together with specifying the port states of the output supply port; and is done only when an interface port has a related supply which is the output of a power switch.Join the waitlist — get patent alerts
Track US2017011138A1 — get alerts on status changes and closely related new filings.
We store only your email — no account needed. See our privacy policy.