Doğan Fennibay MS Thesis Presentation - June 7th, Supervisor: Assoc. Prof. Arda Yurdakul

Transcription

1 Doğan Fennibay MS Thesis Presentation - June 7th, 2010 Supervisor: Assoc. Prof. Arda Yurdakul

2 Motivation System-level Modeling More integrated systems HW & SW modeled together Models larger but more abstract Component-based strategies Trends in embedded systems More connected with others Increasing use of off-the-shelf components Real/implemented components become important for developing models Slide Fennibay Hardware-in-the-Loop (HiL) DO NOT model real subsystems Integrate real and virtual worlds Avoid modeling complex systems Avoid modeling effort for implemented/ off-the-shelf components Increase modeling accuracy More realistic test beds

3 Achievements Published work: Fennibay, D., Yurdakul, A. and Sen, A., Introducing Hardware-in-Loop Concept to the Hardware/Software Co-design of Real-time Embedded Systems, Proceedings of the seventh IEEE International Conference on Embedded Software and Systems, Bradford 29 June-1 July 2010, pp. tbd. Fennibay, D., Yurdakul, A. and Sen, A., Hardware-in-the-loop for hardware/ software co-design of real-time embedded systems (Poster), DATE 10 Workshop: Designing for Embedded Parallel Computing Platforms: Architectures, Design Tools, and Applications, 8-12 March Fennibay, D., Yurdakul, A. and Sen, A., Endüstriyel Uygulamalar için SystemC ile Döngü İçinde Donanım, Proceedings of the Fourth Ulusal Yazılım Mühendisliği Sempozyumu, İstanbul, 8-10 October 2009, pp Commercial use: Not yet A workshop is planned with Siemens Germany to evaluate the usability Slide 3

4 Outline Introduction Problem definition Preliminaries Related work Solution Experimental evaluation Conclusion Discussion Slide 4

5 Introduction Standardized: IEEE Wide use Fit for system-level Modular Transaction-level modeling Domain: Industrial Communication Strict hard-real-time constraints Data exchange rate (10 KHz) is achievable System-level design is a new trend in the domain Slide 5

6 Problem definition Communication between real and virtual subsystems Virtual to real communication & real to virtual communication Real-time behavior of virtual subsystems Determinism & speed Slide 6

7 Preliminaries: Simulation Discrete Event Simulation Events and passing time abstracted from each other Simulation clock advanced in discrete intervals Part of State According to Event Queue Real-time simulation Simulation clock T S Wall clock T W Synchronize T S T Sstart = T W T wstart External events Not in event queue Simulation clock cannot be advanced according to those Slide 7

8 Preliminaries: SystemC kernel Discrete event simulator Delta-cycle used for concurrency modeling in a single thread 0 simulation time advance during delta-cycles Problem! No 0 time advance in real-time Slide 8

9 Related work: Existing HiL methods Commercial devices and tools for test xpc Target, Real-Time Windows Target by MathWorks...but they are orthogonal to our work: Introduction of HiL to the Systemlevel HW/SW co-design of embedded systems...a new field!!! Slide 9

10 Related work: Integrating different environments CHILS Chip HiL Simulation Real-time constraint relaxed Exchange period adjustable Only for processors Via Remote Debugging Interface Slide 10

11 Related work: Timing concerns & determinism Virtual Chip Operational Buffer Unit to accommodate for the speed difference Realtimify Real-time execution of SystemC No concern w.r.t. determinism Uncertainty about synchronization point Suitable for human observation, not for HiL RTAI (used by Lu et. al.) Time sharing with Linux kernel RT_PREEMPT Increase determinism of Linux Kernel Slide 11

12 Solution Slide 12 SystemC is insensitive to external events!!!!

13 Solution: Achieving Real-Time Behavior Bind simulation clock to wall clock simulation step n - 1 t S simulation step n t Snew simulation step n + 1 delta cycles outputs time advance t W t Wdeltacycles t Woutput t Wdeltaend t Wactual t Wdelay t Wnew t Wpassed Simulation clock Advance t S t Snew Wall clock Current time: t Wactual t Wpassed in delta-cycles & outputs Delay by t Wdelay t Wnew t W = t Snew - t S T S T Sstart = T W T Wstart Slide 13

14 GPOS with real-time improvements Real-time scheduler Increased preemptibility Priority inheritance protocol High resolution timers Simulation thread set to real-time priority Latency sources eliminated Swap memory, power mgmt. etc. Slide 14

15 Solution: Achieving Real-Time Behavior Outputs in real-time Slide 15

