UNIVERSITY OF CALIFORNIA. Los Angeles. Avrora. The AVR Simulation and Analysis Framework. A thesis submitted in partial satisfaction

Transcription

1 UNIVERSITY OF CALIFORNIA Los Angeles Avrora The AVR Simulation and Analysis Framework A thesis submitted in partial satisfaction of the requirements for the degree Master of Science in Computer Science by Benjamin Lawrence Titzer 2004

2 The thesis of Benjamin Lawrence Titzer is approved. Todd Millstein Rupak Majumdar Jens Palsberg, Committee Chair University of California, Los Angeles 2004 ii

3 Table Of Contents Chapter 1 Background and Motivation.1 Section 1.1 Microcontroller Background..1 Section 1.2 Debugging and Testing Sensor Network Programs... 3 Section 1.3 Sensor Network Measurements.6 Section 1.4 Motivating the Need for Avrora 6 Section 1.5 Contributions.. 8 Chapter 2 The Avrora Architecture.. 9 Section 2.1 Program Representation Section 2.2 The State Interface...10 Section 2.3 The Interpreter.11 Section 2.4 The Microcontroller Interface..11 Section 2.5 The IOReg Interface 12 Section 2.6 The Platform Interface.14 Section 2.7 Pins...15 Section 2.8 Probes...16 Section 2.9 Events...18 Section 2.10 Watchpoints Section 2.11 Sleep...21 Section 2.12 Multi-node Simulation...23 iii

4 Chapter 3 Instruction Set Description Language 28 Section 3.1 Overview..28 Section 3.2 Legal Statements..32 Section 3.3 Legal Expressions 33 Section 3.4 Maps.34 Section 3.5 Generating the Interpreter 34 Section 3.6 Generating Analysis Tools...37 Section 3.7 Portability. 37 Chapter 4 Related and Future Work...39 Section 4.1 Simulators 39 Section 4.2 Simulator Performance 40 Section 4.3 Domain Specific Languages for Instruction Sets 41 Section 4.4 Sensor Network Simulators.42 Section 4.5 Future Work.44 Chapter 5 Conclusion.45 Bibliography.46 iv

5 List of Figures and Tables Figure Microcontroller...12 Figure Platform..14 Figure Probes. 17 Figure Counter Probe. 18 Figure Program Profiler Probe...18 Figure Event Queue Figure Thread Synchronization 25 Figure 3.1 Instruction Format Example..30 Figure 3.2 Operand Type Declaration Example.31 Figure 3.3 Subroutine Declaration Example Figure 3.4 Instruction Declaration Example...32 Figure 3.5 Statement Grammar...33 Figure 3.6 Expression Grammar.33 Figure Simulator Comparison 43 v

6 ABSTRACT OF THE THESIS Avrora The AVR Simulation and Analysis Framework By Benjamin Lawrence Titzer Master of Science in Computer Science University of California, Los Angeles, 2004 Professor Jens Palsberg, Chair Simulation is an important step in the development cycle of embedded systems. A simulator can enable detailed inspection of program execution and early diagnosis of problems before the software is deployed onto the target hardware. Avrora is a clean and open architecture for simulating and analyzing AVR architecture microcontroller programs on the Mica sensor node platform. Avrora provides a detailed, cycle-accurate simulator that allows flexible profiling and instrumentation of running programs. The asynchronous execution model provides a clean interface for device implementations and high scalability in multi-node simulations. Avrora also provides a framework for program analysis, allowing static checking of embedded software and an infrastructure for future program analysis research. vi

7 Chapter 1 Background and Motivation 1.1 Microcontroller Background Microcontrollers are small, limited power processors that represent systems on a chip a central processing unit, main memory, and I/O devices on a single physical chip. They generally have limited computational power and resources; registers are usually 8 or 16 bits and main memories are generally measured in bytes or kilobytes. Microcontrollers can serve as the central or auxiliary control in embedded systems where the presence of computers might not be readily apparent (e.g. a fuel-injection system in an internal combustion system). Full software programmability allows general-purpose microcontrollers to be mass-produced and custom software to be tailored for specific tasks, removing the need for expensive special-purpose hardware and allowing per-unit costs to measured in pennies. Software for the smallest of microcontrollers is generally written in assembly language. Some software, however, is written in higher-level languages like C and compiled to the machine code of the microcontroller. Generally there is not enough space to fit a true operating system on the microcontroller, so most programs run directly on the microcontroller without any of the protection mechanisms that are common on desktop microprocessors. Microcontrollers make the ideal fit for sensor networks, where programmability, physical size, and power consumption are important design criteria. The availability of compilers that translate high-level languages into microcontroller code brings many of 1

