Three Steps To Complete Power-Aware Debug

In previous blogs, we’ve talked about UPF and the successive refinement low power flow developed by ARM and Mentor Graphics (you can find these here.)

In this blog we’d like to walk through some typical debugging scenarios our customers face in their low power designs. So I’ve asked two of our low power debug experts, Gabriel Chidolue and Mark Handover, to join me to make sure you get the straight dope from our best and brightest minds.

Gabriel Chidolue, Verification Technologist, Mentor Graphics

Mark Handover, Application Engineer, Mentor Graphics

First of all, UPF adds isolation cells, level shifting, checking, and other things on top of the RTL. The power domain is defined in the UPF, the power states are defined in the UPF, and you’re merging this all on top of your RTL. When you want to start debugging, what are the important things to have access to and be able to see after the UPF has been added to the RTL?

Gabriel: It’s critical that UPF be considered part of the design. So you need a completely unified view because you want to debug the interactions between the RTL and the contents of the UPF together. You need an environment that allows you to see the expanded artifacts that include not just the logical things that belong in the RTL but all the other inferred structures that come from the UPF side of things.

For example, Figure 1 shows how the Visualizer Design Hierarchy tab allows you to look at both your UPF and RTL structure, for the first time probably, by putting those two worlds together. This particular example shows that the design has been expanded to include the UPF artifacts in the design itself, so it’s all mixed in with the design, following the design’s logical hierarchy.

Figure 1: Visualizer design hierarchy tab with UPF.

Ellie: What are the scenarios and flows you use when debugging UPF as part of your design. What are the things you’re looking for?

Gabriel: There are three steps: static checking, dynamic checks, and dynamic sequencing.

STEP ONE: Static Checking
First you iron out structural issues from power management using a static checker. In order to do this type of check, if and when you do get an error, what you’d like to do is understand why the tool is reporting an error. For that you would need a supply network as well as the ports in question that may have an isolation cell missing—or conversely, have an isolation cell that’s not required. Those kinds of issues are best debugged in an environment that allows you to visualize the combined artifacts of the isolation, supply network information, and power space.

Mark: When you’re doing static checking, you’re looking at things like power domain crossings. The Visualizer Power Domain Crossings window in Figure 2 lists the power domains and the signals that go from one power domain to another. On the far right of the window, it shows the static checker results that are getting flagged; i.e., “redundant level shifter,” “not inserted level shifter,” and “redundant isolation.” One of the biggest things in UPF is that you’ve properly added these structures in your design.

Figure 2: Debugging static checks and UPF using the power domain crossings window.

Gabriel: This window allows you to see the issues, and if you want to debug them further, you click the icon between “state” and “info” to open up the schematic, seen in Figure 3, that shows detailed information about which signal in question is crossing from one particular source domain to a sink domain.

Figure 3: Logic cone view of a power domain crossing, complete with isolation cell.

Mark: Just going through the checks and visualization is a key part of this flow because you’re moving from text, obviously in UPF, to now inserting things into a hierarchy. It’s not checking or compiling your UPF by syntax alone, it’s applying it with the design and making sure that the two together work as intended. And because you’ll probably spend a reasonable amount of time iterating these static checks, it’s important to have a tool that provides really good visualization so you can have a good turnaround time.

STEP 2: Dynamic Checks
Ellie: Okay, now that you’ve got all your UPF structurally correct, what are you looking for?

Mark: Now we want to look at things dynamically, where it’s all about sequences of events; things following a precise order. Dynamic checks help debug those by catching illegal behavior in real-time during the simulation and flagging them for you.

If you’re doing a power up, typically you’d apply a reset before you disable or enable the clock. So you can have checks on the sequence of events, so the ordering of clock reset, applying isolation, applying retention, all those types of events can be checked with these types of dynamic checks.

Assertion-based dynamic checks are much more efficient than trying to find all those things in a waveform. You just turn these assertions on, run your simulation, and debug based on the violations in the checks. The violations that you debug lead you to the place in the waveform where you look for why the check is failing.

Figure 4: Dynamic message viewer.

Mark: When you run your simulation, you get a window like the one shown in Figure 4, which shows that an assertion fired because something didn’t get isolated properly. So then you can click on the waveform icon to get more detail.

STEP 3: Dynamic Sequencing
Ellie: So once you’ve run these automatic checks you browse through the waveforms and look at the sequences to figure out what you did wrong. What are you looking for there?

Gabriel: You’re looking to see that it behaves correctly. You return to the more traditional verification flow where you’re able to transition the design from one state to another, and, while doing so, all the portions of the design are inspected.

It’s important that your debugger indicate the stages that you’re in as you go through a power sequence. For example, in Figure 5, the waveform viewer uses red crosshatching to show where you have successfully powered down the design. This is called corruption mode, which in this context doesn’t mean something is wrong. It just means that there is no power going to or from that particular domain.

Figure 5: Power aware wave window.

Mark: Further, you need to ensure that the power sequence has enabled isolation in the right places. The Power Aware window uses a green-dot background to indicate that a particular port is now in isolation mode. Features like these help you debug the dynamic behavior of power-up and power-down and quickly identify corruption and isolation.

Ellie: What about retention? When you power down a whole set of logic, what happens when you power it back up?

Gabriel: Retention is all about preserving important state information when you power something down. When you’re debugging you want to make sure of three things when it comes to retention. You want to make sure you save your code correctly, make sure it’s been retained, and make sure it got restored correctly on power up.

Ellie: This all sounds very powerful. How do you know when you’ve properly verified everything that is in your power management?

Gabriel: For that you need coverage. What we do is turn the checkers into coverage points. When you’ve exercised all of those without any assertions firing, you know you’re good to go. You also want to make sure you’ve covered any interesting scenarios or interactions between the different power states of the design. The tool has to help you by first figuring out all the different transitions in the power states and giving you a cross-coverage view to show you how much of the different power states you’ve traversed in the design. And with those two things you get a good measure of the quality of your verification exercise.

Ellie: Thanks Gabriel and Mark! I see it’s important to understand that in low power design, you are not only unifying UPF with RTL, but also UPF is introducing your power management structures. So you need debugging capabilities that give you all the power that you have when debugging an RTL design and its behavior.

Mark: You don’t always enter a debug session thinking, well today I’m going to debug low power issues. More often than not, it’s just that you’ve got some failing tests in your regression and some strange behavior. And as you triage and debug that, it turns out that it’s a low power issue along the way. So that’s one of the benefits of having a tool that can provide you with that integrated view of your design. UPF is part of your design so the debug tool needs to show you all views. It’s not an afterthought, it’s an integrated part of your design, and you need to think it that way.

For those wanting to learn more about power management techniques and verification, check out the new whitepaper, Power Aware CDC Verification of Dynamic Frequency and Voltage Scaling (DVFS) Artifacts, which was presented at DVCon Europe 2015.