Power Aware Dynamic Simulation Coverage

Abstract

Coverage provides meaningful insight into design verification completeness. The coverage metric in dynamic simulation is a system or standard of measurement used to describe the degree to which the design is exercised with certain design parameters for a particular test-suite or test-plan execution. Even the test-plan is subject to measurement using a weighted metric and recapitulated to contribute to the total resultant coverage metric.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Coverage provides meaningful insight into design verification completeness. The coverage metric in dynamic simulation is a system or standard of measurement used to describe the degree to which the design is exercised with certain design parameters for a particular test-suite or test-plan execution. Even the test-plan is subject to measurement using a weighted metric and recapitulated to contribute to the total resultant coverage metric. The design and verification parameters that contribute to the combined coverage metric in non-PA simulation is summarized as follows:

FormalPara List 6.1 Design and Verification Parameters Contributing to Non-PA Coverage Metrics

• Code coverage (this includes branch, condition, expression, statement, and toggle coverage information)

• Finite State Machine (FSM) coverage

• SystemVerilog covergroup coverage

• SystemVerilog and PSL assertion coverage

• Assertion data (including immediate and concurrent assertions, pass, non-vacuous pass, fail, attempt, and other counts)

• Formal analysis results based on different properties

• Verification Plan data

• Links between the Verification Plan and coverage data

• User-defined data

• Test data

Hence, it is comprehensive in the sense that the coverage is a combination of collection, analysis, and reporting (in general, a coverage computation model) of diversified design and verification parameters. Often the resultant metrics from such diversified parameters are stored in a common and unified coverage database (UCDB) for analytical and result representation purposes. UCDB provides accessibility to further enhance coverage metrics with new coverage results from different new sources through coverage merging, as well as a mechanism to analyze and generate the coverage reports through an API. Unfortunately Unified Coverage Interoperability (UCIS) Standard Version 1.0 does not provide any format or extensions for power aware coverage computation models. Apparently the standard is not enhanced to include the covergroup modeling of PA metrics (discussed in Sect. 3.1). However, UCDB provides the mechanism to merge PA and non-PA coverage metrics to contribute towards 100 percent design verification closure.

6.1 PA Dynamic Simulation: Coverage Fundamentals

Now obviously PA-SIM verification environment coverage metrics are power-related and recapitulate on the non-PA coverage results in the UCDB, as discussed above. The power-related coverage metric originates broadly from the following PA verification perspective.

List 6.2 Primary Source of PA Coverage Metrics

• 1. Coverage information from PA Dynamic Checks based on:

  • PA testbench (Code Coverage),

  • Automated PA Sequence Checkers,

  • Custom PA Checkers.

• 2. Coverage information from power-states and power-state-transitions

  • States and their transitions for power domains, supply sets, ports, power state tables, ISO, RFF, PSW Control and Acknowledgement signals.

However similar to UCIS, UPF also does not provide any semantics or standard guidelines for PA coverage computation models. Moreover, in the power aware dynamic simulation state space, the UPF power states have the following unique but very contradictory features with respect to traditional coverage computation models; for example, the finite state machine state transition mechanism.

List 6.3 Contradiction of PA vs. Non PA State Transition Mechanism

• Power state and transitions are asynchronous in nature,

• More than one power state can be true at a time,

• A state may be marked as illegal any time by user,

• Power states of any UPF object may refer to the power states of other UPF objects.

While the coverage collection, analysis, and reporting for PA dynamic checks originating from a PA testbench and different dynamic assertions are very straight forward; however, due to the above listed contradictions, the coverage information extraction from power-states and their transitions requires an exhaustive process. Because the characteristics of a power-state can be best summarized in the following categories.

List 6.4 Characteristics of Power States

• Power states are abstract at higher-levels and physical (supply port and nets) at lower-levels of design abstraction,

• They are applicable for different UPF objects that include rudimentary parts of supply networks and design elements; e.g. power supplies, power domains, design groups, design models, and design instances,

• Power states may reference descendant power-domains or power supply states from the scope of top domains,

• Power states denote different operation modes based on different combinations of power-domains and their power-supplies,

• They are subject to interdependency between different UPF objects; e.g. power domain and supply set

• It is possible that power states may be exposed to simultaneous state transitions between interdependent objects.

Hence, from the above lists at first it is required to apprehend all possible sources of state and transitions for PA coverage metric modeling. Regardless of UPF versions and releases, it is distinctive that the power states and their transition state machines in a PA-SIM environment can originate from one or a combination of the following UPF constructs and UPF commands, their relevant options and objects.

List 6.5 The Source of Power States and their Transitions from UPF Constructs and Objects

• Supply Port States from add_port_state,

• Supply Net States from Power state table (PST),

• PST States from add_pst_state,

• Power Domain States from add_power_state,

• Supply Port, Supply Net, and Supply Set Functions States from add_supply_state,

• Power States of the Power Supply Sets from add_power_state, etc.

It is also evident that the power states originating from these different types of UPF constructs and objects directly affect the requirements and placement of special power management MV cells, such as ISO, ELS, PSW, and RFF in the design. Hence it is also required to collect coverage information from these MV cells. However, for dynamic simulation the coverage information for MV cells, apart from PSW, may only be collected from the different states and transitions of their controls and acknowledgement signals. Specifically the signals are:

