1. 1 of 14 TDTS07: System Design and Methodology Introduction to Lab 1 and 2 Ivan Ukhov Embedded Systems Laboratory Department of Computer and Information Science Linköping University

2. 2 of 14 2 Contacts  Petru Eles (lectures)  Office: Building B 329:220  Email: petru.eles@liu.se  Ivan Ukhov (lessons)  Office: Building B 329:228  Email: ivan.ukhov@liu.se  Adrian Horga (labs)  Office: Building B 329:198  Email: adrian.horga@liu.se

3. 3 of 14 3 Outline  Today  Organization  Lab 1  Break  Lab 2  Next time  Lab 2 (demo)  Lab 3

4. 4 of 14 4 Organization  Lab groups  Webreg groups A and B  Web page  https://www.ida.liu.se/~TDTS07  Check for detailed information and links to tutorials  Organization  2 lessons (including this one)  10 two-hour lab sessions  Lab assignments 1.Modeling and simulation with SystemC 2.Formal verification with UPPAAL 3.Design-space exploration with MPARM

5. 5 of 14 5 Organization  Choose a lab partner and sign up in Webreg  https://www.ida.liu.se/webreg3  Deadline for registration: January 31  Register as soon as possible  Deadline for labs: March 27  This is the last day for handing in (emailing) lab reports  After the deadline, your assistant will correct the remaining lab reports at his earliest convenience  Rules: Please read them (see the labs’ page)

6. 6 of 14 6 Structure 1.Modeling and simulation with SystemC 2.Formal verification with UPPAAL 3.Design-space exploration with MPARM  Each lab has a tutorial. Please read it and be prepared before you attend the lab session. We want to work efficiently during the supervised lab sessions.

7. 7 of 14 7 Examination  Written report for each lab (pdf)  Present your solution to the lab exercises  Explain your design and implementation choice in detail  Present and discuss your results  Prepare an archive with the report (pdf) and the code (where any) and email it to your group’s assistant (CC both lab partners)  Grades:  Passed  Intermediate: revise your solution and report according to your assistant’s comments

8. 8 of 14 8 Lab 1 and 2: Modeling, Validation, Verification After the system is designed:  Find out whether the system works according to its specification and correctly  Validation – Quality assurance process  “Are we building the right product?”  Simulation  Testing  Verification – Quality control process  “Are we building the product right?”  Model checking  Theorem proving

9. 9 of 14 9 Lab 1: SystemC Modeling and Simulation

10. 10 of 14 10 Simulation  Based on executable models of the system  Generate input stimuli  Permits a quick and shallow evaluation of the design quality  Good for finding bugs  Not suitable for finding subtle errors

11. 11 of 14 11 SystemC  Compare to VHDL and Verilog  Contains structures for modeling HW components and their interaction  Comes with a simulation kernel  It’s a unified HW-SW design language  What do we need to model systems?  time  modules  concurrent processes  events  channels  ports

12. 12 of 14 12 SystemC – Time  Data type sc_time (a C++ class)  Use like an ordinary basic C++ data type ( int, double )  sc_time t1(9,SC_MS);  sc_time t2 = sc_time(5,SC_SEC);  if (t1<t2) cout << t1*3 << endl << t2+t2;  Many of the standard operators are defined for sc_time  The underlying representation is based on 64-bits unsigned integer values  The representable time is limited (discrete time)  Depends on the time resolution  Default: 1 picosecond  Can be set by the user through the function sc_set_time_resolution

13. 13 of 14 13 SystemC – Modules Modules:  Basic building blocks in SystemC  Contains ports, concurrent processes, internal data structures, channels, etc.  Created with the macro SC_MODULE  Concurrent processes ( SC_THREAD or SC_METHOD )  Use wait statements to advance time (or event notification)  Sensitive to events ( sc_event ) or value changes in channels  Input and output ports to communicate with the environment

14. 14 of 14 14 Example: Adder Adder a b sum

15. 15 of 14 15 SystemC Module Example #include using std::cout; using std::endl; SC_MODULE(Adder) { sc_in a_p; sc_in b_p; sc_out sum_p; sc_event print_ev; void add_method() { sum_p = a_p + b_p; print_ev.notify(SC_ZERO_TIME); } void print_method() { cout << sc_time_stamp() << ”:Sum=” <<sum_p << endl; } SC_CTOR(Adder) { sum_p.initialize(0); SC_METHOD(add_method); sensitive << a_p << b_p; SC_METHOD(print_method); dont_initialize(); sensitive << print_ev; } }; // END Adder

16. 16 of 14 16 Generate Inputs Adder a b sum Generator

17. 17 of 14 17 SystemC – Input Generator SC_MODULE(Generator) { sc_out a_p; sc_out b_p; void gen_thread() { for (;;) { wait(1,SC_SEC); a_p = a_p + 1; b_p->write(b_p->read() + 1); } } SC_CTOR(Generator) { a_p.initialize(0); b_p.initialize(0); SC_THREAD(gen_thread); } }; // END Generator

18. 18 of 14 18 SystemC – Test Bench // Definition of an input generator (next slide) int sc_main(int argc, char *argv[]) { sc_set_default_time_unit(1,SC_SEC); sc_signal a_sig, b_sig, sum_sig; // create channels Adder adder_module(”Adder_1”); // create an instance adder_module(a_sig, b_sig, sum_sig); // connect ports to channels Generator gen(”Generator_1”); gen(a_sig, b_sig); sc_start(30,SC_SEC); return 0; }