8 the benefits of high-level languages such as flexibility, reusability, portability, and robustness to sensor network programs. However, it is often hard to write, debug, test, and verify microcontroller programs. This thesis focuses on one particular sensor node platform centered around one particular microcontroller architecture, but the principles and techniques described can be applied without loss of generality to many other platforms. Berkeley motes built on the Atmel AVR [2] microcontroller platform have emerged as one of the leading platforms used in sensor network research. The Atmel AVR microcontroller platform is based on an 8-bit RISC instruction set. There are 32 8-bit general-purpose registers, 64 to 224 memory-mapped device registers, and instructions are either 2 or 4 bytes in size. Models with program storage ranging from 8kb to 128Kb and main memory from 64bytes to 4kb are available. The micro-architecture is generally simple; all instructions are executed inorder, with most completing in one cycle. Clock rates are generally between 4 and 16mhz and can generally be scaled in hardware to achieve the desired compromise between power consumption and throughput. There is usually an on-chip non-volatile EEPROM storage as well as timers, a serial interface, UART chips, and programmable I/O pins that can be wired to other physical devices such as a radio, potentiometer, and other sensors. Execution is highly interrupt-driven; there can be as many as 35 interrupt sources, ranging from timers to I/O devices, to externally triggered interrupts that are triggered by asserting pins on the microcontroller chip. The Berkeley Mote sensor platform built around the microcontroller includes external devices such as a radio for communication, a serial interface for programming 2

9 and debugging purposes, and various sensors. The Berkeley mote has gone through several generations of microcontroller models. The most recent uses the Atmel ATMega128L microcontroller, an AVR implementation with 128KB of program storage, 4KB of SRAM, a 4KB EEPROM, and a default clockrate of 7.3mhz. A small form factor, the Mica2Dot, is about the size of a quarter and the larger model is about half the size of a pack of standard playing cards. The nesc [18] programming language, an extension of the C language that adds module capabilities, is often used to program sensor networks. TinyOS, a set of components written in nesc, is a toolkit of modules that allows programs to interact with the devices available in a modular way. The functionality of the various modules is connected together using configuration mechanisms provided by the nesc language. 1.2 Debugging and Testing Sensor Network Programs Debugging microcontroller programs is notoriously difficult. There is generally no operating system available that provides a stable platform for experimenting with programs, making on-chip debugging difficult. The interface used for debugging and inspecting a program running on a testbed microcontroller is generally a narrow serial interface that is partly controlled by the actual software running on the testbed itself. A deadlock or crash of the microcontroller program can cause this interface to become unresponsive without a clear cause. Some microcontrollers provide a built-in mode called in-circuit-emulation (ICE) that allows low-level pause, inspect, and resume of testbed microcontrollers as they 3

10 execute microcontroller programs. However, these generally require special hardware to enable, special software provided by the manufacturer to interact with, and offer a primitive interface that can have poor performance. It may be difficult or infeasible to run a large enough portion of the program in ICE mode to be representative. The lack of powerful and useful debugging tools often forces programmers to debug with assertion statements or lace their code with printf that dump status information over a serial port when running on the sensor or to the console when running the code on a workstation. The presence of debugging code can influence the program s behavior and often leads to the concept of a debug build where the code behaves differently when compiled in two different scenarios. Worse, the debug build may no longer fit onto the physical device because of the extra code and data associated with printing status information. This type of primitive debugging strategy does not scale well to large programs or complex debugging tasks. One approach that has recently become more popular in the TinyOS community is to compile the nesc code of the sensor network program to the platform of the development machine (usually Linux and x86) and link the program with emulation libraries that mimic the behavior of the hardware devices on the microcontroller that are not present on the desktop machine [19]. This allows the program to be run on the development machine and its behavior to be verified. It often exposes obvious bugs in the program early and allows them to be corrected before attempting to compile the program for the microcontroller. 4

11 While compiling the program to the desktop architecture has its benefits, there are several drawbacks when using this approach to debug and test programs: 1. The program may behave differently on the desktop architecture for reasons such as endianness, structure alignment, size of primitive types, order of evaluation, compiler optimizations, program layout, and other common sources of portability problems associated with C programs. 2. Incorrect emulation of time-dependent behavior such as timers, delays due to serial communication, time required to execute various parts of the program, and environmental factors such as radio attenuation or acoustic propagation. 3. Incorrect or idealized emulation of device behavior. 4. Incorrect emulation of interrupt behavior that can hide synchronization problems and deadlock situations. 5. It only works for microcontroller programs primarily written in a higher-level language, and cannot be applied to microcontroller programs that have a significant portion of their functionality written in assembly. These problems generally result in a lack of simulation fidelity that can hide serious program flaws that are only detected in the deployment phase. Reliance on a new emulation phase introduced in the development cycle also pushes the actual deployment phase later, potentially increasing the costs of finding those serious flaws. 5