16 Solution: Achieving Real-Virtual Communication: Hybrid channel Connect real and virtual worlds Virtual: SystemC interface Real: I/O driver Slide 16

17 Solution: Achieving Real-Virtual Communication Concurrent outputs Concurrent outputs in simulation sequential in real-time We define two constraints to model the limitation All concurrent outputs must occur in an output window t Wow Some concurrent outputs must occur in a smaller critical output window t Wcowi Solution Use HW support when available Enforce a strict ordering of output operations t Wow & t Wcowi parameterized by model developer Slide 17

18 Solution: Achieving Real-Virtual Communication Sensitivity to External events Sol n 1: Polling Most simple Tradeoff: simulation performance vs. I/O latency Slide 18

19 Solution: Achieving Real-Virtual Communication Sensitivity to External events Sol n 2: Adaptive polling Change polling period dynamically PID control Slide 19

20 Solution: Achieving Real-Virtual Communication Sensitivity to External events Slide 20 Sol n 3: Event-driven Patch in SystemC kernel Events detected by input threads put in a special queue SystemC patch interrupts the wait and notifies the events

21 Solution: Achieving Real-Virtual Communication Sensitivity to External events Polling Adaptive polling Fully event-driven Advantages Simple implementation Fastest No complex OS constructs No tradeoff or tuning necessary Disadvantages Tradeoff necessary Tuning necessary Complex implementation Uses complex OS constructs Slide 21

22 A mathematical model to estimate execution performance Virtual subsystems Must show sufficiently realistic behavior e.g. run in real-time Remain loyal to the simulation model e.g. concurrent outputs must be concurrent enough in real-time A mathematical model to estimate the simulation s execution Slide 22

23 Mathematical model: Real-time simulation simulation step n - 1 t S simulation step n t Snew simulation step n + 1 delta cycles outputs time advance t W t Wdeltacycles t Woutput t Wdeltaend t Wactual t Wdelay t Wnew For t Wdelay 0: t Wpassed SystemC is based on C++ Very hard to statically determine t Wevaluate and t Wupdate Instrumentation and profiling can be used Measure t Wpassed / (t Snew t S ) if > 1 model not real-time capable Slide 23

24 Mathematical model: Concurrent outputs Simplifying assumptions All outputs done by async. threads Trigger to output threads similar for all hybrid channels Number of operations at a simulation time does not exceed the number of processing cores All hybrid channels use update_real for output Slide 24 All operations take the same trigger time t Wo in simulation thread Real output operation time t Wdi differs

25 Mathematical model: Concurrent outputs Output window Critical output window For exclusive subsets of outputs Critical outputs can be ordered successively For a subset of m hybrid channels Slide 25 n H: # hybrid channels t Wo : measured as a platform characteristic

26 Experimental evaluation: Simulation speed & determinism Pulse width modulation (PWM) Slide 26

27 Experimental evaluation: PWM Results Signal stable up to 10 KHz Only minor effect of CPU load real-time scheduler works fine The ratio t Wpassed / (t Snew t S ) is reflected in the output jitter math. model works Computation power still available, but jitter prevents higher freq. 0,01 0, Waveform of (a) 10 KHz desired freq., (b) 100 KHz desired freq. Desired frequency [KHz] (persistence = infinite) (b) Slide 27 (a) Max jitter / desired period, (b) t Wpassed / (t Snew t S ) %25,0 %20,0 %15,0 %10,0 %5,0 %0,0 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 0,01 0, Desired frequency [KHz] (a) w/o CPU load with CPU load max (w/o CPU load) max (with CPU load) avg (w/o CPU load) avg (with CPU load)

28 Experimental evaluation:, I/O Performance Experiment: Ethernet round-trip time (RTT) Slide 28

29 Experimental evaluation: RTT results Simple polling Poling period has bigger effect than frame size Frame size has linear effect 10 ms cycle usable, 1 ms cycle usable with low polling period Adaptive polling PI control in [10 µs; 10 ms] Complex behavior Longer frames decrease polling period, but increase transmission time 1 ms cycle usable 1800 µs 1600 µs 1400 µs 1200 µs 1000 µs 800 µs 600 µs 400 µs 200 µs 0 µs 500 µs 450 µs 400 µs 350 µs 300 µs 250 µs 200 µs 150 µs 100 µs 50 µs 0 µs 64 bytes, 100 µs 64 bytes, 1000 µs 780 bytes, 100 µs 780 bytes, 1000 µs 1514 bytes, 100 µs frame size, polling period RTT for simple polling 1514 bytes, 1000 µs 64 bytes 780 bytes 1514 bytes min max avg min max avg frame size Slide 29 RTT for adaptive polling