List 6.6 The Source of Power States and Their Transitions from UPF Strategies

• Isolation “Enable” signal,

• Retention “Save and Restore” signals,

• Power Switch States and Transitions,

• Power Switch “Control Port”,

• Power Switch “Ack Port”

Recalling the syntax and example of ISO, RFF, and PSW in Chap. 3, it is evident that all of the above mentioned control and acknowledgement signals have the following transitions:

List 6.7 Transitions of Control Signals for UPF Strategies

• High-to-Low and

• Low-to-High transitions.

As well, during simulation, the status of these signals may remain in one of the following states:

List 6.8 States of Control Signals for UPF Strategies

• Active through presenting a value (level sensitive) or transition (edge sensitive),

• Inactive (opposite to the active)

• Active x (driving unknown)

• Active z (remain floating or un-driven)

In addition, apart from the control and acknowledgement signals, the functionality of the switch itself allows following state values and their possible combination of transitions as defined in the IEEE 1801 specification:

List 6.9 State Values of Power Switch, Control, and Acknowledge Ports

• ON state,

• OFF state,

• Partial ON state and

• UNDETERMINED (ERROR) state.

At any given time, the ON or the partial ON state contributes a value to the output port of the PSW. The UNDETERMINED status comes into existence only when the ON or partial ON state Boolean expression for a given input supply port, which is not in OFF state, refers to an object with an unknown (X or Z) value, then the contributed value at the output of PSW remains {UNDETERMINED, unspecified}. However, in PA-SIM the UNDETERMINED states are interpreted as ERROR states. Hence the PSW itself also has the states as shown in List 6.9. The coverage metric is required to cover all possible transitions between these states (Fig. 6.1).

Fig. 6.1

State-transition diagram of PSW

Hence coverage information modeling from power-states and their transitions based on fundamental aspects of different UPF constructs from add_port_state, add_pst_state, and add_power_state are also straightforward. Even for the PSW as well as controls and acknowledgment signals of different MV cells, states-transition coverage can be collected through properly exercising the appropriate properties of the design functionalities and elements.

However, all the transitions from the above discussions are not naturally spontaneous in PA-SIM and require user intervention to specify that they are required to be included in the coverage information database. The UPF semantics in 1801–2013 LRM or UPF 2.1 defines the describe_state_transition command for monitoring the legality of power state transitions from one named power state to another. As well, 1801–2015 LRM or UPF 3.0 provide similar semantics through the add_state_transition command to define named state transitions between power states of an object. These commands provide the methodologies for PA simulation tools to accommodate customized coverage from any state or transitions in PA-SIM. For simplicity, the construct detail of describe_state_transition is discussed below as representative of a custom state or transition coverage inclusion mechanism.

Example 6.1 Syntax for Monitoring the Legality of Power State Transition

Verse

Verse describe_state_transition transition_name -object object_name [-from from_list -to to_list] [-paired {{ from_state to_state }*}] [-legal | -illegal]

Here <transition_name> is just a simple name provided by the user. The -object <object_name> is also a simple name of a power domain or supply set. Often PA simulation tools augment acceptable arguments in -objects names to possibly extend the scope of PA coverage. The -from argument in the <from_list> accepts unordered lists of power state names active before a state transition, and <to_list> accepts the unordered list of power state names active after a state transition. The -paired {{from_state to_state}*} actually accepts the list of transition state pairs name for the <from-state> name and <to-state> name. Finally, the -legal and -illegal pair is used to tag a state transition whether it is legal or illegal. By default all state transitions are legal.

Likewise, in a complex hierarchical UPF flow, the power state of the top power domain may remain dependent to the power states of subdomains. Further, power states also specify states for the associated supply sets of these interdependent power domains. Such power state dependency impacts coverage collection and are not as straight forward as the simple state transition coverage discussed so far. A power state dependency based special coverage mechanism is explained in separate Sects. 2 and 3 respectively.

6.2 PA Dynamic Simulation: Coverage Features

The exhaustive lists of coverage extraction procedures from power states and their transitions shown in the beginning part of the previous Sect. 1 actually forecasts the complexity of the overall power-state based coverage computation process. Specifically the abstract nature of power-states, their interdependency, and simultaneous transition occurrence of these interdependent power states requires special attention for coverage collection, analysis, and results.

In order to fully comprehend and confront such coverage complexities, it is required to assess the power state constructs from the component level. Recalling the add_power_state examples in Chap. 3, fundamentally, UPF defines a power-state for a power domain and its associated supply networks. The definition further allows referencing the port state of any supply port or supply net in the descendant subtree from the scope of the top power domain. The UPF add_power_state syntax is shown below:

Example 6.2 UPF Syntax for add_power_state

Verse

Verse add_power_state [ -supply | - domain | - group | - model | - instance ] object_name [ -update ] [ -state {state_name [ -logic_expr {boolean_expression}] [ -supply_expr {boolean_expression}] [ -power_expr {power_expression}] [ -simstate simstate] [ -legal | -illegal ]}]* [ -complete ]

