SimGate: Full-System, Cycle-Close Simulation of the Stargate Sensor Network Intermediate Node

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. 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. 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. 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. Stargate Simulation 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 Src: Crossbow, Inc.

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 timerun time • MMU simulator monitors HW performance monitors • Enabling/disabling HPM turns on/off MMU simulation

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. 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. 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

10. 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

11. 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

12. Full System Stargate Simulation • Error rates are low: worst case 12.5% • For many applications, measurements and simulations are statistically indistinguishable

13. Full System Stargate+Mote Simulation • Blocking (similar to RPC) and non-blocking communication benchmarks • Worst case: 3.6%

14. Full System Stargate+2Motes Simulation • Worst case: 3.5% • Error margins slightly larger than 1-Mote case in average: 2.1% vs. 2.4%

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

16. 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

17. 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

18. 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: S2DB to debug the complete network • An IDE to build for developing applications easily

19. Questions?