12 1.3 Sensor Network Measurements Measuring and studying the behavior of sensor networks under controlled conditions can be extremely difficult. Simulations of sensor network behavior are typically developed based on models and run on desktop computers; prototype code that emulates idealized behavior of nodes is intended as a low-fidelity behavioral simulation of nodes. Measurements of routing protocols, distributed algorithms, and wireless communication using such simulations are based on assumptions that may no longer hold when the protocol eventually must be implemented in software and deployed onto real sensors. Sensor network testbeds are used where actual physical sensors are deployed in a controlled laboratory setting; an implementation is developed, deployed, and measurements are made from the running code. However, networks of sufficient scale under representative conditions may be difficult or infeasible to build for some applications. Moreover, making detailed and precise measurements on a large scale can be difficult and results derived in laboratory settings may not be representative of results in the field. 1.4 Motivating the Need for Avrora Developing, testing, debugging and measuring sensor network software is hard. A more precise simulation of the behavior of the microcontroller is needed in order to detect program flaws that are hidden by low-fidelity simulations such as TOSSIM. This means an emulation of the microcontroller at the machine code level, including the behavior of 6

13 devices present both on the microcontroller chip and devices connected externally. This approach allows a language-independent high-fidelity simulation of the behavior of the microcontroller program, including correct emulation of the time-dependent aspects of the program s execution that can have a large impact on the behavior of the program and its correctness. Simulation is often a tradeoff between precision and performance; one of the goals of this thesis is to demonstrate that machine-code level simulation for sensor networks provides the needed precision with very acceptable performance. Making measurements in sensor network research would be greatly aided by a high-fidelity, high-resolution simulation where the actual implementation of sensor network programs and the hardware which they run on can be evaluated. The simulation environment surrounding the interaction of sensors can be precisely controlled, the behavior of the sensor network programs can be analyzed individually, and properties of the network on a large scale can be measured in a repeatable fashion. Avrora provides a centerpiece for research and development of sensor network programs: a high-resolution simulation with clock-cycle accurate execution of microcontroller programs. The behavior of devices on the microcontroller is emulated as well as the behavior of external devices wired to the microcontroller. Environmental conditions can be modeled; emulation of sensor behavior at the hardware level as well as the correct emulation of the program s interaction with hardware sensors allows studying program behavior, sensor behavior, and network behavior at a level that is much closer to reality than previously possible. High-performance simulation of an individual node 7

14 coupled with parallelizing the simulation will allow Avrora to scale to whole-network simulation. 1.5 Contributions The major contributions of this thesis are as follows: 1. Implementation of a cycle-accurate simulator for the AVR instruction set capable of running machine code programs up to 10x real-time performance, as well as a clean framework for building device simulations. 2. An architecture for detailed profiling and instrumentation of AVR programs during simulation that is not available in either of TOSSIM or AtEmu. 3. An instruction set description language general enough to describe most RISC architectures and detailed enough to generate efficient interpreters and machine code manipulation tools. 4. A clean machine-code representation for manipulation and analysis of programs. 5. The asynchronous event model of the Avrora simulator allows scalable, largescale multi-threaded simulation of multiple nodes for high scalability. 8

15 Chapter 2 The Avrora Architecture The centerpiece of Avrora is the simulator. It simulates the operation of the microcontroller, executing the program and emulating the devices that the program interacts with. In addition, it provides an API for probing and monitoring the program as it executes for studying, debugging, profiling, and testing purposes. 2.1 Program Representation Programs are a collection of instructions, initialized data, and (optionally) source mapping information. Avrora supports three formats for loading programs: a source assembly format specified by the manufacturer s assembler for programs written by hand, a source assembly format that is the output of GNU C compiler [6] that is also supported by the GNU Assembler, and a disassembled format produced by the GNU objdump [5] utility. The programs are parsed into an internal format where each instruction is represented by a Java object that extends the Instr class. Each type of instruction in the AVR instruction set has its own class that is both an inner class and direct descendant of the Instr class. For example, instances of Instr.ADD represent instances of the add instruction that performs addition on two general-purpose registers. Each object stores the operands to the instruction, such as the registers or immediates to the instruction, and several utility methods such as getcycles(), getsize(), etc return information about 9