As already discussed, the add_power_state command provides the capability to augment power states to different UPF objects through the <object_name>. The <state_name> represents the user specified name for a power state that is just defined or updated for the <object_name>. The –logic_expr is used to define the power states for either supply sets or power domains. The expressions are constructed by referencing control conditions, clock frequencies, and power states of the domain supply sets. On the other hand -supply_expr is used only for power states of supply sets; it refers to the functions of supply states of the supply set. Each of these expressions can be further defined as either legal or illegal.

Hence it is distinctive that the logic and supply expressions in the add_power_state definition are based on various conditions through Boolean expressions. These Boolean expressions may contain control conditions, design parameters as well as power state information from different power domains including hierarchically lower level domains. Though such subtree power state referencing from top, allows symmetrical hierarchical representations of power domains, supply network, and their corresponding power-states, but they may also impose inter-state dependency that is often difficult to track. The following example shows the power states of PD_top domain in terms of logic expression.

Example 6.3 UPF add_power_state Sample Example with -logic_expr

Verse

Verse add_power_state PD_top -state SYS_ON { -logic_expr \ {PD_sub1 != SUBSYS1_OFF && PD_sub2 == SUBSYS2_ON }} add_power_state PD_top -state SYS_OFF {-logic_expr \ {PD_sub1 == SUBSYS1_OFF && PD_sub2 == SUBSYS2_OFF }}

These examples are proof of dependency of power states among power domains from PD_top to subtree domains, PD_sub1 and PD_sub2 (reference to Fig. 2.1, Chap. 2). As discussed on several previous occasions, the power states actually remain at the core and drive the entire UPF based PA verification. Hence it is required to devise a mechanism that provides a comprehensive and coherent coverage computation model for the following:

List 6.10 Additional Sources of Power States and Transitions

• 1. All possible combinations of interdependent power states,

• 2. As well as their possible simultaneous transitions.

Since these power states and transitions are highly interdependent, the coverage metrics generally aim to find their possible cross combination for transition occurrence and hence the coverage for such models are termed, cross-coverage. Although it is already mentioned in the previous section that the UPF semantics in 1801–2013 LRM or UPF 2.1 define describe_state_transition for monitoring the legality of power state transitions from one named power state to another, but their semantics do not comply with the context and requirements of cross-coverage computation. (To note, the background detail for the coverage computation model based on the describe_state_transition is already discussed in the previous Sect. 1. The command syntax and PA-SIM specific implementation to compute coverage on these semantics are discussed in the succeeding sections).

Hence the PA-SIM verification environment requires to develop an internal mechanism to establish the cross-coverage computation model. For simplicity, the cross-coverage computing flow can be best represented by a simple dependency graph. The nodes of the graph will be based on power state logics and supply expressions, where the nodes will represent power states and their edges will represent transitions between the nodes. A path between the nodes will denote a sequence of nodes and edges, connecting a node with its descendant and (or) dependent.

The PA-SIM verification environment required to monitor and capture the transitions from the edges of the graph. The path will provide the depth for a group of inter-dependent nodes and helps to untie the dependency among these nodes. Since there is no UPF semantic, hence tool process, the above coverage metric is based on the following extended methodology.

Example 6.4 Methodology Extension for Cross-Coverage

Verse

Verse describe_state_cross_coverage [-domains domains_list] [-depth cross_coverage_depth]

The describe_state_cross_coverage command is an augmentation of current UPF intent to supplement the missing cross-coverage computation semantic model. The –domain defines the list of power domains for which cross-coverage needs to be computed. The -depth is the number of power-domains that are involved in the cross-coverage computation and are interdependent. By default, the computation starts with depth one; however the tool will figure out the list of dependent power domains of a particular top or adjacent domains. These dependent power-domains together with the specified top domain will form a domain group. Then the tool computes the cross-coverage results for this particular group of power domains. Hence for the –logic_expr example of add_power_state, shown above and from the Fig. 6.2, PA-SIM will develop the cross-coverage computing model for PD_top->PD_sub1->PD_sub2 as follows (Tables 6.1 and 6.2).

Fig. 6.2

Dependency graph for cross-coverage computation model for power domains group PD_top->PD_sub1->PD_sub2

Table 6.1 Dependent states for power domains

Table 6.2 Cross-coverage data for -depth=1 (default) for  PD_top->PD_sub1->PD_sub2

The PA-SIM tool specific details on coverage collection, analysis, and obtaining the results from PA dynamic checks based on the PA testbench, automated PA sequence checkers, custom PA checkers, and power state transitions, as well as coverage from the cross-coverage models are discussed in Sect. 3.

6.3 PA Dynamic Simulation: Coverage Practices

From the discussion in the previous two Sects. 1 and 2, it is apparent that designing a complete PA coverage computation model is complicated and has to rely intensely on various nonstandard and nontraditional aspects of coverage measurements. However, through a comprehensive and coherent analytical model, tool, and methodology augmentation, it is possible to completely enumerate the coverage collection, analysis, and results representation through PA-SIM. The entire PA coverage metric computation model, which was listed in List 6.2, can be updated to a new list based on the analytical discussions in the previous two sections.

List 6.11 Updated List for the Complete Sources of PA Coverage Computation Model

• 1. Coverage information from PA Dynamic Checks based on;

  • PA testbench (Code Coverage),

  • Automated PA Sequence Checkers and

  • Custom PA Checkers,

