Automating Coverage And Analysis Of Low Power Designs

There are some exciting new things in the just released IEEE1801-2015 (aka UPF 3.0), some of which have significant benefits for coverage of low power designs, which is what we’ll be looking at in this blog.

One of these is improved semantics for the add power state command, introduced in IEEE1801-2009 (aka UPF 2.0). These clarifications to the add power state command allow you to clearly define the power states of the power domains of your system, which tools can leverage to automate coverage. This gives you a great way to measure the completeness of the verification of the design, including the power management architecture, so you know when you reach low power coverage closure.

Knowing you’ve properly tested your design is really important. I wanted to get some insights from Gabriel Chidolue who has been working hard on making it easier and faster for our customers to close on coverage of their low power designs so they have the confidence to move on to tapeout.

Gabriel Chidolue, Verification Technologist, Mentor Graphics

Q: Would you describe what coverage means in the low power sphere? And what are the different aspects in low power coverage?

Chidolue: The first thing I’d like to talk about concerns gathering the coverage data and formulating the coverage model out of UPF.

First of all, one can gather coverage from the dynamic power aware checks (i.e., assertions) that a tool like Questa enables automatically. We talked about these in our last Semiconductor Engineering blog, Three Steps to Complete Power-Aware Debug. Any point where a dynamic check has succeeded in passing without firing is a good coverage point because it gives an indication of some specific functionality, such as whether the sequence to activate an isolation cell or to power up a power domain is followed correctly.

We also collect coverage data for the power states of the supply sets that form the supply network. It’s important to understand if your controls have activated the supply network into the appropriate states and voltages. This coverage is also based on the state specification available in the UPF using the add power state command. The new semantics and clarifications in UPF 3.0 describe power state composition and refinement, making it now possible to gather coverage across the entire system.

Q: Why is this measurement of coverage for low power functionality important to the users?

Chidolue: For RTL design in general, coverage is important to give you a notion of whether you’ve adequately tested complex interactions in the system. The same is true for low power design.

For low power, it’s not just coverage of the RTL function, it’s coverage of the RTL function as well as the power management artifacts inferred by the UPF file. That’s why the tools have to be able to extract all that information out of the UPF to build a complete picture of the coverage model representing the various states that the design could potentially be in. Then the verification tools have to operate on the design through the testbench, and finally the testbench has to activate the design to make sure that all those different states have been covered. That’s why coverage is really key. It’s an indicator of the quality of your testing.

Q: This must become very complicated very quickly with all the different power domains, subsystems, things like GPUs and CPUs being in different power states at the same time and having so many interdependencies. How does someone keep all this straight?

Chidolue: That’s a good point. Designs are just getting more complex all the time. So the next thing you need is an automated solution for coverage tracking, such as Questa Verification Management, which extracts a low power test plan based on the UPF and any checks the user may have enabled, and then links these test plan items with the power aware coverage objects already created during test runs of the design. Questa Verification Management stores coverage data and the test plan in the UCDB (an industry-standard coverage format compatible with UCIS API) Now you have a complete, unified view of coverage for both the RTL and the power management functions of the design.

Here are the details of how this all works. So the question you ask yourself is, ‘Am I seeing correct behavior across all the legal power states that my design could potentially be in?’ To do that you need to transition the design through all those legal power states, and you need to make sure you are covering all the power state transitions. Questa PASim automates that coverage, extracting and building, in effect, this kind of picture for you in different ways.

Q: That’s great for collecting the coverage data, but then how do you analyze and present the coverage and report it in an interesting way?

Chidolue: That’s where the coverage reporting and test plan integration comes in. Because we store all of the coverage data in the UCDB, we can leverage all the infrastructure that verification management provides. We can automate the creation of a test plan out of the UPF data and link the coverage objects that we’re tracking from the power state transitions and power assertions to the test plan. The test plan is executable so it can be used by the Questa Verification Management solution.

UPF is used to specify the power states of the whole system, in terms of the possible combinations of the power states of each of the power domains of the system – or more specifically, of the primary supplies for each power domain. Questa PASim presents this system power state information in a graphical form similar to a finite-state-machine, along with a tabular representation that is quite similar to the PST structure. In the table, the power supplies are shown as columns and the system power states appear as rows. The green cells represent the current state of each supply, and the yellow cells represent the previous state of each supply. Thus the row that is all green represents the current power state of the system.

UPF describes this so we can automatically extract all this information and build the coverage model from the UPF. That’s the great thing about UPF, and it’s quite powerful.

Also check out a “new school” low power methodology called “successive refinement,” which is detailed in a webinar: New Low Power Verification Techniques. Included are what kinds of power intent information should be captured at each stage of the design flow, which features of UPF are involved in doing so, and how this structured approach benefits both IP providers and IP users.