16 each instruction. Additionally, each Instr subclass has an accept() method implements the visitor [10] pattern, which components like the interpreter, abstract interpreter, and control flow graph builder use to traverse the program. The use of the visitor pattern provides a convenient mechanism for inspecting and manipulating programs, allowing clients to define the visit() methods for the particular instructions they are interested in. 2.2 The State Interface The state of the simulated program, including the values of general purpose registers, IO registers, data memory, program memory, program counter, etc is exposed through an interface called State. The methods of the State interface allow clients to inspect the program state, regardless of the implementation actually used by the simulator. This presents profiling and monitoring tools with a convenient interface to inspect the state without becoming dependent on implementation details. For example, the getsreg() method returns a byte value that represents the status register which contains the status flags of the microcontroller. Originally this register was implemented as a byte and operations on individual flags were implemented with masks and shifts on this byte value. For performance, this implementation was changed so that each flag exists and can be manipulated individually as a boolean and the getsreg() method instead computes this byte from the individual flags. Since the flags are accessed far more frequently individually than the entire register treated as a byte, this resulted in a significant performance boost (up to 30% for individual instructions that 10

17 manipulate flags heavily) without changing the interface. A similar optimization is planned for the stack pointer, which is stored separately in two different 8-bit IO registers but often accessed as a single 16-bit integer. 2.3 The Interpreter The interpreter executes the instructions of the program. In many ways, the interpreter drives the simulation, since it drives the passage of simulation time. The interpreter is a visitor that maintains a program counter that tracks the current instruction in the program. The interpreter is organized in a straightforward way; a main loop controls execution of individual instructions and individual methods implement the functionality of each instruction. The main loop calls the accept() method of the current instruction, passing itself as a parameter, and that accept() method will call the appropriate visit() method of the interpreter. The Interpreter instance contains fields that store the program s state such as the program counter, general-purpose registers, main memory, etc. It implements the State interface, which allows clients to inspect of the state of the simulation without depending on the details of the interpreter implementation. 2.4 The Microcontroller Interface In addition to the execution of each of the individual instructions available in the AVR instruction set, a faithful simulation of the devices on the microcontroller chip is necessary to simulate the behavior of the program. While the Interpreter class 11

18 performs the computation specified by the programs instructions, for modularity purposes it does not implement each of the devices. Another layer of abstraction encapsulates both the interpreter and the on-chip devices provided by a particular microcontroller implementation. The Microcontroller interface abstracts implementation details such as the sizes of main memory and program stores, the clockrate, and the on-chip devices. For example, the ATMega128L class represents the model of microcontroller used on the latest Berkeley motes and contains inner classes that implement the devices specific to that model. An example of such a device is the class Timer0 which is an inner class in ATMega128L that implements an 8-bit timer. Microcontroller Simulator Interpreter IOReg interface Event queue interface ADC Timer SPI On-chip devices Figure The Microcontroller encapsulates an instance of the Simulator class and supplies the on-chip devices such as the timer, the analog to digital converter, etc. Devices communicate with the simulation through the IOreg interface and the event queue interface. 2.5 The IOReg Interface The AVR architecture has a set of memory-mapped registers that are used for communicating with and programming on-chip devices provided on the microcontroller. 12

19 For example, writing to the TCCR0 register at memory address 0x0053 can enable the Timer0 device as well as program its frequency and mode of operation. Various models of the AVR architecture have different numbers of IO registers with different roles. On the ATMega128L, for example, there are 224 such IO registers. For modularity and extensibility purposes, the interpreter was not be hard-coded to implement the devices of a particular microcontroller implementation. Such devices have various behaviors and use a variety of IO registers that are generally not universal across microcontroller models. Instead the State.IOReg interface encapsulates the notion of an IO register. A program may read or write an entire 8-bit quantity or a single bit to an IO register, so the State.IOReg interface has four methods: read(), write(), readbit(), and writebit(). The interpreter stores an array of references to State.IOReg objects that is populated with implementations of State.IOReg that correspond to the particular devices on the microcontroller. Reads and writes by the program into the section of memory containing the IO registers are the redirected to the corresponding State.IOReg instance, which may take action based on the values read or written. For example, the Timer0 device on the ATMega128L uses four IO registers: a counter register, TCNT0 at address 0x0052, an control register TCCR0 at 0x0053, an interrupt mask register TIMSK at 0x0057, and an interrupt flag register TIFR at 0x0056. When the ATMega128L class is instantiated, it creates a Timer0 class that inserts its own implementation of the State.IOReg interface at the appropriate memory locations that will then get control through the read(), write(), readbit() and writebit() 13

20 methods when the program reads or writes to those addresses. Thus, when the program writes the TCCR0 control register, the timer might be enabled, disabled, or the mode changed. The Timer0 class can take the appropriate action such as inserting or removing events from the event queue of the simulator or updating internal state. 2.6 The Platform Interface Platform Microcontroller Simulator Interpreter IOReg interface Event queue interface ADC Timer Ports On-chip devices Pin interface Radio LEDs Off-chip devices Figure The Platform interface encapsulates a microcontroller class and supplies the off-chip devices such as the radio and LEDs. The external devices communicate with the microcontroller through the pin interface. The Platform interface encapsulates the notion of a hardware device that is built with the microcontroller as the centerpiece and external devices connected to it. For example, in addition to a particular model of microcontroller, a sensor node contains off- 14

