Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 of 14 Lab 2: Formal verification with UPPAAL. 2 of 14 2 The gossiping persons There are n persons. All have one secret to tell, which is not known to.

Similar presentations


Presentation on theme: "1 of 14 Lab 2: Formal verification with UPPAAL. 2 of 14 2 The gossiping persons There are n persons. All have one secret to tell, which is not known to."— Presentation transcript:

1 1 of 14 Lab 2: Formal verification with UPPAAL

2 2 of 14 2 The gossiping persons There are n persons. All have one secret to tell, which is not known to the others. They are very desperate to tell their secrets and hear what the other persons know. They communicate via a two- way channel (e.g., a telephone); thus, when two persons are on the phone, they exchange the secrets they currently know. What is the minimum telephone calls needed so that each person knows all secrets?  A person should be able to call and answer (channels)  How do we represent secrets? (integer variable)  How do we communicate secrets? (global variable)

3 3 of 14 Lab 3: Design space exploration with MPARM

4 4 of 14 4 Outline  The MPARM simulation framework  HW platform  SW platform  Design space exploration for energy minimization  Communication in MPSoC  Mapping and scheduling

5 5 of 14 5 MPSoC architecture Bus ARM Interrupt Device Private Memory Private Memory Private Memory Semaphore Device Shared Memory CACHE

6 6 of 14 6 System design flow Informal specification, constraints Modeling System model Mapped and scheduled model Estimation System architecture Architecture selection Hardware and Software Implementation Prototype Fabrication ok Testing Functional simulation not ok Mapping Scheduling not ok

7 7 of 14 7 System design flow Hardware platform Software Application(s) Extract Task Graph Extract Task Parameters Optimize (Mapping & Sched) Implement Formal Simulation

8 8 of 14 8 MPARM: Hardware  Simulation platform  Up to 8 ARM7 processors  Variable frequency (dynamic and static)  Split/Unified instruction and data caches  Private memory for each processor  Scratchpad  Shared Memory  Bus: AMBA, ST  This platform can be fine tuned for a given application  Read more in:  /home/TDTS07/sw/mparm/MPARM/doc/simulator_stati stics.txt

9 9 of 14 9 MPARM: Software  C crosscompiler chain for building the software applications  No operating system  Small set of functions (pr, shared_alloc, WAIT/SIGNAL)  (look in the application code)

10 10 of 14 10 MPARM: Why?  Cycle accurate simulation of the system  Various interesting statistics: number of clock cycles executed, bus utilization, cache efficiency, energy/power consumption of the components (CPU cores, bus, memories)

11 11 of 14 11 MPARM: How?  mpsim.x -c2 runs a simulation on 2 processors, collecting the default statistics  mpsim.x -c2 -w runs a simulation with power/energy statistics  mpsim.x -c1 --is=9 --ds=10 :one processor with instruction cache of size 512 and data cache of 1024 bytes  mpsim.x -c2 -F0,2 -F1,1 -F3,3 :two processors running at 100 MHz, 200 MHz and the bus running at 66 MHz  200 MHz is the ”default” frequency  mpsim.x -h for the rest  Simulation results are in the file stats.txt

12 12 of 14 12 Design space exploration  Generic term for system optimization  Platform optimization:  Select the number of processors  Select the speed of each processor  Select the type, associativity and size of the cache  Select the bus type  Application optimization  Select the interprocessor communication style (shared memory or distributed message passing)  Select the best mapping and schedule

13 13 of 14 13  Given a GSM codec  Running on 1 ARM7 processor  The variables are:  cache parameters  processor frequency  Using the MPARM simulator, find a hardware configuration that minimizes the energy of the system Assignment 1

14 14 of 14 14 Energy/speed tradeoff CPU model

15 15 of 14 15 Frequency selection: ARM core energy 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 2.6 2.8 1 1.5 2 2.5 3 3.5 4 Energy [mJ] Freq. divider

16 16 of 14 16 Frequency selection: Total energy 8.5 9.0 9.5 10 10.5 11 1 1.5 2 2.5 3 3.5 4 Energy [mJ] Freq. divider

17 17 of 14 17 Instruction cache size: Total energy log2(CacheSize) 8.50 9.00 9.50 10.0 10.5 11.0 11.5 12.0 12.5 9 10 11 12 13 14 Energy [mJ] 2 9 =512 bytes 2 14 =16 kbytes

18 18 of 14 18 Instruction cache size: Execution time t [cycles] 5e+07 5.5e+07 6e+07 6.5e+07 7e+07 7.5e+07 8e+07 8.5e+07 9e+07 9.5e+07 1e+08 9 10 11 12 13 14 log2(CacheSize)

19 19 of 14 19 Interprocessor data communication CPU 1 CPU 2... a =1... print a ;... BUS How?

20 20 of 14 20 Shared memory CPU 1 CPU 2... a =1... print a ; BUS Shared Mem a a =2 a=? Synchronization