• 2. Coverage information from Power states and power state transitions based on;

  • Design controls,

  • Supply ports and nets created in the UPF and design,

  • Power domains and their power states,

  • Supply sets and their states,

  • Power Switch States and their Transitions,

  • State transitions for ISO, RFF, PSW Control and Acknowledgement signals,

• 3. Coverage Information from Cross-Coverage based on;

  • All possible combinations of interdependent power states,

  • As well as their possible simultaneous transitions.

On the basis of the above categorization, the dynamic simulation tool processes the coverage collection, analysis, and representation of the results from power aware verifications. The succeeding stanzas will cover the tool specific approach for all the coverage information listed in the above three categories. The tool computes the coverage in the following phases:

List 6.12 PA Coverage Computation Phases through Dynamic Simulation

• Step 1: Collecting PA coverage

• Step 2: Analyze the coverage through generated UCDB for merging

• Step 3: Reporting the results

• Step 4: Analyze post-simulation coverage data from UCDB

• Step 5: (Optional) Coverage Exclusion

6.3.1 Coverage Computation Model: For PA Dynamic Checks

The five steps for the coverage computation model from PA dynamic checks are discussed in detail below.

Step 1: Collecting PA Coverage Information from PA Dynamic Checks

Recalling the standard three-step PA simulation flow discussed in Sect. 5.3, the coverage collections processes are exercised in the following way:

Standard Coverage Processing:

• (i) Compile: vlog- No special commands or options required (Not applicable onward)

• (ii) Optimize: vopt- requires to add “vopt -pa-coverage=checks”

• (iii) Simulate: vsim- No special commands or options required

Advanced Coverage Processing:

This process actually marks a power aware dynamic check as “covered” when the check has never failed and has passed at least once (fail count = 0 and pass count > 0). This result can be obtained from the following tool configurations.

• (i) Compile: vlog – Not applicable

• (ii) Optimize: vopt- requires to add “vopt -pa_coverage=checks”

• (iii) Simulate: vsim- requires to add “vsim –assertcover”

Identifying Unattempt Checks:

In addition, PA-SIM also allows distinguishing any unattempt power aware check assertions. Specifically, the coverage data includes information about any unattempt power aware checks.

• (i) Compile: vlog –Not applicable

• (ii) Optimize: vopt- requires to add “vopt -pa_coverage=checks”

• (iii) Simulate: vsim- requires to add “vsim – unattemptedimmed”

Step 2: Coverage Analysis and Generate UCDB for PA Dynamic Checks:

The next step after collection is coverage analysis. However this is a process to integrate and accumulate coverage data to the UCDB with .ucdb file extension as follows for the tool to analyze or facilitate the user to merge with any or all other coverage information collected.Verse

Verse CLI> coverage save <name>.ucdb or CLI> coverage save –pa <name>.ucdb

In the later step, the UCDB accumulated data is used for analyzing and reporting purpose.

Step 3: Reporting Results for PA Dynamic Checks:

PA coverage reports are generated from the data stored in the UCDB. Even though the results can be represented in numerous ways similar to non-PA coverage reports including HTML, XML or plain text, inclusion of verbosity often provides additional guide-points to further improve the achieved metric.Verse

Verse GUI> coverage report -assert –pa (optionally: verbose or summery) or CLI> vcover report pa.ucdb -assert –pa

Step 4: Analyze Post-Simulation Coverage Data from UCDB for PA Dynamic Checks:

UCDB provides comprehensive resources for coverage data analysis and generating numerous forms of reports even after completion of the simulation process. The complete coverage closure metric from non-PA and PA simulation environments can be accommodated through loading the database in a simulation window and generate the reports through the following process.Verse

Verse Load UCDB in GUI: GUI> vsim -viewcov <name>.ucdb Generate reports: GUI> coverage report -pa [-details]

Step 5: (Optional) Coverage Exclusion from PA Dynamic Checks:

There are no specific fine-grain controls and options to exclude specific coverage features from PA dynamic checks. Alternatively, not using the procedure in the tool Optimization phase explained above will automatically exclude coverage information from PA dynamic checks.

6.3.2 Coverage Computation Model: For Power States and Power State Transitions

Similarly the five steps for a coverage computation model from Power State Transitions in PA dynamic simulation are discussed in detail below.

Step 1: Collecting Power Aware Coverage Information on Power States and Power State Transitions

The basic power state and transitions coverage are primarily collected from the UPF commands explained in Sect. 1 that can originate from one or a combination of add_port_state, add_pst_state, add_power_state and their relevant options and objects.

Standard Power State Transition Coverage Processing:

• (i) Compile: vlog – Not applicable

• (ii) Optimize: vopt- requires to add “vopt -pa_coverage”

• (iii) Simulate: vsim- requires to add “vsim –coverage”

Controlling State Transition Coverage Collection:

Fine-grain user controllability is also available for state-transition coverage collection from ISO, RFF, PSW Control, and Acknowledgement signals through the following tool procedures.

(Option at Optimization: vopt – may requires to add one or all of the followings)

• For Power Switches (PSW states, control, and ack port) “vopt–pa_coverage=switch”

• For Isolation Enable “vopt –pa_coverage=iso”