19. 19 of 14 19 Simulation Run $./adder.x SystemC 2.1.v1 --- Dec 22 2014 16:12:32 Copyright (c) 1996-2005 by all Contributors ALL RIGHTS RESERVED 0 s: Sum=0 1 s: Sum=2 2 s: Sum=4 3 s: Sum=6 4 s: Sum=8 5 s: Sum=10 6 s: Sum=12 7 s: Sum=14 8 s: Sum=16 9 s: Sum=18 10 s: Sum=20 11 s: Sum=22.

20. 20 of 14 20 Simulator Kernel  1. Initialize: each process executed once; it’s possible to disable this phase for methods  2. Evaluate: select a ready to run process and execute/resume it; immediate notification may happen – e.notify()  3. repeat 2 until no more processes to run  4. Update: values assigned to channels in the previous evaluate cycle  5. stept 2-4 = delta-cycle; if 2 or 3 resulted in delta event notifications (e.notify(0) or wait(0)) go to 2 without advancing simulation time  6. Advance to next simulation time with pending events  Determine processes ready to run and go to 2

21. 21 of 14 21 Simulator kernel – Delta-Cycle Example //inside a process sc_signal sig_int; //assume current value //of sig_int is 0 sig_int.write(1); int value = sig_int.read(); cout << value << endl; wait(SC_ZERO_TIME); value = sig_int.read(); cout << value << endl; 0101

22. 22 of 14 22 Try the Example  You can find the example at:  /home/TDTS07/tutorials/systemc/adder  Copy it to your home directory  Two files:  adder.cc (implements the two modules + the test bench)  Makefile (helps you compile and build the program)  Type make at the command line assuming you are in the correct directory  Creates an executable adder.x  After building the example, type./adder.x to run it  Study the source code together with the tutorial

23. 23 of 14 23 Lab Assignment  Study the lab material linked from the web pages  At the end of the document you find the lab assignment  Design and implement a traffic light controller  For details: SystemC Language Reference Manual  http://accellera.org

24. 24 of 14 24 Lab 2: Formal Verification with UPPAAL

25. 25 of 14 25 Formal Methods For the levels of complexity typical to embedded systems:  Traditional validation techniques (e.g., simulation) cover a small fraction of the system behavior  Bugs found late have a negative impact on the time-to-market  A failure may lead to a catastrophe

26. 26 of 14 26 Model Checking

27. 27 of 14 27 UPPAAL Design and verification tool:  Requirements specification: computation tree logic (CTL)  Modeling: timed automata  Validation: simulation  Verification: model checking  User-friendly graphical user interface  http://uppaal.com (free for academic use)

28. 28 of 14 28 Timed Automata in UPPAAL  A timed automaton is a finite automaton augmented with a finite set of real variables called clocks  All the clocks change along the time with the same constant rate  Timing constraints can be expressed imposing conditions over clocks  The timed automata model consists of a collection of automata that operate and coordinate with each other through shared variables and synchronization labels

29. 29 of 14 29 Timed Automata — Syntax X 3 n m Clocks: X, Y a Action used for synchronization Guard = clock constraint X = 0 Reset (action performed on clocks) Y<=2Invariant

30. 30 of 14 30 Timed Automata — Example a1a2 a3 b1 b2 b3 y=1 t? ca=0 ca<=3 y=2 t! y==2 y==1 cb=0 y=2 cb>4

31. 31 of 14 31 Temporal Logics How do we specify properties for timed systems?  Logic augmented with temporal modal operators  Allow us to reason about how the truth of assertions changes over time  Used to specify desired properties of timed systems  Safety: Nothing bad will ever happen  Liveness: Something good may eventually happen  Boundedness: Something will happen within a time limit  Different forms of temporal logic  Depending on the underlying model of time  Computation tree logic (CTL)

32. 32 of 14 32 CTL: Computation Tree Logic  Based on propositional logic of branching time: it may split into more than one possible future  Atomic propositions (states in timed automata) and boolean connectors  Temporal operators:  Path quantifier  A – all computation paths  E – some computation path  Forward-time operators  G – globally  F – in the future  X – next time  U – until

33. 33 of 14 33 Computation Tree  Represents an unfolded state graph – nodes are the possible states that the system might reach  Build (infinite) computation trees from the TA model OKError OK

34. 34 of 14 34 CTL Temporal Operators p EX p p EF p p AX p p EG p p p p p AF p pp p p AG p pp p pp p p InvariantInevitable Possible Potentially global

35. 35 of 14 35 CTL Example Two properties of the system  Possible error: EF Error (True!)  Possibly globally OK: EG OK (True!)  AG OK (False!) OKError OK

36. 36 of 14 36 CTL in UPPAAL  UPPAAL has a special syntax for CTL  AF p = A<> p Always eventually p  AG p = A[] pInvariantly p  EF p = E<> pPossibly p  EG p = E[] pPotentially always p  Boolean connectives: and, or, not, imply  No nested formulas, except  A[] (p imply A<> q) = p --> q  p --> q ”If p holds in some state, then q will hold in some future state”  This construction can be used to verify one of the properties in the assignments: ”If a car arrives at the traffic light, it should eventually be granted green light.”

37. 37 of 14 37 Formal Methods Formal methods can  overcome some of the limitations of traditional techniques,  give a better understanding of the system,  help to uncover ambiguities, and  reveal new insights of the system. Formal methods do have limitations and are to complement simulation and testing, rather than replacing them.

38. 38 of 14 38 Lab Assignment  Study the lab material linked from the lab pages  In the document you will find the lab assignments as well as the requirements on the deliverables  Introductory assignments to get familiar with timed automata, CTL, and UPPAAL  Model the traffic light controller in timed automata  Simulate and verify  Implement a communication protocol  Alternating bit protocol

39. 39 of 14 39 Thank you! Questions?