Automatic compositional reasoning for probabilistic model checking of hardware designs

1. Automatic compositional reasoning for probabilistic model checking of hardware designs Jayanand Asok KumarandShobha Vasudevan Electrical and Computer Engineering University of Illinois at Urbana-Champaign

2. Stochastic nature of hardware • Sources of variations • Random data, transient physical faults, process variations • Variable hardware delay can result in incorrect latching of values • Traditional hardware verification (non-probabilistic) “Does the hardware always provide correct input/output functionality ?” • Cannot provide quantitative measures of “correctness” We incorporate statistical reasoning into the high-level hardware verification paradigm

3. Probabilistic verification of hardware • We employ probabilistic model checking (PRISM tool) “What is the probability that the hardware provides correct input/output functionality?” • Quantitative performance estimates can be obtained • Eg: “Probability [Delay of a block < Specified time constraint]?” • Feasible only for systems withless than1010 states We present a compositional reasoning approach for probabilistic model checking of hardware systems

4. Compositional reasoning • “ Probabilistic hardware model M satisfies property Φ ?” • Previous work in compositional reasoning • Significant manual effort in obtaining (M1 , Φ1)and (M2 ,Φ 2) Our compositional reasoning technique is fully automatic

5. Our approach

6. Design source code • Register Transfer Level (RTL) designs • Behavioral description of functionality • Data is represented as variables in the “program” module (I1,I2,I3,I4,O1,O2,O3) input [9:0] I1,I2,I3,I4; wire [9:0] Z1,Z2,Z3,Z4; output [9:0] O1,O2,O3; always @(posedge clk) begin Z1 <= I1; Z2 <= I2 - I3; Z3 <= I3 + I4; Z4 <= I3 & I4; O1 <= Z1 | Z2; O2 <= ~Z3; O3 <= Z4; end • In the example • 10-bit variables (210 possible numeric values) Input variables Temporary variables Output variables Rising edge of clock = Next time step <=: Assignment LHS at t +1 = RHS evaluated at t

7. Statistically distributed data • Assumptions on input variables ( I) • Statistically independent • Probability distributions are known to us • Probability distributions are stationary (i.e. do not change over time) • Probability distribution (PMF) of a variable v? • Propagate PMFs from the inputs • Need a “formula” for evaluation ofv as a function of input values • For each v, we derive • Sup(v) is the supportof v • fis the system function for v We formally represent the statistical behavior of a design

8. Statistical model • We use Discrete Time Markov Chains (DTMCs) • Define DTMC M for the set of variables Π • Πis the set of observables of M DTMC for v State variables S =Sup(v) State µ State µ’ An assignment of values to Sup(v) New values assigned to Sup(v) 1 clock cycle = 1 transition Joint probability of Sup(v)

9. Property specification • Performance metrics are data-dependent • Can be expressed in terms of hardware variables (eg: Delay = fP(Π)) We check M satisfies Φusing PRISM Probabilistic invariant where fP is real-valued function, c is a real-valued constant Property where p is a real-valued constant in [0,1]

10. Propagate PMFs from inputs • For each variable v in Π • Obtain the support Sup(v) • Derive the system function f(Sup(v)) • In the example • ConsiderΓ : P[(O1 + O2 + O3) ==100] • Π = { O1, O2, O3}

11. Static analysis Z1 <= I1; Z2 <= I2 - I3; Z3 <= I3 + I4; Z4 <= I3 & I4; O1 <= Z1 | Z2; O2 <= ~Z3; O3 <= Z4; • Traverse the RHS of assignments statement, transitively • Stop when primary inputs are reached Sup(O1) = {I1, I2, I3} Sup(O2) = {I3, I4} Sup(O3) = {I3, I4} DTMC model: S = {I1, I2, I3, I4}

12. Obtaining the components: M1,M2

13. Structural decomposition Partition observables In the example: M2 M1 Ψ= {I3} Π1 = {O1} Π2 = {O2, O3}

14. Obtaining the properties: Φ1 ,Φ2

15. Value-based case splitting Conditional PMF • Constrain M1 : Assign numeric value of Cto Π1 • Each caseC= An environmental constraint for M2 • PMF of Ψ is conditioned on Π1/.C • Augmented model M2’ = (M2 + updated PMFs ofΨ) In the hardware domain, the number of cases is finite M2’ Γ: P[ fP (Π1, Π2)= = c] Substitute Π1with C Π1/.C Γ1= P[ Π1 /.C] Property Φ1 Γ2’= P[ fP(C, Π2)= = c] Property Φ2 Consider all possibleC

16. Assume-guarantee reasoning

17. Assume-guarantee reasoning • ComputeΓ12 • In the example Γ : P[(O1 + O2 + O3) ==100] Π1 = { O1}, Π2 = {O2, O3} Γ2’= P[(5 + O2 + O3) = = 100] (Consider the caseC=5 ) Γ1 = P[O1/.5]210=1024 total cases Composing the invariants

18. Correctness of our approach Equivalent • Proof sketch • Sufficient to show that Γ12 =Γ • Rewrite the conditional probability expressions for Γ12 • Use “Law of total probabilities”

19. Case study: Ripple-carry adder • fP is separable • Each case is a numeric value of hP(Π1), instead of Π1 (Abstraction) • Only 17 cases, instead of 232 • Required Invariant: P[fP(ripples) < T] • ripples: length of carry chain

20. Experimental results • Without decomposition, ~1020 states in DTMC • System runs Out of memory • Our technique can be applied recursively • Tradeoff • Size of component DTMCs vs. Number of cases • Other hardware designs and performance metrics • Communication systems (Bit Error Rate) • Microprocessor (Soft Error Rate)

21. Summary • Automatic compositional reasoning approach for probabilistic model checking of hardware designs • Approach is sound and applicable to different types of hardware designs and performance metrics • Future work • Optimize decomposition for the size of interface variables • Automatic detection and exploitation of case symmetry