• For Retention Save and Restore “vopt –pa_coverage=ret”

Controlling Transition Coverage Collection:

The UPF describe_state_transition command and its augmentation also provide fine-grain controllability for collecting power-state-transition-only coverage. Recalling the semantics explained in Sect. 1, Example 6.1, the PA-SIM provides the mechanism to include the following coverage information through the –object <object_name> options in describe_state_transition command.

List 6.13 Sources for PA Transitions for PA Coverage Computation Model

• 1. Transition Coverage:

  From Power States for

  • Power Domain,

  • Supply Sets,

  • PST states

However, any state marked as illegal will not to be covered. As well, it is also required to generate reports in a separate coverage section, to be more specific to transitions defined and marked legal from describe_state_transition command.

The other transition coverage that are also possible to collect from the augmentation of the describe_state_transition semantics are from the following categories.

List 6.14 Additional Sources for PA Transitions for PA Coverage Computation Model

• 1. Transition Coverage:

  From Power states for

  • PST,

  • Supply Ports,

  • Power Switches

In this case as well, when transitions are marked illegal they will not be reported in the transition coverage reports. For this category, it is also required to add the following procedure in the Optimization phase for tool processing along with all other relevant power aware dynamic simulation commands.

• Compile: No change

• Optimize: vopt- requires to add “vopt -pa_enable=statetransition” along with “-pa_coverage”

• Simulate: vsim- requires to add “vsim –coverage”

• UCDB Generation and Coverage Reporting: No change

Hence for the controlling transition coverage collection, the PA-SIM compilation and coverage reporting do not require any special procedures.

It is also required to understand that this UPF describe_state_transition command is exclusive for describing a state transition legality. Hence it is exploitable for coverage collection controllability. So, when this command is not used, all transitions are legal and reported in coverage results.

Alternately, when control is defined in the UPF intent file through the describe_state_transition command, the tool will generate a coverage report only for the specified transition in –object <object_name> as shown in following Example 6.5. In order to realize the complete transition coverage depiction, a corresponding PSW example is also shown adjacent to the controlling of the transition coverage commands.

Example 6.5 Controlling Transition Coverage by UPF describe_state_transition Command

Verse

Verse # PSW example for Collecting State Transition Coverage create_power_switch IN_sw \ -domain PD_SUBSYS2 \ -output_supply_port {vout_p VDD_IN_net} \ -input_supply_port {vin_p MAIN_PWR_moderate} \ -control_port {ctrl_p IN_PWR} \ -on_state {normal_working vin_p {ctrl_p}} \ -off_state {off_state {!ctrl_p}} # Controlling State Transition Coverage by UPF for PSW (IN_sw) shown above describe_state_transition ts -object IN_sw -from {ON} -to {} describe_state_transition ts1 -object IN_sw -from {ON} -to {OFF} describe_state_transition ts2 -object IN_sw -from {ON} -to {} describe_state_transition ts3 -object IN_sw -from {ON} -to {ERROR} -illegal

A sample report for Example 6.5 is shown below.

Example 6.6 Sample State Transition Coverage Reports from describe_state_transition for PSW

----------------------------------------------------------------------------------------------- UPF OBJECT Metric Goal Status ----------------------------------------------------------------------------------------------- PSW State Coverage Sample Report: TYPE : Power Switch /alu_tester/dut/IN_sw 50.0% 100 Uncovered Power Switch coverage instance \/alu_tester/dut/pa_coverageinfo/IN_sw/IN_sw_PS/PS_IN_sw 50.0% 100 Uncovered Power State ON 100.0% 100 Covered bin ACTIVE 3 1 Covered Power State OFF 100.0% 100 Covered bin ACTIVE 2 1 Covered Power State PARTIAL_ON 0.0% 100 ZERO bin ACTIVE 0 1 ZERO Power State ERROR 0.0% 100 ZERO bin ACTIVE 0 1 ZERO PSW Transition Coverage Sample Report: TYPE : Power Switch /alu_tester/dut/IN_sw 33.3% 100 Uncovered Power Switch coverage instance \/alu_tester/dut/pa_coverageinfo/IN_sw/IN_sw_PS/PS_TRANS_IN_sw 33.3% 100 Uncovered Power State Transitions 33.3% 100 Uncovered illegal_bin ON -> ERROR 0 ZERO bin ON -> PARTIAL_ON 0 1 ZERO bin ON -> ON 0 1 ZERO bin ON -> OFF 2 1 Covered PSW Control Port State Coverage Sample Report: TYPE : Power Switch Control Port /alu_tester/dut/IN_sw/ctrl_p 50.0% 100 Uncovered Power Switch Control Port coverage instance \/alu_tester/dut/pa_coverageinfo/IN_sw/ctrl_p/PS_ctrl_p 50.0% 100 Uncovered Power State ACTIVE_LEVEL 100.0% 100 Covered bin ACTIVE 3 1 Covered Power State INACTIVE 100.0% 100 Covered bin ACTIVE 2 1 Covered Power State ACTIVE_Z 0.0% 100 ZERO bin ACTIVE 0 1 ZERO Power State ACTIVE_X 0.0% 100 ZERO bin ACTIVE 0 1 ZERO

