SystemC Semantics by Actors and Reduction Techniques in Model Checking Marjan Sirjani Formal Methods Lab, ECE Dept. University of Tehran, Iran MoCC 2008 Eindhoven 1

Outline of the Talk Motivation and Goal SystemC Actors and Rebeca Coordinating Actors Mapping SystemC to Actors Model Checking SystemC Designs Conclusion 2

Motivation  Integrating heterogeneous components  Increasing complexity of microelectronic systems  Demand an appropriate increase in the level of abstraction in design => using SystemC and/or Actors  Sufficient verification/validation of complex designs  High amount of effort for simulation  Demand a formal verification approach => mapping 3

Goal A model for system-level design  Modeling different levels of abstraction Software TLM RTL in a consistent manner. Closer to the application domain A tool for formal verification of system-level designs 4

Why SystemC? A standard language for modeling embedded systems at system level An object-oriented language supporting  Modularity  Concurrency  Synchronization 5

Why Actor? Actor-based design: high level of abstraction Inherent Concurrency: provided by means of concurrent actors No threads Actors: units of concurrency Event-driven computational model: message passing and event-driven execution of actors 6

Applications Models: Actors Programs: SystemC Executables Silicon Chips 7

SystemC 8

9 A system-level design language Design of the hardware and software components together at a high level of abstraction Simulation kernel manages process interactions 9

SystemC Modularity: SC_MODULE  Contains: ports, signals, variables, constructor, functions, processes Concurrency: Processes  SC_Method: atomic execution  SC_Thread: wait statements Synchronization: Events  Explicit: event of type SC_EVENT Calling notify() method  Implicit: change of the value of signals 10

11 SystemC Simulation Kernel Each simulation cycle has two phases  Evaluation Execution of the ready to run processes  Update After delta time Signal Updates Two dimension timing to implement concurrency  Physical time  Delta time 11

Actors and Rebeca 12

Traditional Actor Agent-based model, introduced by Hewitt, 1970 Developed as a concurrent object-based language by Agha, 1980 Concurrent objects communicating with each other through asynchronous message passing Actors know about the communicating partners Objects take messages from their queues and reacts to them  Do some computation  Send messages to other objects 13

14 Rebeca Language Reactive Objects Language Actor-based A Rebeca model is  Set of concurrently executing reactive objects  Interacting by Asynchronous messages

Rebeca Language Rebecs are instances of Reactive Classes Reactive Classes  A queue for messages  Message servers  State variables Rebecs are running concurrently  Take a message from the queue and execute the related message server atomically 15

Rebeca  Actor-based Inherent concurrency Units of modeling = units of concurrency Event-driven  Built for verification purposes model checking support compositional verification  Formal semantics Firm basis for verification 16

System Design Using Rebeca System components are running concurrently Considering a rebec for each component Each component knows other components to which it interacts with and directly send messages to them 17

18

19

20

21

22

Coordinating Actors 23

New Generation of Actors Keeping Actors as simple as possible Actors do not know about the scenarios which activate other actors Moving towards component-based designs Extracting coordination parts from computational parts A coordinating Actor is responsible for activating other actors 24

25

26

27

28

29

30

Actors with a Coordinator Actors: concurrent components  communicate through ports and  interact according to a common pattern of interaction System components -> Concurrent components Interaction patterns -> Component composition Component behavior and component composition are orthogonal 31

Mapping SystemC to Rebeca 32

Modules and Processes SystemC ConstructRebeca Construct ModuleReactive Class Process (method & thread)Message server Module instanceA group of rebecs 33

Signals, Ports and variable SystemC Construct Rebeca Construct SignalTwo global variables PortA local copy of the variable representing the attached signal VariableOne global variables 34

Events, Wait and Notify 35 SystemC Construct Rebeca Construct Eventa global variable of type Boolean WaitRebeca wait statement Notifyan assignment on the variable representing the event

SystemC Simulation Kernel  A specific reactive object is dedicated to handle the functionality of the simulation kernel  Becomes active when none of the other rebecs are active  Functionality:  Checking sensitivity lists to find if any of the rebecs can be activated  Updating signal values  Feeding new input to the system if all of the rebecs are still inactive 36

Model Checking SystemC Designs 37

Rebeca Model Checkers 38 SystemC Model LTL/CTL Property Sytra: Model and Property Transformer (Including KasCPar as the compiler) Rebeca Model Checker (Modere & SyMon) Model Checking Result Rebeca Model

Modere Modere: Model checking Engine for Rebeca  Direct model checker of Rebeca Generating state space based on the interleaving of all executable rebecs Provides many abstraction and reduction techniques specific for Rebeca Supports both LTL and CTL properties 39

SyMon SyMon: Systemc Model checking Engine A verification engine customized according to the behavior of SystemC simulation kernel:  Executes processes one by one, with a non- preemptive scheduling policy, according to a pre- specified order  Generating only one path of execution  Provides a significant amount of reduction in the size of the generated state space 40

Reduction Techniques: Based on SystemC Semantics Delta Cycles  Generating state space based on the interleaving of all executable rebecs N ready to run => N! states for delta cycles  Generating only one path of execution, assuming an order for executing rebecs N ready to run => N states for delta cycles 41

Reduction Techniques: Based on Rebeca Semantics Compositional Verificationn:  Abstracting environment as external messages 42

43 Abstraction Techniques: Bounded queues  Abstracting external messages  Queue length in model checking Check overflow, supported by tool Course grained interleaving  Method execution as a transition (Atomic method execution) Conventional data abstractions

44 Partial Order and Symmetry Reduction Techniques Partial order reduction  Diamond parts in the state space Symmetry reduction  Like in dining philosophers (Ring-like topologies)  The permutation relation shall preserve both rebec types and known-rebec relation.

Case studies The approach is applied on a set of case studies  D-flip flop  Shifter  Bus arbiter  Latched ALU  2-by-4 decoder  Full adder  Fibonacci generator  GCD calculator 45

A large case study: MIPS Model  SystemC A processor supporting ALU, branch and memory operators 17 concurrent threads 96 signals, events and variables  Rebeca 18 rebec 136 global variable Total number of states  Modere: exploded  SyMon:

Work in Progress: Scheduling Using Time Automata and Task Automata to verify schedulability of rebecs 47

Conclusion Define formal semantics of SystemC by means of Rebeca Model check SystemC designs  According to the semantics of simulation kernel  All interleavings 48