Breaking The Three Laws


Verifying Power Management Modes, both Software and Hardware

Quote: “It works! After disabling power management for my WiFi stick in Raspberry PI configuration it is now working!!”

Raspberry PI image

BTW: This blog was inspired by a true story of a challenge that Achim Nohl, Technical Marketing Manager for HAPS Physical Prototyping recently experienced:

Power management is an increasingly complex function provided by hardware and controlled by a large extent by software. The software is orchestrating the power-up and power-down sequence of the SoC’s subsystems and peripherals in various scenarios such as cold boot, warm boot, resume, hibernate etc. These scenarios involve multiple software layers such as firmware, boot loader, operations system and user space software. The interaction between those layers, which often reside in different privilege modes (aka exception levels), is complex and prone to errors due to the variety of scenarios, conditions and distributed ownership of the software modules in different teams and 3rd party or open source.

Testing this software power management prior to silicon is a huge concern but, the same concern is with the hardware designers as it’s the software that controls most of the hardware operation. The complexity of software power management is mirrored in the hardware through complex clock-/power-management units, a growing number of power domains and the required logic for retention and isolation functions. While the power-off sequence in software is a coarse grain level for the power domains, the power gating (PG) sequence in hardware is a complex fine grain control of isolation, retention, voltage and clocking. Before a power domain can be powered off after shutting down the clock, the outputs need to be isolated to prevent floating signals to propagate to neutral power domains. Certain flops may need to keep their state during power gating using retention cells after isolation has happened. Only then, the voltage VDD can be safely removed, keeping the lower retention voltage VSS, which levels have been programmed via software using a PMIC (Power Management IC). A lot can go wrong here and a flaw may just be exposed under very specific conditions during field operation. That is why we are seeing so many answers like this in user forums. “It Works!! Disabling the power management of my Wifi chipset solved my instability problem”. Whoops, a bug got through somewhere, could be software, could be hardware but we don’t know for sure. What we do know is that the bug only showed itself when power management is active.

In order to address the important and urgent need to verify and validate hardware and software power management functions prior to silicon designers have turned to physical prototyping. The power management software can be executed against the power management hardware before you commit to silicon. Of course you can only do this if your physical prototyping solution supports modeling of the power management hardware. The HAPS physical prototyping solution enables support for those power management use-cases. Compared to traditional FPGA synthesis targeting FPGA as the final product, HAPS ProtoCompiler is able to understand the hardware power intent from UPF (Universal Power Format) specification and translate this into the required logic for prototyping power management. UPF is the IEEE standard for describing the power supplies, power states, retention etc. and separated from the RTL description of the design.

Low power intent view in ASIC

Typically, this is not something you are concerned as an FPGA implementer and that is why synthesis tools for FPGA implementation do not support it and provide power management solutions very different than the ones for ASIC implementation. Since HAPS ProtoCompiler has a different objective, which is the validation of ASIC hardware and software under real world conditions, UPF is an integral part of the HAPS prototyping flow. For this purpose HAPS ProtoCompiler goes beyond translating UPF into a neltlist for the FPGA and enables new techniques which allow more and targeted testing of power management functions. Fro example the flow enables the isolation and retention logic to be prototyped, in addition, dedicated capabilities enable corruption of sequential elements when the power domain is shut off to better reflect what the final SoC would experience. This way, HAPS ProtoCompiler increases the test coverage for the crucial isolation and retention logic.

Low power modes modeled through ProtoCompiler for HAPS

Not testing power management software and hardware is risky as it leaves a gap in the pre-silicon validation. HAPS with HAPS ProtoCompiler enables power management capabilities to be verified based on a standard UPF flow.

Look out for a new blog starting soon: This blog will discuss both Virtual and FPGA-based Prototyping

To SUBSCRIBE use the Subscribe link in the left hand navigation bar.

  • Print
  • Digg
  • StumbleUpon
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn