1. SimGate: Full-System, Cycle-Close Simulation of the Stargate Sensor Network Intermediate Node Ye Wen, Selim Gurun, Navraj Chohan, Chandra Krintz, Rich Wolski UC Santa Barbara IC-SAMOS 2006

2. 2 Why Simulation? Sensor networks have unique characteristics —Resource-constrained, tiny devices —Heterogeneous, ad-hoc networks of thousands of nodes —Remote deployment locations Sensor network research requires substantial engineering, investment, and learning curve —Configuring/installing network devices a hassle —Many bugs not detected until run-time —HW lacks user-interface, debugging requires HW modification —Analyzing erroneous behavior not easy Simulation has significant advantages

3. 3 Simulation + Provides a controlled environment —Explore new ideas with no physical deployment —Observe (and reproduce) hard-to-create behavior + Cost-effective solution —A single Mica-2 node ~ $125 (many needed in a real setup) —Sensors and sensor gateways significantly more expensive - Not the same as real-life execution —Simplifying model assumptions (e.g. in network, power models) —May not include all real world scenarios —May require that applications be recompiled

4. 4 Our goals Simulate heterogeneous sensor networks —Including both intermediate gateway node (like Stargate) and basic sensor node (like motes) —Model and simulate the interaction between different nodes Scalable full-system simulation that runs applications transparently —Must boot and run the OS and all device drivers —Must communicate with other simulated devices in a network —The application should not be able to distinguish whether it is running on a simulated or a real sensor net Simulated devices run real code and interact in the same way as physical, deployed devices —Requires a model of radio interaction (hard!) —Requires accurate simulation/emulation of each (possibly heterogenous) device

5. 5 Stargate Simulation Src: Crossbow, Inc. Stargate Block Diagram CPU: Arm v5TE instruction set with Xscale DSP extension. No thumb instruction set support yet Flash: Memory-mapped I/O. State machine based on Intel Verilog model. Estimate flash latency using empirical data Boots and runs Familiar Linux

6. 6 Functional vs. Cycle-Close Simulation MMU/Pipeline simulation is expensive —7-8 stages, 3 parallel pipelines —32 Entry TLB, 128 entry Branch Target Buffer, 32KB cache and 8 entry fill-write buffer —Important for cycle-close simulation Not needed when cycle accuracy not a concern —Disable MMU simulation to improve simulation performance —Selectively turn off at compile time run time MMU simulator monitors HW performance monitors —Enabling/disabling HPM turns on/off MMU simulation

7. 7 Machine Code Interpreter while( ! stop_sim) { instr=load_instr(cpc); //fetch evtq->fire(); //fire events mach()->get_sysIO()->do_cycle(); //IO cycle … switch(BITS(instr,20,27)) { //execute instructions } if (pipex_enable) { pipex->sim(instr); } else { evtq->advance_clock(3); }

8. 8 Stargate-Mote Ensemble Mica-2 Mote simulation —Atmel processor —Serial interface —Packet radio —Boots and runs TinyOS Both simulators run applications transparently Currently implemented: a simple radio model Communication: —Stargate cannot communicate with Motes via Radio —It instead uses a serial connection

9. 9 Ensemble Architecture

10. 10 Multi-Simulation Manager Couples device simulators —Provides create, join, start, stop —Forks a thread for each simulator —A configuration file specifies which binary to boot Provides a unified debug interface —Manager dispatches debug commands to simulator threads —Watch changes/control execution flow Supports check-pointing —Threads save/reload current state on manager’s request —Improves booting time

11. 11 Ensemble Synchronization Clock synchronization —Execution rates of simulators should be proportional to real devices —Lock-step method: synchronize clocks on each serial byte transfer period —Serial transfer rate: 57.6 Kbits/seconds (128 Mote cycles) Ensemble simulation requires clock synchronization to slowest simulation thread —Stargate simulator is the bottleneck (most complex) Communication —Packets assembled using receivers local clock —Packet rate: 19.2 Kbits/seconds

12. 12 Methodology Validation: Simulation of Stargate and Mica-2 Motes working together —Standalone gateway scenario  A Stargate and a Mica-2 mote attached via UART —Packet forwarding engine scenario  A Stargate + Mica-2 gateway communicating to another Mica-2 via radio Benchmarks —Mediabench/Mibench to evaluate SimGate —Open source applications to evaluate SimGate/SimMote ensemble —Short/long forms

13. 13 Full System Stargate Simulation ApplicationMeasured CyclesSimulated CyclesError and Margin Audio code demodulation (adpcm ) 3.07*10 7 2.76*10 7 9.8% +/- 0.36% Jpeg Decode2.55*10 7 2.23*10 7 12.5% +/- 1.16% Jpeg Encode5.41*10 7 4.73*10 7 12.5% +/- 0.41% Error rates are low: worst case 12.5% For many applications, measurements and simulations are statistically indistinguishable

14. 14 Full System Stargate+Mote Simulation ApplicationMeasured Cycles Simulated Cycles Error and Margin Ping9.41*10 7 9.52*10 7 1.9% +/- 6.6% Localization2.13*10 8 2.08*10 8 2.2% +/- 1.5% Send-and-Store1.63*10 8 1.69*10 8 3.6% +/- 1.25% Blocking (similar to RPC) and non-blocking communication benchmarks Worst case: 3.6%

15. 15 Full System Stargate+2Motes Simulation ApplicationMeasured CyclesSimulated CyclesError and Margin Ping3.23*10 8 3.12*10 8 3.5% +/- 2.9% Localization2.36*10 8 2.28*10 8 3.3% +/- 3.3% Send-and-Store1.89*10 8 1.92*10 8 1.3% +/- 2.4% Worst case: 3.5% Error margins slightly larger than 1-Mote case in average: 2.1% vs. 2.4%

16. 16 Execution Performance Slowdown with respect to execution time in a real device

17. 17 Related Work Sensor Network Simulation —ATEMU, Avrora  Full system, multi-simulation, lock-step synchronization  No sensor network gateway support —EmTos  A wrapper library for TOSSIM and EmStar  All applications must be recompiled to host machine code and linked to EmTos Other Simulation —Skyeye  Full system ARM emulator including LCD and debugger  Not intended for sensor networks and multi-simulation

18. 18 Summary Real sensor network environment not attractive during application development phase —Physical deployment challenges —Debugging difficulties Simgate provides full-system, functional and cycle- close simulation without any code modification —Cycle estimation error: 9% —Simgates and simmotes: 4% 20X slower than real device 58X slower when cycle close simulation enabled

19. 19 Current and Future Work Scalability —Simulate large scale network using cluster computers —Partial results with only basic nodes (DiSenS); investigating the support for Stargate Radio model —Under development but a really hard problem —If the community develops one first, we will incorporate it Power model —A significant requirement for sensor devices —Planned for near future Debugging and IDE —Ongoing work: S 2 DB to debug the complete network —An IDE to build for developing applications easily

20. 20 Questions?

21. 21 Stargate Simulation Xscale processor —Arm v5TE instruction set with Xscale DSP extensions  No thumb instruction set support yet —MMU, GPIO, interrupt controller, real-time clock Flash memory —Memory-mapped I/O —State machine based on Intel Verilog model —Estimate Flash latency using empirical data 802.11 Wireless card Serial interface Boots and runs Familiar Linux