Seeing Is Believing: Visualizing Full Coverage Closure In Low-Power Designs

By Madhur Bhargava and Durgesh Prasad

Lowering the power consumption and leakage in SoCs and other electrical designs has become a paramount concern in recent years. The reasons for this are many and well understood. The structures and techniques we use to accomplish this have made verification of so called low-power designs more complex and difficult than it is for designs where power usage is not critical. Consequently, many new technologies, tools, and methodologies have arisen to help with low-power verification objectives.

These power-aware verification solutions have been proven to be helpful in ensuring that the low-power aspects of designs function correctly and are free of bugs. Yet, with all this added complexity, it’s even more challenging to know when you’ve thoroughly verified the entire design, both the non-power RTL and its low power elements. In other words, how do you know you’ve achieved 100% code coverage, as well, how do you reach closure as quickly and easily as possible?

Because neither the UPF LRM nor the UCIS standard have provided any guidance for a standardized low power coverage methodology, verification engineers have fallen back on ad-hoc approaches, which are error prone and highly time consuming. Thus, verification engineers continue to face a difficult road while pursuing full code coverage of low-power designs.

Overcoming these challenges is greatly advanced by the ability to visualize all of the coverage results. In this article, we share some highly effective ways to improve your ability to visualize all coverage results, enabling you to achieve verification closure of low-power designs in significantly less time.

Code coverage in low-power designs
Achieving code coverage closure in low-power verification requires two things: the coverage of power objects and full coverage of the RTL itself. Thus, regression setups for low-power designs are divided into two parts. Typically, part of the RTL code is covered by a non-power aware regression and the remaining parts of the RTL code is covered when the low-power regressions are completed. Together these two regressions achieve 100% structural code coverage of the design.

First let’s review the different categories of code coverage.

Statement Coverage /Line Coverage: This gives an indication of how many statements (lines) are covered in the simulation, by excluding lines like module, endmodule, comments, timescale etc. This is important in all kinds of designs and has to be 100% for verification closure. Statement coverage includes procedural statements, continuous assignment statements, conditional statements and Branches for conditional statements.

Conditional/Expression Coverage: This gives an indication of how well variables and expressions (with logical operators) in conditional statements are evaluated. Conditional coverage is the ratio of number of cases evaluated to the total number of cases present.

Branch/Decision Coverage: In Branch coverage or Decision coverage reports, conditions like if-else, case and the ternary operator (? : ) statements are evaluated in both true and false cases.

Toggle Coverage: Toggle coverage gives a report about how many times signals and ports are toggled during a simulation run. It also measures activity in the design, such as unused signals or signals that remain constant.

State/FSM Coverage: FSM coverage reports show whether the simulation run could reach all of the state s and cover all possible transitions or arcs in a given state machine. This is a complex coverage type, as it works on behavior of the design that means it interprets the synthesis semantics of the HDL design and monitors the coverage of the FSM representation of control logic blocks.

Due to low-power instrumentation, coverage numbers taken from the low-power simulation are expected to be different from those from the non-power aware simulation. However we need to address the visualization of coverage results for a low-power design. We will look into various approaches in each of the code coverage types to tackle this issue.

Line Coverage
The issue with line coverage calculations in a power-aware simulation run is that including power logic introduces new lines and statements, which not only modifies the line numbers of existing RTL logic but also gets included in statement/line coverage.

One way to handle this problem is to exclude the coverage of new lines/statements introduced by including power logic. In Example 1, exclude the statement coverage for statements (line 2, 3, and 4) so that it will give proper results as expected on a non-power-aware RTL logic.

Example 1: D-FlipFLop with additional PA logic

Also, the line numbers of newly added lines can be set to some high number or negative number so that they won’t modify the line numbers of actual non-power-aware RTL logic while reporting.

Conditional/Expression Coverage
Example 2 includes a low-power instrumented expression in which we can observe that the actual non-power-aware expression has been modified to include power logic and that new lines/statements were not introduced. This modification resulted in an increase in FEC expression input terms. Therefore, expression coverage will not give proper results as expected on a non-power-aware RTL logic.

Example 2: PA logic inserted into RTL expression

In order to achieve proper low-power expression coverage one can exclude the input terms that have been additionally added. Once they have been excluded, the expression coverage will depend only on the actual RTL logic input terms and thus give proper results as expected on a non-power-aware simulation.

In Example 3, there is no issue with conditional coverage because the conditional statement has not been modified, and thus one can have proper results as expected on a non-power-aware simulation.