21 chip devices that are connected to the microcontroller through physical pins on the chip. These external devices could be sensors such as photo-sensors, acoustic sensors, temperature or humidity, as well as communication devices such as a radio, parallel controller, or Ethernet-on-a-chip. Status LEDs are generally connected directly to a few reserved pins for visual inspection of the state of a sensor node. For the Mica platform of sensor node, a Mica class exists that implements the Platform interface. Devices such as LEDs on the mica sensor node platform are implemented as inner classes within the Mica class. Such devices connect to the Microcontroller through the Pin interface that is described in the next section. 2.7 Pins Just as external physical devices are connected to the microcontroller through physical pins in reality, external device implementations within the simulation are part of the platform and connect to the Microcontroller object through a Microcontroller.Pin interface. In the real world, all physical pins on the microcontroller designated for IO purposes are bi-directional and programmable by software through IO registers. Each physical pin has three corresponding bits that are programmable by software: a direction bit, an input bit, and an output bit. Reading from the input bit when the pin is configured as input will read the logical level on the corresponding physical pin on the microcontroller. Writing the output bit when the pin is programmed as an output causes the microcontroller to pull the logical level high or low depending on the value of the bit 15

22 written to the register. In this way the pins provide a primitive, bit-level communication mechanism between the microcontroller program and the devices connected to the microcontroller. Timing of the signals is extremely critical. Specific implementations of the Microcontroller interface export certain named pins through a Microcontroller.Pin interface. The getpin() method of the Microcontroller looks up a pin by either its physical number or a string name. This Microcontroller.Pin interface then allows devices to be connected to the pin as either an input or an output. Then, when the program attempts to read or write to that pin, the device is notified. This simple interface allows external devices to be implemented in a modular way, without increasing the complexity of the Simulator or Microcontroller. 2.8 Probes Probes in Avrora are pieces of instrumentation code that can be inserted at particular points in an executing program. The simulator provides the methods insertprobe() and removeprobe() that allow Java objects that implement the Simulator.Probe interface to be inserted at particular instructions in the program. Those probes then implement the firebefore() and fireafter() methods that the simulator calls before and after the target instruction executes. The probe can also be inserted in a global queue of probes that fire before and after every instruction executes. When the simulator calls the probe, the instruction executing, the address of the instruction, and a Java object representing the state of the microcontroller are passed, 16

23 allowing the implementer of the probe to inspect the state of the simulation, tally profiling information, or enable or disable events or other probes. This simple interface allows for a remarkably rich space of possible instrumentation to be achieved, without any internal modifications to either the simulator or any of its supporting code. A simple counter probe amounts to less than ten lines of code; a probe to count the execution frequency of the entire program is less than twenty. Simulator Program Interpreter a insertprobe(x, a) firebefore() fireafter() user Probe X Figure The insertprobe() method allows a userdefined probe to be inserted into the program at a particular address. The probe will then be called before and after each time the instruction at that address is executed. A toolbox of simple probes is provided that offer commonly needed and useful types of information. Simple counters, branch counters, whole-program instruction counts, as well as meta-probes like region probes that enable another probe when a region is entered and disable it when the region is exited offer a rich set of base functionality for tackling more sophisticated profiling and monitoring tasks. 17

