Model Checking of Global Power Management Strategies
in Software with Temporal Logic Properties
Rajdeep Mukherjee
Indian Institute of Technology Kharagpur
Subhankar Mukherjee
Samsung India Software Operations
Pallab Dasgupta
Indian Institute of Technology Kharagpur
ABSTRACT
Complex and sophisticated power management strategies are a commonplace design policies today in order to man-age the power consumption of complex low power digital integrated circuits. These global power management strate-gies are implemented in software/firmware and are used to orchestrate the switching between power states of multiple power domains in local power controllers which resides in hardware. In this paper, we propose a methodology of ver-ifying such global power management softwares with safety linear temporal logic (LTL) properties using bounded model checking based verification approach. We present our results on several test cases of significant complexity to demonstrate the feasibility of the proposed framework.
Categories and Subject Descriptors
D.2.8 [Software Engineering]: Software/Program Verifi-cation—Model Checking
General Terms
Embedded Software, Verification
Keywords
Power Intent Verification, Assertion, Bounded Model Check-ing, Temporal Logic
1.
INTRODUCTION
The rise in the use of embedded systems over the last decade has forced the developers to integrate embedded soft-ware in such systems in a rapid way. Thus the need of formally verifying the embedded software is of fundamen-tal importance in the present scenario in order to ensure the correctness of the functionality of embedded systems. However, when a large software design is considered, formal property verification using model checker often suffers from the state space explosion problem. The main challenge for
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
ISEC ’13, Feb. 21-23, 2013 New Delhi, India
Copyrightc 2013 ACM ISBN 978-1-4503-1987-4 ...$15.00.
any embedded software is in verifying the temporal proper-ties over the variables and functions of the software mod-ule. The authors of [18] proposed two new approaches to integrate assertions for verifying embedded software using simulation-based verification.
In the domain of low power embedded system design, the task of verifying that the implementation of the power do-mains and the architectural power management logic meets the micro-architectural specs has become important. This has prompted the design community to adopt standards like Unified Power Format (UPF) [17] and Common Power For-mat (CPF) [1] for specifying the power domains and their control points at a higher level of abstraction. The power management fabric is broadly divided into the controllers for the individual power domains and the global power man-agement logic which orchestrates the power state transitions in the local power domains. The global power management logic is responsible for implementing the architectural power management strategy, but the per-domain controllers speci-fied using UPF and CPF control analog interfaces, like level shifters.
A recent research work has attempted to leverage per-domain UPF / CPF specifications for translating architec-tural power intent into assertions for enabling formal verifi-cation of the global power management logic [8]. Our work developed on the same approach, but with an important dif-ference, namely, that the global power management logic is specified in software, as opposed to the assumption in [8] that the logic is in hardware. The significance of our contri-bution is based on the fact [11] that most recent designs use a combination of software and micro-instructions in firmware to implement the global power management logic, and it is increasingly likely that in future this trend will become ubiquitous. The work of [16] models the synchronization between the software which implements the global power management logic with the per-domain controllers that are implemented in hardware. It then verifies the composition of the software and hardware power managers against the architectural power intent.
There are several important differences in verifying a power management fabric that is partially controlled by software / firmware, as opposed to ones that are implemented solely in hardware. Typically global power management (GPM) soft-ware is driven by softsoft-ware/hardsoft-ware interrupts. For exam-ple, if an interrupt comes then the GPM executes a sequence of instructions in order to determine the next state of itself as well as the local power managers. The task of the GPM is to determine the global power management strategies and
provide directives to the local power managers (LPM) (typi-cally in hardware) which are responsible for actual execution of these strategies into hardware.
Our objective in this paper is to model such software power management units by capturing the execution seman-tics in terms of the interrupts that drive the software, spec-ifying the architectural intent (safety requirements) of the power management strategies in terms of these interrupt, and formally verifying the architectural intent on the soft-ware using state of the art formal softsoft-ware verification tech-niques.
An incorrectly implemented global power controller might issue illegal power state transition sequence and GPM di-rectives thereby violating the desired power-intent. It is therefore imperative to consider the timing and functionality of the GPM software in verification. Thus the verification of the global power management strategies in software is important in guaranteeing the functional correctness of the directives that it issues over the entire power-management fabric. The main contributions of this paper are as follows: 1. We allow the specification of the global power
manage-ment strategy in a procedural language like C. 2. Given the LTL properties capturing architectural power
intent, we automatically translate the temporal logic properties into safety properties of given depth using unfolding technique.
3. The GPM software is automatically instrumented with the assertions generated in step 2.
4. The instrumented code is then passed to the CEGAR loop for model checking the GPM software against the safety properties.
2.
RELATED WORK
In the past, LTL [19] has been the most acceptable logic for describing temporal properties in the model checking en-vironment such as SPIN [10]. Assertion-based verification methodology is useful for hardware verification technique [7]. However, this technique of verification is not suitable for ver-ifying embedded software which contains complex program-ming constructs like complex data types, pointers, recursive functions etc. and has no notion of timing behaviors.
The crux in the verification of embedded software lies in monitoring the valuation of the program variables, func-tions, conditional loops and complex pointer handling based on temporal property specification. Formal methods prove to be efficient for verifying temporal properties over medium sized embedded software. However, for larger software de-sign, an abstraction technique is used in order to avoid the state-explosion problem for the back-end model checker. The tool named BLAST [9] verifies temporal safety proper-ties on software using predicate abstraction technique. BLAST uses Counter-Example Guided Abstraction Refinement (CE-GAR) framework for model checking software. It iterates the whole process by first constructing an abstract model of the software based on predicates, then checks the safety properties, and if the property fails, it refines the model based on the counter-example. The software model check-ing approaches can be categorized as follows:
1. Bounded Model Checking(BMC) [3] based verification
2. Predicate abstraction based model checking using a theorem prover or SAT solver [9, 4, 2]
3. Modeling the semantics of the software using suitable abstraction technique and then verify the abstract model using BDD-based and SAT-based model checkers. The tool CBMC [5] performs the formal verification of ANSI-C programs using bounded model checking based ap-proach. However, the boundedness restricts the tool for proving the correctness of the software. Therefore, the veri-fication of temporal properties of embedded software is still a challenge for the verification community.
A low-power digital integrated circuit can be viewed as the composition of several individual power-domains consti-tuting the design, a set of power control circuitry (PCC), and the power control logic(PCL). PCC provides a power control interface which is driven by the PCL so as to make power state transitions within the power managed domain. A PCC consists of various isolation cells, retention cells, level shifters and voltage regulators. Further, PCL can be decomposed into two separate power managers for larger cir-cuits, namely thelocal power manager(LPM) and theglobal power manager(GPM). LPM’s are mainly per-domain local power managers which issues valid control signals to the cor-responding power domain so as to make a valid power state transition. The GPM implements various global power man-agement properties. It orchestrates the LPM’s to implement the architectural power management strategy. The architec-tural view of such power management logic is popular among architects [12, 13]. Figure 1 shows the architectural compo-nents of a low-power digital integrated circuits.
LPM 2 LPM 4
Global Power Manager
UPF 2 UPF3 UPF 4 PD 4 PD 1 PD 3 PD 2 UPF 1 LPM 3 LPM 1 PCC 4 PCC 1 PCC 2 PCC 3
Power Control Logic (PCL) Global Assertions Architectural Power intent Predicate Table
Design Partitioned into Power Domains(PD)
Figure 1: Architectural Power Managed Design Component
The architectural power management strategies are usu-ally specified by architects using names of architectural power domains and their power states. However, the PCC are driven by low level control signals from PCL which are used to perform actions like isolation, retention as well as specific power state transitions inside the power domains. The re-cent work of [8] addresses the issue of bridging the existing disconnection between the high level architectural properties
and low-level control signals over which the PCL is defined, and performs the formal verification of the Power Control Logic(PCL) at the register transfer level.
In [8], all controllers are given in Verilog and so it is im-plemented using standard model checkers from the hardware domain. In our problem the global power management logic is in software and the local controllers are in Verilog. Hence we propose a verification framework for the purpose of veri-fying the correctness of the global power management logic against the architectural power intent.
Software-based power management strategy tries to ex-ploit explicit power management hooks provided by the un-derlying architecture that are of particular interest to a software at higher level in an intelligent manner. Power management software employs efficient algorithms to ensure that the system and devices maintains low power state as long as possible without degrading system performance. In order to make maximum utilization of the CPU, modern day operating system like Linux implements dynamic volt-age and frequency scaling (DVFS) based on the system’s utilization via heuristic algorithms. Recently, Intel’s Ne-halem microarchitecture uses a dedicated on-die microcon-troller [11], called the power control unit (PCU) that runs embedded firmware, used for making power management decisions based on global inputs like temperature, current, power and OS requests. Thus, the migration from hardware to firmware / software based power management in mod-ern day processors provides efficient platform for managing system’s power.
3.
FORMAL MODEL
The GPM software is triggered by software/hardware in-terrupts. On waking up, the GPM issues one or more direc-tives and goes back to sleep. The direcdirec-tives are executed by the local controllers to actuate the power state transitions. Our objective is to verify architectural assertions over the global power management software. The GPM software is used to implement the overall power management strategies of the embedded system and orchestrate the switching be-tween power states of multiple power domains in local power controllers. Unlike conventional software verification tech-niques, the main aspect of verifying the power management software lies in the fact that the program states (comprising valuation of the program variables and program locations) and the power states defining the per-domain power states are two different entities. The architectural properties are specified relating the power states and its transitions.
In order to formally capture the execution semantics of the GPM, we model the interrupts that drive the GPM with a single clock, that is the time period between any two con-secutive interrupts define a time cycle. Figure 2 depicts the scenario for a typical GPM software. We take an example in English language describing a typical safety requirement. The architectural assertions are defined over the GPM power state and may be used to capture the temporal nature of the power management behavior. With the GPM software exe-cution model described in this section, it is possible to en-code the above requirement using a temporal logic property as follows:
For example, let us consider an architectural property comprising three power domains namely CORE, MEMORY and TRANSMITTER. The properties may be temporal in nature in order to capture the architectural power intent or
GPM_STATE LPM_3_STATE LPM_2_STATE LPM_1_STATE LPM_1_STATE (NEW) LPM_3_STATE (NEW) LPM_2_STATE (NEW) GPM_STATE (NEW) GPM Instruction 2 Instruction 3 Instruction 1 ... ... ... Interrupt
Figure 2: GPM execution model
it may be safety properties as well.
1. Property 1: We may be interested to verify a temporal property which specifies that :
Once the MEMORY domain is ON, the TRANSMIT-TER domain has to be ON within 1 to 2 cycle. The property can be encoded as follows:
G(M_ON_T_OFF -> F[1:2] M_ON_T_ON)
2. Property 2: Global safety properties may also be used to capture power management strategies which speci-fies that :
CORE and TRANSMITTER domains are never ON together.
The property can be encoded as follows:
G(C_ON_T_OFF ∧ C_OFF_T_ON ∧ C_OFF_T_OFF)
4.
VERIFICATION FRAMEWORK
Let P D be the total number of power domains and M
be the total number of states. Then, we haveN = log2M
number of state variables. The inputs of the system are as follows:
1. Software code of the Global Power Manager (GPM) 2. GPM specification as a set of Temporal Logic
proper-ties (ϕi,j) encoded in terms ofN state variables
{S0, S1, ..., SN−1}.
We useϕi,j to denote that ϕis true at theithtime step
andϕis to be unfolded further forj time steps. We inter-changeably useϕito denoteϕi,0, that isϕis true at theith
time step and is not unfolded further.
4.1
Procedure
For performing the verification task we unfold the LTL properties upto certain depth (either determined from the properties if they are bounded or chosen by the verification engineer) in order to express them as safety properties of the software. This is facilitated by maintaining state infor-mation up to the chosen depth. The steps of the proposed approach shown in Figure 3 work as follows.
1. We storej-depth of state information. Thus, we need to expand the propertyϕuptoj-depth.
Instrumented
Software Software Global Power Manager
MODEL CHECKER Verification Report Falsified Verified LTL Properties Verification Framework Safety Reachability Property Unfolding
Figure 3: Work Flow of Proposed Method
(a) pi,j ≡ piwherepis an atomic proposition.
(b) (¬ϕ)i,j ≡ ¬ϕi,j
(c) (ϕ1∧ϕ2)i,j ≡ (ϕ)1i,j∧(ϕ)2i,j (d) (Xϕ)i,j ≡ϕi+1,j−1
(e) (ϕ1Uϕ2)i,j ≡ ϕ2i,j∨(¬ϕ2i,j∧ϕ1i+1,j−1∧ϕ2i+1,j−1)∨ (¬ϕ2i,j∧ϕ
1i,j∧¬ϕ2
i+1,j−1∧ϕ
1i+1,j−1∧ϕ2i+2,j−2)∨
... jtimes
It is to be noted that after unfoldingϕbecomes Boolean properties over the set of Boolean variables
j
[
k=0
{Sk
0, S1k, ..., SkN−1}.
3. Whenever some state change takes place in the GPM software due to the arrival of specific interrupt sig-nals, the unfolded safety assertions are automatically instrumented inside the controller.
4. The instrumented code is then passed to the CEGAR framework to verify for the reachability of the embed-ded safety properties.
4.2
Example
The verification and the working of the GPM software with respect to architectural intent can be described by the following example.
Consider the following LTL property:
ϕ ≡ F(X(s))
Suppose, we unfoldϕat theithtime instance upto a depth
d= 3 as follows. ϕi,3≡(F(X(s)))i,3 ≡(Xs)i,3∨((¬Xs)i,3∧(Xs)i+1,2)∨ ((¬Xs)i,3∧(¬Xs)i+1,2∧(Xs)i+2,1)∨ ((¬Xs)i,3∧(¬Xs)i+1,2∧(¬Xs)i+2,1∧(Xs)i+3,0) ≡si+1∨(¬si+1∧si+2)∨(¬si+1∧ ¬si+2∧si+3)∨(¬si+1∧ ¬si+2∧ ¬si+3)
We save 4 levels of state bits {S0, S1, S2, S3} in order to encode the LTL property in terms of safety property. The
corresponding safety (for everyi) Boolean assertion equiva-lent toϕ(only upto a depth of 3) is:
ϕ3 ≡ S1∨(¬S1∧S2)∨(¬S1∧¬S2∧S3)∨(¬S1∧¬S2∧¬S3) Let us now consider the semantics of the global power management controller software. When the program is in a particular power state and some external interrupt arrives, the power management strategy determines the next state and the signals asserted during the process. Each state of the global power manager controller corresponds to the set of states of the individual local power managers. Our GPM software has the following form:
int state; void controller() { ... while (state_change_interrupt) { ... state = new_state; ... } }
The global controller is instrumented with the unfolded safety properties. The update saved state information() pro-cedure maintains state information upto certain depth of the temporal property which is either determined by the prop-erty if they are bounded or specified by the verification en-gineer. The instrumented code is as follows:
int state; int S0, S1, S2, S3; void controller() { ... while (state_change_interrupt) { ... state = new_state; update_saved_state_information(); //- state change takes place :: unfolded assertion is inserted
-S1 || (!-S1 && S2) || (!-S1 && !S2 && S3) || (!S1 && !S2 && !S3);...
} }
4.3
Case Study
In order to outline the syntax for specifying the global power management (GPM) logic, we consider an example consisting of three power domains, namely CORE, MEM-ORY and TRANSMITTER. The GPM description starts with an enumeration of the power states of the design:
enum STATE {
ST0, //Core-Off, Trans-Off, Mem-PartiallyOn ST1, //Core-Off, Trans-Off, Mem-FullOn ST2, //Core-StandBy, Trans-Off, Mem-PartiallyOn ST3, //Core-Active, Trans-Off, Mem-FullOn ST4, //Core-Off, Trans-Low, Mem-FullOn ST5, //Core-Off, Trans-High, Mem-FullOn };
The following C code snippet for the GPM logic imple-ments the following aspect of the power management strat-egy:
On getting an interrupt signal, the GPM drives a transition from ST0 to ST2while retaining the
same state for other two domains. It also drives a transition from ST0 to ST1 if either of the fol-lowing two conditions hold:
[(finish && setbit)∨ (!finish && signal_transmit)]
The GPM retains the same state if none of the above conditions occur.
GPM_core_mem_transmitter() {
const enum STATE curSt; int interrupt_new, setbit_new,
signal_transmit_new, signal_str_new ; // Output of GPM if(curSt == ST0)
{
interrupt_new = interrupt; //saves initial configuration setbit_new = setbit; signal_transmit_new = signal_transmit; if(interrupt == 1) { setbit_new = 0; signal_transmit_new = 0; state = ST2; // Transition :: ’ST0 - ST2’ }
else if( (finish && setbit) || (!finish && signal_transmit)) {
if(finish && setbit) {
signal_transmit_new = 0; signal_str_new = 1; }
if(!finish && signal_transmit) { setbit_new = 0; signal_str_new = 1; } state = ST1; // Transition :: ’ST0 - ST1’ } else { signal_str_new = 1; finish_new = 1; state = ST0; // Transition :: ’ST0 - ST0’ } } } // end module
The signalsinterrupt, setbit, signal transmit, andfinishare inputs to the GPM. These variables are modified by oper-ating system events or by hardware events. The variables
curStandstatecontain the current state and the next state values respectively. Writing thestatevariable acts as a di-rective to the local per-domain power controllers to change the power states to match with this variable. Let us consider the following bounded LTL property [6].
G((ST2 -> F[0:2] ST1) ∨ (ST3 -> F[1:2] ST0))
Since this is a safety requirement, so the unfolding of the property into safety property is shown as follows. The state level information in each iterationiof the GPM execution is updated and captured using the variableL i.
( (( L_0 == ST2 ) && ( L_0 == ST1 )) || (( L_0 == ST2 ) && ( L_1 == ST1 )) || (( L_0 == ST2 ) && ( L_2 == ST1 ))) || ((( L_0 == ST3 ) && ( L_1 == ST0 )) || ((( L_0 == ST3 ) && ( L_2 == ST0 ))))
These assertions are automatically instrumented inside the GPM software and the level informations are updated whenever some state change takes place.
Primary Integer Unit
6 − Port Register File
PD6 I − Cache Cache Controller Memory Controller Multiplication PD3 Interrupt Port Division Unit PD4 Main Memory AHB interface Secondary Integer Unit PD 2 PD 1 PD7 Superscalar Controller PD 5 IRQ D−Cache 15
Figure 4: Power Domains of eleon3 processor
5.
EXPERIMENTAL RESULTS
In this section, we present experimental results on six test cases, namely PowerTrans, PowerCounter, Promethues and low-power Enhanced Leon3 benchmarks [14, 15], namely, eLeon3-SingleCore, eLeon3-DualCore and eLeon3-QuadCore. We have used Linear Temporal Logic (LTL) to express the temporal safety architectural properties and invoked SA-TABS [4], a verification tool for ANSI-C and C++ programs, to perform the model checking of the GPM software. The results presented in this section are performed on a 2.33 GHz INTEL(R) XEON(TM) CPU with 16 GB RAM.
Figure 4 shows the different power domains of the single-core eleon3 processor, namely primary integer unit, a sec-ondary integer unit, a multiplication unit, a division unit, a memory controller unit, a cache unit,and astorage elements unit. Each domain has its own power modes, like ACTIVE, IDLE, OFF, FULL ON and PARTIAL ON, as decided by the architects. These power states are further specified using three flags, namelyvoltage,frequency,biasflag. There also exists potential transient states between the off state and on state of a power domain, namely Isolation, Retention, or between twoon statesby changing the voltage-frequency pair in particular order.
The GPM design details for various benchmark circuits are summarized below in Table 5. Column 2 denotes the size of the global power manager in terms of number of lines of code. The number of power states present in each global power manager of the power control logic is listed in Column 3. We also report the verification results using the Model checking tool SATABS [4] in Table 5. Column 4 denotes the number of global assertions. The maximum unfold depth among all global architectural properties is reported in Col-umn 5. ColCol-umn 6 shows the verification time and ColCol-umn 7 reports the memory usage by the proposed methods.
6.
CONCLUSION
This paper demonstrates the verification of global power management strategies implemented in software with re-spect to safety LTL properties using reachability analysis. The LTL properties are automatically translated into safety properties of a given depth and the generated assertions are automatically instrumented inside the GPM software. The instrumented code is then passed to the CEGAR frame-work for model checking the GPM software with respect to safety properties and thereby ensuring the correctness of the global power management strategies in software. Thus, the proposed verification framework is suitable for proving the
Table 1: Results Demonstrating GPM Design Details And Verification Time
No. of Number No. Maximum Verification
Design Lines of of Unfold Time Memory Name of code states assertions Depth (sec) (MB)
PowerTrans 373 6 5 10 136.15 14.91 PowerCounter 348 8 5 14 68.72 15.36 Prometheus 279 11 5 18 57.44 12.57 eLeon3-Singlecore 2670 17 5 12 913.83 24.49 eLeon3-Dualcore 7462 38 5 8 2735.04 56.8 eLeon3-Quadcore 9632 42 5 8 3387.74 66.4
correctness of the embedded software against the temporal architectural assertions and the experimental results on em-bedded power management strategies for ELEON processor shows the feasibility of the proposed verification approach.
7.
REFERENCES
[1] Power forward, a practical guide for low power design - an experience with cpf. [available] online:
http://www.powerforward.org/, 2008.
[2] T. Ball, V. Levin, and S. K. Rajamani. A decade of software model checking with slam.Commun. ACM, 54(7):68–76, 2011.
[3] A. Biere, A. Cimatti, E. M. Clarke, O. Strichman, and Y. Zhu. Bounded model checking.Advances in Computers, 58:117–148, 2003.
[4] E. Clarke, D. Kroening, N. Sharygina, and K. Yorav. Satabs: Sat-based predicate abstraction for ansi-c. In
Proc. of TACAS, pages 570–574, 2005.
[5] E. M. Clarke, D. Kroening, and K. Yorav. Behavioral consistency of c and verilog programs using bounded model checking. InProc. of DAC, pages 368–371, 2003. [6] P. Dasgupta.A Roadmap for Formal Property
Verification. Springer-Verlag New York, Inc., Secaucus, NJ, 2006.
[7] H. Foster, A. Krolnik, and D. Lacey.Assertion-based design (2. ed.). Kluwer, 2004.
[8] A. Hazra, S. Goyal, D. P., and A. Pal. Formal verification of architectural power intent.IEEE Transactions on VLSI Systems, 21(1):78–91, 2013. [9] T. Henzinger, R. Jhala, R. Majumdar, and G. Sutre.
Software verification with blast. InProc. of SPIN, pages 235–239, 2003.
[10] G. J. Holzmann. Logic verification of ansi-c code with spin. InProc. of 7th International SPIN Workshop, pages 131–147, 2000.
[11] Intel and C. i7 (Nehalem) Dynamic Power Management. [available] online: impact.asu.edu/cse591sp11/nahelempm.pdf. [12] C. Isci, A. Buyuktosunoglu, C. Cher, P. Bose, and
M. Martonosi. An analysis of efficient multi-core global power management policies: Maximizing performance for a given power budget. InProc. of MICRO, pages 347–358, 2006.
[13] A. Lungu, P. Bose, D. J. Sorin, S. German, and G. Janssen. Multicore power management: Ensuring robustness via early-stage formal verification. InProc. of MEMOCODE, pages 78–87, 2009.
[14] K. Marcinek, A. W. Luczyk, and W. A. Pleskacz. Enhanced leon3 core for superscalar processing. In
Proc. of DDECS, pages 238–241. IEEE Computer Society, 2009.
[15] K. Marcinek, A. W. Luczyk, and W. A. Pleskacz. Enhanced leon3 low power ip core for dsm technologies. InProc. of MIXDES, pages 262–265, 2009.
[16] R. Mukherjee, P. Dasgupta, A. Pal, and S. Mukherjee. Formal verification of hardware / software power management strategies. InProc. of 26th International Conference on VLSI Design, 2013.
[17] R. Mukherjee, A. Srivastava, and S. Bailey. Static and formal verification of power aware designs at the rtl using upf. InProc. of DVCon, pages 42–47, 2008. [18] P. Nalla, J. Ruf, T. Kropf, W. Rosenstiel, and
T. Kirsten. Verification of temporal properties in automotive embedded software. InProc. of DATE, pages 164–169, 2008.
[19] A. Pnueli. The temporal logic of programs. InProc. of 18th IEEE Symposium on Foundations of Computer Science, pages 46–57, 1977.