21 21 of 14 21 Synchronization CPU 1 CPU 2 a =1 signal(sem_a) print a ; BUS Shared Mem a a =2 Semaphore sem_a wait(sem_a) a =2 With semaphores

22 22 of 14 22 Synchronization internals (1) CPU 1 CPU 2 a =1 signal(sem_a) print a ; BUS Shared Mem a a =2 Semaphore sem_a while (sem_a==0) wait(sem_a) polling sem_a=1

23 23 of 14 23 Synchronization internals (2)  Disadvantages of polling:  Results in higher power consumption (energy from the battery)  Larger execution time of the application  Blocking important communication on the bus

24 24 of 14 24 Distributed message passing  Instead:  Direct CPU-CPU communication with distributed semaphores  Each CPU has its own scratchpad  Smaller and faster than a RAM  Smaller energy consumption than a cache  Put frequently used variables on the scratchpad  Cache controlled by hardware (cache lines, hits/misses, …)  Scratchpad controlled by software (e.g., compiler)  Semaphores allocated on scratchpads  No polling

25 25 of 14 25 Distributed message passing (1) CPU 1 a=1 signal(sem_a) BUS Shared Mem a CPU 2 print a; a=2 wait(sem_a) sem_a

26 26 of 14 26 Distributed message passing (2) CPU 1 (prod) signal(sem_a) BUS CPU 2 (cons) print a; wait(sem_a) sem_a a=1

27 27 of 14 27 Assignment 2  You are given 2 implementations of the GSM codec  Shared memory  Distributed message passing  Simulate and compare these 2 approaches  Energy  Runtime

28 28 of 14 28 System design flow Hardware platform Software Application(s) Extract Task Graph Extract Task Parameters Optimize (Mapping & Sched) Implement Formal Simulation

29 29 of 14 29 Task graph extraction example for (i=0;i<100;i++)a[i]=1;//TASK 1 for (i=0;i<100;i++) b[i]=1;//TASK 2 for (i=0;i<100;i++) c[i]=a[i]+b[i];//TASK 3    Task 1 and 2 can be executed in parallel Task 3 has data dependency on 1 and 2

30 30 of 14 30 Execution time extraction  Using the simulator  This is an ”average” execution time  Can be extracted using the dump_light_metric() in MPARM

31 31 of 14 31 Execution time extraction example (1) start_metric(); for (i=0;i<100;i++) a[i]=1;//TASK 1 dump_light_metric(); for (i=0;i<100;i++) b[i]=1;//TASK 2 dump_light_metric(); stop_metric(); stop_simulation();

32 32 of 14 32 Execution time extraction example (2) Task 1 Interconnect statistics ----------------------- Overall exec time = 287 system cycles (1435 ns) Task NC = 287 1-CPU average exec time = 0 system cycles (0 ns) Concurrent exec time = 287 system cycles (1435 ns) Bus busy = 144 system cycles (50.17% of 287) Bus transferring data = 64 system cycles (22.30% of 287, 44.44% of 144) ----------------------- Task 2 Interconnect statistics ----------------------- Overall exec time = 5554 system cycles (27770 ns) Task NC = 5267 1-CPU average exec time = 0 system cycles (0 ns) Concurrent exec time = 5554 system cycles (27770 ns) Bus busy = 813 system cycles (14.64% of 5554) Bus transferring data = 323 system cycles (5.82% of 5554, 39.73% of 813)

33 33 of 14 33 Application mapping and scheduling CPU0 CPU1 CPU2        0-2  2-4  4-5  1-3  3-5 CPU0 CPU1 CPU2 Bus = + =      dl=3 dl=6 dl=9 

34 34 of 14 34 Mapping in MPARM example if (get_proc_id()==1) { //Task 1 executed on processor 1 for (i=1;i<100;i++) a[i]=1; } if (get_proc_id()==2) { //Task 1 executed on processor 2 for (i=1;i<100;i++) b[i]=1; }  Using the lightweight API of MPARM  get_proc_id()

35 35 of 14 35 Scheduling in MPARM  The schedule is given by the code sequence executed on one processor //task 1 for(i=1;i<100;i++)a[i]=1; //task 2 for(i=1;i<100;i++)b[i]=3; //task 2 for(i=1;i<100;i++)b[i]=3; //task 1 for(i=1;i<100;i++)a[i]=1; Schedule 1 Schedule 2

36 36 of 14 36 Assignment 3: Mapping and scheduling  Theoretical exercise (you will not use MPARM)  Task graph and task execution times are given  Construct 2 schedules with (same) minimal length:  keeping same task mapping  changing the mapping

37 37 of 14 37 Thank you! Questions?


Download ppt "1 of 14 Lab 2: Formal verification with UPPAAL. 2 of 14 2 The gossiping persons There are n persons. All have one secret to tell, which is not known to."

Similar presentations


Ads by Google