Now, the “Step2: through Step 4:”for the coverage information processing on “States and Transitions:” are exactly the same as for “PA Dynamic Checks:” shown above. Hence they are not duplicated here once again, except the following step 5.

Step 5: (Optional) Coverage Exclusion from Power States and Power State Transitions

The PA-SIM provides fine granularity for controlling specific power states to be excluded from coverage reporting. The “coverage exclude” procedure syntax is as follows:Verse

Verse CLI> coverage exclude –scope <scope_path> –pstype {portstate | pststate | powerstate} –pstate <state_obj> <state_list> –ptrans <state_obj> <transition_list> Where, portstate: state on a port and net added via add_power_state or add_port_state pststate: state on a pst added via add_pst_state powerstate: state on a supply set and power domain added via add_power_state The -pstate <state_obj> <state_list>: Exclude only listed states from state_list of object state_obj The -ptrans <state_obj> <transition_list>: Exclude only transitions mentioned in transition_list of object state_obj.

More detailed explanation of “coverage exclude” usage related to pstate and ptrans:

State exclusion (-pstate):Verse

Verse CLI> coverage exclude –scope <scope_path> -pstate <state_object> <state list>

Where,Verse

Verse <scope_path> is the scope of state object listed in List 6.15.

List 6.15 The List of <state_object>

• Supply port

• PST

• Supply Set

• Power Domain

• Power Switch

• Power Switch Control & Ack

• Isolation Signal (ISO_SIG)

• Retention Save (SAVE_SIG), Retention Restore Signal (RESTORE_SIG)

All transitions to and from this state will also be excluded.

Transition exclusion (-ptrans):Verse

Verse CLI> coverage exclude –scope <scope_path> -ptrans <state_object> <transition list>

Where,Verse

Verse <transition> is actually transition between state1 -> state2

In addition, tool also provide support for s1->* and *->S1 (where * denotes a simplified wildcard) type of transition coverage exclusion.

It is also worth noting that, during PA-SIM, all power states originating from add_port_state, add_pst_state, add_power_state may not remain active all the time. In general these commands specify predefined and named power states explicitly for UPF objects; such as power domain, supply set, supply port, and power state tables. The named state and their transitions are automatically covered by the tool. However, in a particular verification environment, the UPF intent file may not specify all possible power states for all of the above objects. Hence the tool specifies the missing power states as “undefined” power states and assigns these states as active when the named states are inactive. Hence the coverage data may also include “undefined” power states and transition information in the coverage data.

6.3.3 Autotestplan Generation: From PA Dynamic Checks and Power State Transitions

The coverage information created from List 6.11, the (1) PA Dynamic Checks and (2) Power States and Power State Transitions, as discussed in previous sections, provides an extra level of PA verification confidence. However, apart from providing the coverage closure metric, their coverage information also facilitates verification onward by auto generating a PA testplan as a constructive derivative in the process. The automated testplan or “Autotestplan” is generated on the basis of coverage information from the following categories of coverage collection procedure.

List 6.16 PA Checks Contributing Autotestplan Generation

• Dynamic PA checks,

• Power states and transitions (mainly from power domains and supply sets),

• Port states and transitions,

• Power State Table states and transitions

Autotestplan Generation Process:

• (i) Compile: vlog – Not applicable

• (ii) Optimize: vopt- requires to add “vopt -pa_enable=autotestplan”

• (iii) Simulate: vsim- requires to add “vsim –coverage –assertcover”

  (Optionally -unattemptedimmed)

Verse

Verse Coverage Analysis and Generate UCDB for Autotestplan: coverage save -pa pa.ucdb (Optionally) Generate XML format for the Autotestplan: pa autotestplan -format=xml -filename=foo.xml Merge the coverage UCDB with Autotestplan UCDB: vcover merge merged.ucdb pa.ucdb QuestaPowerAwareTestplan.ucdb

To note, QuestaPowerAwareTestplan.ucdb will be generated during the simulation process when the tool procedures are used as noted in “Autotestplan Generation Process”.

Visualize the merged UCDB to analyze the testplan and results on verification planner window: Verse

Verse vsim -viewcov merged.ucdb

The PA testplan may be used on verification onward for correlating the achieved coverage results and improving overall test suite specification and plan further. To assist the process, as noted before, the testplan also can be generated in various formats, including spreadsheets. The PA-SIM visualization system enables providing the PA coverage scenarios at a glance based on the automated testplan. Figures 6.3 and 6.4 below show an example of an XML format of a testplan and its visual contents, respectively. The hierarchical construct of the “testplan section”, “coverage status”, and the “% of goal” achieved features are productive resources to apprehend the verification status.

Fig. 6.3

Spreadsheet format of automated testplan

Fig. 6.4

Visualization of automated testplan features

6.3.4 Coverage Computation Model: For Cross-Coverage

The cross-coverage computation model is fundamentally based on the power state’s Boolean expressions defined either in terms of logic nets, power states of supply sets, power domains or their combination, that evaluates to be true when the object is in the state being defined. The - logic_expr in add_power_state semantic specifies such Boolean expressions and are the keys to the cross-coverage extraction process.

Recalling the Example 6.4 in Sect. 2, the extended methodology for collecting cross-coverage through the describe_state_cross_coverage semantic is explained with a specific example of logic expression in add_power_state command below.