30 Experimental evaluation: RTT results 1200 µs Event-driven No tradeoff necessary No tuning necessary Max RTT not affected by frame size Performs worse than adaptive polling for larger frames There is an inherent latency in the more complex OS constructs employed 1000 µs 800 µs 600 µs 400 µs 200 µs 0 µs 500 µs 450 µs 400 µs 350 µs 300 µs 250 µs 200 µs 150 µs 100 µs 50 µs 0 µs 64 bytes 780 bytes 1514 bytes frame size RTT for event-driven 64 bytes 780 bytes 1514 bytes frame size min max avg min max avg Slide 30 RTT for adaptive polling

31 Experimental evaluation Concurrent Outputs MultiPWM Experiment Performance of concurrent outputs with output ordering MultiPWM with HW Support Experiment Performance of concurrent outputs with HW support Slide 31

32 Experimental evaluation: Concurrent output results No HW support Successive ordering gains 6.7x smaller difference Mathematical model works: (nh 1) (m 1) 6 1 Maximum difference gains 10.7x smaller difference The possibility to be caught by the worst system latency smaller HW support achieves 100% concurrence Waveform of 2 signals for (a) with 5 channels inbetween, (b) successive (persistence = infinite) (a) output ordering, dist = 6 output ordering, dist = 1 (b) Time difference between signals in µs avg max min Slide 32

33 Experimental evaluation: Real-Life Experiment BBMD Experiment BACnet Broadcast Management Device model in SystemC Non-timed transaction-level model Traffic Between management station and automation stations Peer-to-peer traffic among automation stations Slide 33

34 Experimental evaluation: BBMD results Non-timed transaction-level BBMD outperformed the real BBMD Average response time: up to 80x better Incoming packet burst: 2000 packets/s 67% drop at real BBMD No drops at virtual BBMD Slide 34

35 Conclusion Hardware-in-the-loop concept for HW/SW codesign of embedded systems Developed Implemented Experimentally evaluated Slide 35 Hybrid channel Good encapsulation Very generic, can implement any kind of communication Clear interface to SystemC model Real-time patch Non-intrusive Adequate level of determinism reached with common tools

36 Conclusion Use in new domains may multiply More powerful modeling platforms Improvements in simulation speed: parallelism, optimization Determinism requires manual tuning RT_PREEMPT is constantly being improved, better tools are developed External events Event-driven implementation could perform better on an RTOS Adaptive polling can be tuned better via the provided PID mechanism Slide 36

37 Conclusion Mathematical model Usable for estimating if our method will work for a given SystemC model Needed empirical data is easy to obtain Also usable for understanding bottlenecks in the SystemC model Future work: scalability Test of our method with larger SystemC models BBMD experiment is realistic, yet smaller than industry-scale models Workshop in Germany will focus on this aspect, too Mathematical model can also be leveraged to estimate scalability Slide 37

38 Discussion Thanks for your attention Contributions & questions are welcome Doğan Fennibay Slide 38

39 Appendix Slide 39 Fennibay

40 Transaction-level modeling High-level, more abstract modeling Do NOT model every register transfer. Model transactions at the bottom level. TLM serves as a golden copy for less abstract RTL modelers. Slide 40

41 Hybrid channel examples Slide 41

42 Experimental evaluation SW Platform Linux rt19 In RT_PREEMPT mode SystemC Our real-time patch CPU load via multiple instances of infinitely spinning shell script HW Platform Dual Intel Quad-Core XEON at 3.4 GHz Intel Pentium 4 HT at 3.2 GHz (only in BBMD Experiment) Slide 42

43 Preliminaries: SystemC System-level modeling Transaction-level to register-transfer level Constructs Channel: communication Process: Execution paths Method, thread, clocked thread sc_event: synchronization Interface: Entry point to a channel Port: Exit point from a module Slide 43 Different from the event in a discrete event simulator

44 Solution: Output timing SystemC standard Our contribution Moment Advantages Disadvantages Evaluate e.g. write update Time advance update_real Data does not wait at all The final data of concurrent processes is used (e.g. sc_signal) Less number of outputs in total Concurrent outputs calculated by delta cycles are gathered together in real-time Data must not change in later cycles (e.g.. sc_fifo) Delta cycle processing time increases Concurrent outputs are distributed wider in realtime. Glitches occurring at the end of delta cycles are not relayed to outside Slide 44