Using Formal Techniques to Debug the AMBA System-on-Chip Bus Protocol

1. Using Formal Techniques to Debug the AMBA System-on-Chip Bus Protocol Author: A. Roychoudhury, T. Mitra, and S.R. Karri Speaker: Johnny Lee

2. Outline • Introduction • Related work • The AMBA bus protocol • Model checking the protocol • Conclusions

3. Bus-based SoC design • Heterogeneous functional modules are connected to a common bus • AMBA, CoreConnect • Bus protocol incorporate advanced features for high performance • pipelining, burst and split transfers

4. Bus-based SoC design (cont’d) ARM Processor On-chip RAM B R I D G E Timer Mem. Interf. AHB APB DMA bus master Keypad

5. Bus-based SoC design (cont’d) IP cores ARM Processor On-chip RAM B R I D G E Timer Mem. Interf. AHB APB DMA bus master Keypad

6. Bus-based SoC design (cont’d) • The design for these IP cores are n/a; however they are pre-validated • We still need to validate the interactions among these IP cores • These interactions are specifiedinformally in documents via timing diagrams and English descriptions

7. Outline • Introduction • Related work • The AMBA bus protocol • Model checking the protocol • Conclusions

8. Related Works • K. Shimizu and D. L. Dill • Deriving a Simulation Input Generator and a Coverage Metric from a Formal Specification • Formal specification; observer • M. T. Oliveira and A. J. Hu • High-Level Specification and Automatic Generation of IP Interface Monitor • Formal specification; monitor

9. Outline • Introduction • Related work • The AMBA bus protocol • Model checking the protocol • Conclusions

10. Bus Architecture • Several masters and slaves are connected to AHB • An arbiter decides which master will transfer data • Data is transferred in bursts • The slave to service a burst is chosen depending on the addresses (decided by a decoder) • AHB is connected to APB via a bus bridge

11. Pipelining within a Burst Writes data D1, D2, and D3 to addresses A1, A2, and A3 respectively D(i) and A(i+1) are transmitted in the same cycle

12. Wait Cycles Slave does not ready to service De-assert HREADY

13. Transfer Cancellation Slave does not able to service

14. Outline • Introduction • Related work • The AMBA bus protocol • Model checking the protocol • Conclusions

15. Model Checking the Protocol • Specify properties of the protocol in Computation Tree Logic (CTL) • φ : a boolean formula • AG φ: invariant • AX φ: all the next states • AF φ: eventually • Model check properties using Cadence SMV (symbolic model verifier) tool

16. Model Checking the Protocol (cont’d) • Checking for no-starvation • AG ( HBUSREQm  AF HGRANTm ) • HBUSREQm : masterm requests bus access • HGRANTm : mastermgranted access by arbiter • Arbiter is fair • AG ( HBUSREQm && !maskm AF HGRANTm ) • maskm is true if and only if masterm has been split and not recovered • Slave is live • AG ( splitm  AF HSPLITm ) • splitm is true if and only if the slave split masterm and not yet to service

17. Model Checking the Protocol (cont’d) • no_starve: • AG ( HBUSREQm  AF HGRANTm ) • fair: • AG ( HBUSREQm && !maskm AF HGRANTm ) • slave_live: • AG ( splitm  AF HSPLITm ) using fair, slave_live prove no_starve; assume fair, slave_live;

18. Scenario • The arbiter, 2 masters, and 1 slave • master1 transfers a two beat burst in cycle 1 and 2 • master2 gains bus access and starts a burst in cycle 3

19. Counter Example

20. Counter Example (cont’d) • In cycle 3 • mask1 = false ; mask2 = true • split1 = true ; split2 = false • This leads to a starvation of master2 • AG ( HBUSREQ2 && !mask2 AF HGRANT2 ) • AG ( HBUSREQ2  AF HGRANT2 )

21. Outline • Introduction • Related work • The AMBA bus protocol • Model checking the protocol • Conclusions

22. Conclusions • The AMBA protocol has a potential starvation scenario that arises from an incompleteness in the spec. • Formal techniques are useful in detecting subtle corner cases