Step 1: Collecting Coverage Information from Cross-Coverage

Example 6.6 Sample example for cross-coverage collection from add_power_state Verse

Verse add_power_state PD_OUT -state PD_OUT_on {-logic_expr {PD_OUT.primary == PD_OUT_primary_on}} add_power_state PD_OUT -state PD_OUT_off {-logic_expr {PD_OUT.primary == PD_OUT_primary_off}} add_power_state PD_OUT -state PD_OUT_ret \ {-logic_expr {PD_OUT.primary == PD_OUT_primary_off && PD_OUT.default_retention == PD_OUT_ret_on}} add_power_state PD_OUT2 -state PD_OUT_on {-logic_expr {PD_OUT == PD_OUT_on}} add_power_state PD_SUBSYS2 -state PD_SUBSYS2_on \ {-logic_expr {PD_SUBSYS2.primary == PD_SUBSYS2_primary_on}} add_power_state PD_SUBSYS2 -state PD_SUBSYS2_off \ {-logic_expr {PD_SUBSYS2.primary == PD_SUBSYS2_primary_off}} add_power_state PD_SUBSYS1 -state PD_SUBSYS1_on \ {-logic_expr {PD_SUBSYS1.primary == PD_SUBSYS1_high_volt && PD_OUT2 == PD_OUT_on}} add_power_state PD_SYS -state RUN \ {-logic_expr {PD_SUBSYS1 == PD_SUBSYS1_on && PD_SUBSYS2 == PD_SUBSYS2_on}} add_power_state PD_SYS -state SLEEP \ {-logic_expr {PD_SUBSYS1 != PD_SUBSYS1_on && PD_SUBSYS2 != PD_SUBSYS2_on}} ### configure cross coverage ## describe_state_cross_coverage - domains {PD_SYS} -depth 3 describe_state_cross_coverage - domains {PD_SUBSYS1} -depth 2 describe_state_cross_coverage - domains {PD_OUT2}

In the above examples, the describe_state_cross_coverage is given for three different power domains to find the cross-coverage data for different depths ranging from none, which is default and depth 1 for PD_OUT2, depth 2 for PD_SUBSYS1, and depth 3 for PD_SYS. The tool will process the dependency graph for each category based on the depth information and extract the state transition from the add_power_state logic expression components like “{PD_SUBSYS1 != PD_SUBSYS1_on && PD_SUBSYS2 != PD_SUBSYS2_on}”.

Though the testbench is the actual trigger for a power state to make a transition to another state, the cross-coverage collection procedure depends more on unrolling the dependency of these transitions on power states from hierarchical paths. Following are the cross-coverage collection procedures for PA-SIM.

• Compile: No change.

• Optimize: vopt – requires to add “vopt –pa_coverage”

• Simulate: vsim – requires to add “vsim -coverage –assertcover”

Step 2: Coverage Analysis and Generate UCDB for Cross-Coverage

The cross-coverage database generation from the collected coverage in step 1 is similar to any other UCDB generation process.

CLI> coverage save pacross.ucdb

Step 3: Reporting Results for Cross-Coverage

As well, cross-coverage result analysis and representation from UCDB are also similar to any other coverage reporting process.

CLI> vcover report -detail -pa pacross.ucdb

The following Example 6.7 shows a sample reports for cross-coverage.

Example 6.7 Sample Report for Cross-Coverage Based on Example 6.6

POWER STATE COVERAGE: ----------------------------------------------------------------------------------------------- UPF OBJECT Metric Goal Status ----------------------------------------------------------------------------------------------- TYPE : POWER STATE CROSS /alu_tester/dut/PD_SYS(ID:PD1), /alu_tester/dut/PD_SUBSYS2(ID:PD2), /alu_tester/dut/PD_SUBSYS1(ID:PD3), /alu_tester/dut/PD_OUT2(ID:PD4), /alu_tester/dut/PD_OUT(ID:PD5) 100.0% 100 Covered POWER STATE CROSS coverage instance \/alu_tester/dut/pa_coverageinfo/PD_SYS/PD_SYS_PS_CROSS/PS_CROSS_PD_SYS 100.0% 100 Covered Power State Cross 100.0% 100 Covered bin \PD1:SLEEP-PD2:PD_SUBSYS2_off 2 1 Covered bin \PD1:RUN-PD2:PD_SUBSYS2_on-PD3:PD_SUBSYS1_on-PD4:PD_OUT_on-PD5:PD_OUT_on 2 1 Covered TYPE: POWER STATE CROSS /alu_tester/dut/PD_SUBSYS1(ID:PD1), /alu_tester/dut/PD_OUT2(ID:PD2), /alu_tester/dut/PD_OUT(ID:PD3) 100.0% 100 Covered POWER STATE CROSS coverage instance \/alu_tester/dut/pa_coverageinfo/PD_SUBSYS1/PD_SUBSYS1_PS_CROSS/PS_CROSS_PD_SUBSYS1 100.0% 100 Covered Power State Cross 100.0% 100 Covered bin \PD1:PD_SUBSYS1_on-PD2:PD_OUT_on-PD3:PD_OUT_on 2 1 Covered