24 public class Counter implements Simulator.Probe { public long count; public void firebefore(instr i, int address, State state) { count++; } } public void fireafter(instr i, int address, State state) { // do nothing } Figure The simplest type of probe is a counter which simply increments an internal count each time it is triggered by the simulator. public class ProgramProfiler implements Simulator.Probe { public final Program program; public final long icount[]; public ProgramProfiler(Program p) { int size = p.program_end; icount = new long[size]; program = p; } public void firebefore(instr i, int address, State state) { icount[address]++; } } public void fireafter(instr i, int address, State state) { // do nothing. } Figure Another example probe that collects a histogram of the execution frequency for each instruction in the program using an array indexed by the address of the instruction. 2.9 Events Avrora has an asynchronous model of execution, meaning that the simulator does not have a visible clock signal that devices and monitors can see on every simulated cycle. Instead, devices and monitors that have time-dependent behavior register events that will occur a known number of cycles in the future. The simulator will then fire the event when simulation time reaches that point in the future. 18

25 Simulator DeltaQueu e Interpreter Timer0Even t ProfilingEven t UARTEvent Figure The event queue is maintained as a delta list of events that will be fired as they are encountered in order. The interpreter decrements the count of the event at the head of the queue as time passes. When the count at the head reaches zero, it fires the event and removes the link. As an example, the on-chip timer device, when the program enables it, increments a register on the microcontroller with a programmable frequency derived from the main clock signal. For instance, it could be programmed to increment the register once every 32 clock-cycles and signal an interrupt when the count reaches a certain value. A straightforward but naïve approach to implementing the timer would be to expose a global clock signal in the simulator so that each device is called on each clock cycle to do some work. The timer implementation would then increment an internal count each clock cycle until it reached 32, and then increment the register and check whether it has reached the limit. The penalty of this strategy is three-fold: the timer is more complex because it must internally scale the clock signal; the simulator is more complex because it must consult every device every cycle, even when executing instructions consuming multiple 19

26 clock cycles; and the performance of the whole system is severely degraded due to large amounts of unnecessary method calls. The approach taken in Avrora is to register time-dependent work in a delta-queue managed by the simulator. Each device or monitor that needs to perform work that is time-dependent registers an event at the latest point in the future at which that work can be performed. The simulator then implements a delta queue that keeps the events in chronological order. Processing of the queue by the simulator each clock cycle requires only constant time: decrement the count at the head of the queue; if zero, fire the event(s). If two events occupy the same time slot, they are fired in the order in which they were inserted. Insertion takes time proportional to the number of events preceding the inserted the event in the worst case, the number of ticks in the future. In practice the delta queue remains small. Hiding the clock signal behind a clean interface with a tight implementation contract allows the simulator to achieve good performance and simplifies both sides of the implementation. The simulator exposes the insertevent(), removeevent(), and insertperiodicevent() methods that allow Java objects implementing the Simulator.Event interface to be inserted into the delta queue. No special support for periodic events in the delta queue processing is required: an implementation of Simulator.Event that automatically reinserts itself into the queue is used internally to implement the insertperiodicevent() call. These three calls offer a very simple API into the simulator that has proved to be remarkably useful and general. 20

27 2.10 Watchpoints Profiling and monitoring the behavior of the program s code is useful, but the data access patterns of a program are not necessarily apparent from its path through the code. A mechanism to monitor the data access patterns of programs is provided in Avrora that is similar to probes. The Simulator defines a method insertwatchpoint() that allows a profiling or monitoring tool to insert a Java object that implements Simulator.MemoryProbe interface into a particular memory address in the program. The Simulator.MemoryProbe interface defines the methods firebeforeread(), firebeforewrite(), fireafterread(), and fireafterwrite(). When a memory address that has an associated Simulator.MemoryProbe is read or written, the Simulator will call the appropriate methods of the memory probe before and after the memory operation. In this way, profiling tools can monitor the memory access patterns of the program Sleep Microcontrollers often exist in energy-constrained settings where the microcontroller s power is provided by a battery or solar cell. It is important to preserve energy wherever possible in such settings; most microcontrollers allow software to turn off unnecessary sources of power drain such as unused devices. Additionally, the microcontroller s clock signal itself can be turned off, causing the unit to enter a lowpower sleep mode where no instructions are executed until the next interrupt arrives. In the AVR instruction set, a program can write a special sleep register and then execute the 21

28 sleep instruction. Sleeping is important for sensor network programs where most sensors remain in a sleep mode and only activate periodically to perform work or communicate. In Avrora, the progress of time is driven by the execution of instructions, while a delta queue of events is maintained that represent work to be performed at different points in time. The delta queue model allows a straightforward and efficient implementation of sleep; when a program executes the sleep instruction, the program will not regain control again until an interrupt is triggered. Using this fact, the simulator then knows that if no interrupt is currently pending, then an interrupt can only be triggered by execution of some event that is waiting in the queue. Thus, while sleeping, the simulator simply executes the events in the event queue in order until one triggers an interrupt. For example, suppose that the timer device is enabled with a period of 1024 clock cycles and the program enters a sleep mode. The simulator will process the delta queue, where it may find the timer event at the head, and that it should execute, for example, 998 cycles in the future. Until that time, no instructions will execute, and no other events will intervene since that event is at the head of the queue. The simulator can then safely advance the simulation time by 998 cycles and fire the timer event. The timer event will increment the value of the timer count register and insert another timer event back into the queue 1024 cycles in the future. When control returns to the simulator, it is still in sleep mode, and the new timer event in the event queue will be at the head with a delta of 1024 cycles (assuming there were no other events in the queue). The simulator will then advance simulation time by 1024 cycles and fire the timer event just as before. This 22

29 process will repeat until the timer event triggers an interrupt when it reaches the maximum value. The simulator will then notice the interrupt, break out of sleep mode, and begin executing again at the interrupt handler s address. Simulating sleeping periods is highly efficient, since no computation happens during those times, and no per-cycle work is done. For programs that sleep a majority of their time, this yields a major boost in simulation performance. For example, the Blink program uses a timer to generate an interrupt once a second. The interrupt handler simply toggles an LED on or off and then goes to sleep. With the sleep optimization, Avrora runs Blink five times faster on our test machine (a 3.06ghz Xeon processor), up to 80mhz, or more than ten times real-time Multi-node Simulation Simulating an entire network of sensors requires the ability to simulate multiple nodes, each running their code on a microcontroller, each with their own devices, and each with their own particular view of the environment. The sensor network amounts to a distributed system where individual nodes can usually only communicate wirelessly through a radio link. Such networks may contain tens, hundreds, or even thousands of sensor nodes, each sensing and communicating with its neighbors. The modular, object oriented architecture of the Avrora simulator and its encapsulation and abstraction of ideas such as nodes, state, and devices lends itself well to building a large scale simulation for an entire network of sensors. An instance of the Simulator class is independent of others and its execution model is straightforward; 23

30 start(), stop(), and reset() drive the execution of an individual node. The start() method causes the simulator to enter its main loop and begin executing the program, firing probes and events as the program executes and the simulation time of the node passes. As was shown, the asynchronous execution model of events in the simulator allows a convenient and efficient implementation of time-dependent behavior of devices on the microcontroller without complicating the internals of the simulator. This event model, coupled with the encapsulation inherent in the software architecture of the simulator, can be applied to the multi-node simulation problem. To simulate multiple nodes at once, each node can be created as a separate instance of the Simulator class, each with its own local simulation time, and run in its own thread. The threads can then be run in parallel, and periodically synchronize to a global clock that manages the state of the environment, including the radio communication channel. Each Simulator instance s event queue can be utilized for this purpose. By inserting a periodic event in each event queue of each Simulator and having each event synchronize to a global object, the Simulator threads can run in parallel until they each individually fire the synchronization event. When all Simulator instances have reached the synchronization point, the global state of the environment and communication channel can be recomputed. Once the global state of the environment has been computed, all instances can be released again to compute in parallel until the next synchronization point. 24

31 For example, suppose there are 5 nodes being simulated. Five instances of the Simulator class are constructed and each associated with the properties (such as physical location) of its respective node. A GlobalClock object is created and each of the 5 Simulator instances inserted into the global clock. The GlobalClock then inserts an event in the event queues of each Simulator instances for a particular time in the future. For example, for a period of one millisecond, the event would have a period of 7300 cycles on ATMega128L. To begin the simulation, the start() methods of all 5 instances of Simulator are called. GlobalClock Simulator.start() Node A Node B Node C Node D Event.fire() GlobalClock return Node A Node B Node C Node D Node E Node E Environment o Environment 1 Figure Illustration of thread synchronization and environment update in multiple-node simulation. Threads synchronize on the GlobalClock object through the use of the Simulator s event queue interface. The only interface needed to accomplish this synchronization is the fire() method of the Event. Threads can be blocked in the GlobalClock and then return after unblocking. Each Simulator executes independently, executing instructions, manipulating devices, or sleeping, until its local simulation time reaches 7300 cycles, when it will fire the synchronization event. The synchronization event will enter the global clock, atomically register that it is ready for the next simulation interval, and then block. When 25

32 all threads have entered the GlobalClock, the last will cause the GlobalClock to reinsert the event into all Simulator instances 7300 cycles in the future, and then all threads will be unblocked and proceed again. Nodes may view or interact with the environment during their execution. The properties of the environment, including the state of the radio communication channel, are only updated at the end of each synchronization point. Therefore the state of the environment is an average over an interval of time and is an approximation. It is only updated with the resolution of the synchronization points. Therefore it is important that the period of these synchronization points be chosen appropriately, since too low of a resolution may not be accurate enough, but too high of a resolution may constrain the scalability of the simulation by increasing the synchronization overhead. This is likely to be an application-specific problem, but the ability tune this parameter demonstrates the generality of the approach. The parallel nature of the simulation allows excellent scalability for large networks without sacrificing precision on the simulation of individual nodes. The simulation will perform well on server machines with a large number of processors due to the highly multithreaded organization and largely independent data sets (since each node has its own computational state). The asynchronous event model of the Simulator made implementing multinode simulation almost trivial and required no changes to the Simulator itself. The GlobalClock class simply maintains a count of number of threads that have entered the synchronization region and the total number of threads in the simulation. The 26

33 Simulator.Event inserted into each Simulator simply increments this count atomically and blocks if it is less than the total number of threads. The last thread will increment the count, notice that all threads are ready, insert the events in all threads again, and then unblock all threads. The implementation of GlobalClock amounts to just over 100 lines of code. This approach is a significant advance in the state of the art in simulating sensor networks. A simulator such as AtEmu [1], while it can provide a precise and faithful simulation of the microcontroller behavior and radio-waveform propagation over air, simply cannot scale to a large network due to the naïve implementation of global time, where each node is advanced a single clock cycle at a time in one large loop. TOSSIM allows multiple nodes to be emulated on a behavior level using UNIX processes which are more heavyweight than Java threads, but there is no notion of global time. Scaling to hundreds or thousands of UNIX processes to simulate a large network puts a significant burden on the operating system and may simply not be possible on machines with limited physical memory. 27

34 Chapter 3 -- Instruction Set Description Language 3.1 Overview Tools that work with machine code often need information about the semantics of individual instructions in the architecture. Most often this information is documented in an instruction set manual provided by the hardware vendor and described in natural language. Someone interested in simulating or analyzing programs interprets the manual and develops an ad-hoc implementation of an assembler, disassembler, emulator, abstract interpreter, or program analyzer in a general purpose programming language like C or Java that implements the programmer s understanding of the instruction set. This process is tedious and error prone. Many people prefer to work with other representations of the program, even when machine code offers clear advantages, due to the large initial effort that is spent and the lack of widespread machine code tools. There has been some success in developing domain specific languages for describing instruction set architectures. Instructions, their encoding formats, and their behavior can be described in many different ways such operational or denotational semantics. Some description languages are tuned towards code generator generators and some towards interpreter generators, while still others are tuned for analysis tools. There are several parts of Avrora that depend on the instruction set of the microcontroller being simulated. The interpreter implements the semantics of each instruction. The input format readers must parse and simplify source assembly. A control flow graph discovery utility must discover basic blocks in the program and needs a listing 28

35 of the branch and call instructions as well as a way to compute their possible targets. An abstract interpreter must implement the abstract semantics of each instruction. The internal program format must have one class for each type of instruction in the instruction set. Originally the development of Avrora followed the traditional model, where the instruction set manual was used as a guide and each piece that depended on it was tediously written. After several iterations of evolving parts of Avrora, it became clear that further progress would be greatly speeded if an automated, special purpose tool to generate instruction-dependent portions of Avrora based on a common specification existed. For example, a disassembler that converts binary machine code to Avrora s internal format would allow loading of binary formats and execution of self-modifying code. An assembler would allow source instruction to be interpreted as binary data, allowing execution of source programs that read their instruction s machine code as data, which is needed in a truly faithful simulation of the hardware s actual behavior. The central instruction set description was designed to allow these new components to be generated and allow more flexibility in the implementation of the interpreter. Experience in the initial development and evolution of portions of Avrora dependent on the instruction set contributed positively to the design of the instruction set description language. Several interpreter optimizations that would have been tedious to perform by hand were simple to implement in the generator and resulted in a significant performance boost over the hand-written interpreter. 29

36 The instruction set description language allows the description of an instruction, including the name, a mnemonic (source) name; operands, a list of typed arguments to each particular instruction such as registers or immediates or addresses; encoding, a binary encoding format including opcodes and fields for operands; and a body, a sequence of straight-line code that describes execution. Non-recursive subroutines allow common functionality to be shared between the bodies of several similar instructions. Individual analysis of instruction bodies allows classifications such as branch, memory, arithmetic, etc, that might be important to analysis tools. Avrora s instruction set description language is general enough to express most RISC architectures. It currently has no support for variable length instructions. Some examples from the AVR instruction set description are given below. format GPRGPR = { }; opcode[5:0], r2[4:4], r1[4:4], r1[3:0], r2[3:0] Figure 3.1. An example declaration of an instruction format. This particular format is for instructions that accept two general purpose registers; its encoding format is specified in the microcontroller manual. The example in Figure 3.1 declares a new encoding format that can be used in the declaration of individual instructions. It specifies an encoding name, GPRGPR that can be used by subsequent instruction declarations to specify their encoding formats, and an ordered list of fields that describe how the bits of each field are encoded into binary machine code, most-significant bit first, lowest memory address first. The square bracket notation denotes a range of bits from a field. For example, opcode[5:0] represents the sequence of 6 bits starting at bit 5 of the field opcode and ending at bit 0, inclusive. The 30

37 bits of a single field can be split up and spread throughout the encoding, which is common in many architectures and illustrated in the r2 operand in this example. operand EGPR: register = { r0, r2, r4, r6, r8, r10, r12, r14, r16, r18, r20, r22, r24, r26, r28, r30 }; Figure 3.2. An example declaration of an operand type that is a subset of the general purpose registers. This example example declares an operand type named EGPR that contains the even registers. Figure 3.2 shows an example declaration of an operand type that subsequent instruction declarations can use to give the types of legal operands that they accept. An operand can be a register, an immediate, a program address, or a data address. For example, the ADIW instruction, which adds an immediate to a pair of registers, accepts only an even-numbered register as an operand. Operand types that are a subset of the available registers or operands that must be in a particular range of integer values can be declared. inline subroutine performaddition(r1: int, r2: int, carry: int): byte { local result: int = r1 + r2 + carry; local ral: int = r1[3:0]; local rbl: int = r2[3:0]; local Rd7: boolean = r1[7]; local Rr7: boolean = r2[7]; local R7: boolean = result[7]; // set the flags as per instruction set documentation. H = (ral + rbl + carry)[4]; C = result[8]; N = result[7]; Z = low(result) == 0; V = (Rd7 and Rr7 and!r7) or (!Rd7 and!rr7 and R7); S = N xor V; }; return low(result); Figure 3.3. An example subroutine declaration that accepts three parameters, manipulates the state of several flags, and returns the sum of the three passed values. 31