Example 3: No change in RTL conditional statement

Branch Coverage
The issue with a branch coverage calculation in a low-power simulation run is similar to that with the line coverage calculation. In this scenario, to include power logic, new branches are introduced which not only modify the line numbers of existing RTL logic but also gets included in branch coverage.

Here, again, you can use the same approach followed for line coverage to achieve sophisticated code coverage; for example, excluding the coverage of new branches that were introduced to include power logic. In Example 1, you exclude the branch coverage for newly added branches (lines 2 and 9) so that it will give proper results as expected on a non-power-aware simulation. Also, the line numbers of newly added branches can be set to some high or negative number so that they won’t modify the line numbers of actual RTL logic while reporting.

Toggle Coverage
Insertion of power logic into the RTL logic causes toggling of signals and ports which are otherwise unused signals or signals that remain constant as they were in non-power-aware simulation. Therefore, performing toggle coverage on this low-power instrumented logic will not give proper results.

As we can see in Example 4, the always block can get triggered whenever there is activity on the PWR signal even though there is no activity on signal a. This triggering of the always block will result in toggling activity of signal t. Since, there is no way in RTL code coverage to exclude the toggling activity of signals in the block because of new powering logic, there will always be a difference in toggle coverage results in both non-power-aware and low-power simulation.

Example 4: Change in sensitivity list can affect toggle coverage

State/FSM Coverage
The issue with state/FSM coverage is that the introduction of any new states will not give proper results as expected on a non-power-aware FSM logic. From the low-power instrumented FSM logic shown in Example 5, we infer that verification tools create a new state (say, xx) to make sure the object is in some state during the simulation run when power goes down.

Example 5: New state introduced into FSM as a result of power-aware instrumentation

One way to tackle this issue is to exclude the states added to facilitate the power logic, which will result in proper FSM coverage.

Complex Power-Aware Instrumentation
The examples used in this article use simple RTL logic for which we could easily apply the above mentioned approaches to tackle the challenges imposed by additionally added power-aware instrumented logic and thus achieve proper code coverage results as expected by the user on a non-power-aware simulation. There may be various design logics which result in complex power-aware instrumentation for which exclusion of code coverage components for additionally added power-aware logic wouldn’t be simpler. Consider Example 6, in which the retention strategy has been applied on a simple D-FlipFlop:

Example 6: Power-aware instrumentation of restore and save processes on the output of a D-FlipFlop

In order to provide retention capability, the behavior of each register to be retained is modified. We can see that the process sensitivity list for the register is expanded and the body of the process is modified. Also, an additional process is created for the saved state. Excluding coverage for new statements/branches introduced into the RTL logic is not straightforward and therefore, addressing these kind of complex, power-aware instrumented scenarios needs more diligent and meticulous analysis.

Code + Functional Coverage = Closure
Code coverage tells us only about the quality of the implemented design and not the low-power functionality; thus it alone doesn’t ensure verification completeness. With 100% coverage in both code coverage and functional coverage one can have verification closure of the design.

Low power coverage is as essential as functional coverage of RTL. Low-power coverage data helps to ensure that regression suites are adequately testing power aware elements of the design, including dynamic power aware checks and power aware states and transitions, as created through the UPF file with the add_power_state, add_port_state, or add_pst_state commands.

SystemVerilog construct “covergroups” help in sampling signal/property activities at desired sampling points through coverpoints and bins. These are used effectively to collect coverage numbers of states and their transitions. Moreover, a low-power coverage methodology that combines UPF 3.0 HDL functions with SystemVerilog coverage constructs can also help you write a fast and reliable low power coverage infrastructure.

Power/port/PST states are a key aspect of today’s low power designs. They capture the intent about the operating modes of the low power design and hence have a huge impact on the functionality. So it becomes essential to verify the occurrence of various states and their transitions to ensure proper operation of low power designs as well as to achieve verification closure of the design.

The complexities in low power verification have greatly increased. Code coverage is an important aspect of the verification process. In this article we covered how total coverage results can be visualized in order to achieve verification closure in significantly less time. For more detailed information on the code coverage challenges of low-power designs and how these challenges are addressed in low-power verification environment, please read our paper Unveil the Mystery of Code Coverage in Low-Power Designs: Achieving Power Aware Verification.

Durgesh Prasad is a Low Power UPF Expert for Mentor, A Siemens Business with more than 11 years of experience. He holds a Bachelor’s degree in Computer Science and Engineering from IIT, BHU. He is also a member of IEEE Low Power Working Group.