Step 4: Analyze Post-Simulation Coverage Data from UCDB

This is also exactly the same as in the case for PA Dynamic Checks explained in Sect. 3.1. However for simplicity the commands are reproduced here as well.Verse

Verse Load UCDB in GUI: GUI> vsim -viewcov <name>.ucdb Generate reports: GUI> coverage report -pa [-details]

Step 5: (Optional) Coverage Exclusion from Cross-Coverage

Since cross-coverage is more oriented toward capturing the coverage of inter-dependent power states, apparently based on the logic expression components of add_power_state, the possible combination of power states may explode and may diverge from the actual point of interest. Hence, the tool provides abundant fine grain controllability to customize report generation through exclusion. Following are the tool procedures for cross-coverage exclusion along with simple examples.Verse

Verse CLI> coverage exclude –scope <scope_path> –pstate <state_obj> <state_list> –ptrans <state_obj> <transition_list> –pcross Where, The -pstate <state_obj> <state_list>: Exclude only listed states from state_list of object state_obj The -ptrans <state_obj> <transition_list>: Exclude only transitions mentioned in transition_list of object state_obj. The -pcross: Exclude cross coverage of the listed –pstate or –ptrans. Cross Coverage exclusion (-pcross): CLI> coverage exclude -pstype powerstate -pstate PD_SYS This will exclude the cross coverage bins for PD_SYS like PD_SYS_PD_SUBSYS1_PD_SUBSYS2 CLI> coverage exclude -pstype powerstate -pstate PD_SYS RUN However this will be as follows: Exclude - {RUN PD_SUBSYS1_on PD_SUBSYS2_on} Include - {SLEEP PD_SUBSYS1_on PD_SUBSYS2_on} CLI> coverage exclude -pstype powerstate -pstate PD_SYS SLEEP –pcross Exclude - all the cross coverage bins of SLEEP (PD_SYS) (Include - this will not exclude the state and transition coverage).

It is worth mentioning here that the cross-coverage theory explained in Sect. 2 is implemented based on SystemVerilog covergroup semantics. The “cross-coverage bin” is the extractions of coverage point transitions (edge of the graph). More precisely, a covergroup can contain one or more coverage points. A coverage point can be an integral variable or an integral expression. Each coverage point includes a set of bins associated with its sampled values or its value transitions. The bins, as seen in the above examples, can be explicitly defined by the user or automatically created by the tool exploiting SystemVerilog semantics.

Regarding coverage for Mixed-RTL and the GL-netlist, it is also required to know that during PA-SIM, the power aware automated checks are not conducted on the gate level cell instance scopes as discussed in Chap. 5. Hence they are excluded from any coverage calculation and the tool generates the list of all the excluded assertion information in the report file named “pachecks.excluded.txt”.

Coverage is an enormous topic and hence explained in a separate Chap. 6, in conjunction with the PA dynamic simulation, since coverage computation models are possible to develop only during the simulation process. Unlike the non-PA, the PA coverage computation models are exceptional, complicated, and robust in nature as explained and observed in this Chapter.

Hence the PA dynamic verification through simulation is also a robust, critical, yet mandatory verification process in every phase of DVIF that combines diversified power aware features, functionalities, computation models, techniques, and trends for the tool, design, and methodologies. PA dynamic simulation is the testimony of the functional correctness of the design under verification from the power specification and power intent perspectives. However, such power specifications also alter the design structurally from the power architecture and microarchitectural points of observation. Often verifying power-related physical and structural changes in a design through simulation is expensive in terms of verification time, resources, and efficiency.

The next Chap. 7 will discuss a different perspective of PA verification, which is PA-Static. The PA-Static verification tool with built-in PA architectural and microarchitectural verification rules is the best suited solution for verifying power intent and design from physical and structural points of view. The next Chap. 7 will discuss the PA-Static verification techniques. Although chronologically the PA-SIM verification discussion appears before the PA-Static, there is no specific precedence to deploy such tools in the DVIF in the same order. The order of PA tool deployment for PA verification, broadly, depends on the design abstraction levels. Correlating the results from both the verification environment are instinctive.

Epilogue: The Chap. 6 provided an exhaustive but coherent solution to device and measure PA coverage metric. The readers will find the exhaustive List 6.4 for understanding the PA state machine mechanism and Lists 6.5, 6.6, 6.7, 6.8, 6.13, and 6.14 as the complete sources of power states and their transitions to compute complete PA coverage. Specifically the List 6.11 Updated List for the Complete Sources of PA Coverage Computation Model will remain as the primary source for all type of PA coverage computations. Although add_power_state remains as standard source but this chapter also explains the missing part for interstate overlap or cross-coverage computation through extended UPF command describe_state_cross_coverage. In addition, Autotestplan generation, merging of PA coverage metric in UCDB, and fine-grain controlling of exclusion of coverage data are explained with practical examples.

Prologue: The Chap. 7 – UPF Based Power Aware Static Verification, just like Chap. 5, provides a generic foundation for PA-Static verification. The chapter explains the advanced techniques for PA-Static verification with detail example of built-in rules of the static checker. In addition, the chapter also includes an interactive PA-Static examples that explains the fundamental aspects of how to debug and resolve real power aware static issues in a design.