1. System Synthesis for Networks of Programmable Blocks
Ryan Mannion, Harry Hsieh, Susan Cotterell, Frank Vahid*
Department of Computer Science and Engineering
University of California, Riverside
{rmannion, harry, susanc,
* Also with the Center for Embedded Computer Systems at UC Irvine
This work is being supported by the National Science Foundation and a Department of Education GAANN Fellowship

2. Introduction
Sensor networks are emerging as an important general computing domain
Small inexpensive battery-powered sense and compute nodes
Tens to thousands of nodes
Wired or wireless communication
Stringent requirements (power, cost, size)
Environmental Monitoring
Military Applications
Home Automation
Medical Monitoring
Structure/Building Monitoring

3. Introduction
Potential sensor network application developers may not be computer programmers
Instead, engineers, scientists, office workers, homeowners, etc.
Existing programmable nodes
Flexible, but require programming
Existing off-the-shelf end applications
Specialized, so hard to customize
Expensive due to small volumes
Our solution – eBlocks
Enables non-programming users to create simple but useful customized sensor network applications
hard to program
Flexible,
Photo: Jason Hill
Limited configurability - mention “What if we wanted to detect if the garage door was open at night?”,
Easy to use,
inflexible

4. Network nodes and programs
Talk Outline
Brief introduction to eBlocks
Synthesis
Motivation
Methodology
Experiments
Button
2-Input Logic
Inverter 1
Splitter
Prolonger
LED
PROG
C Code
eBlock capture tool
Synthesis
Limited configurability - mention “What if we wanted to detect if the garage door was open at night?”,
Network nodes and programs

5. Magnetic Contact Switch
eBlocks Overview
eBlocks (UC Riverside)
Began as low-cost reusable basic building blocks
Enables non-programmers to create basic but useful sensor-based applications
Function of each block is pre-defined
Block types:
Sensors – motion, light, contact, etc.
Output – led, electric relay, beeper, etc.
Compute – logic, prolong, toggle, etc.
Basic configuration required (dials, switches)
Communicate – wireless point-to-point link
Users merely connect blocks to create working customized application
Evolving into a “spatial” programming methodology for sensor networks with programmable nodes
CODES/ISSS’03, SECON’04, CHI’05, SPOTS’05
Light Sensor
Magnetic Contact Switch
Motion Sensor
Button
Splitter
2-Input Logic
Toggle
Tripper
LED
Electric Relay
Limited configurability - mention “What if we wanted to detect if the garage door was open at night?”, 1
C Code

6. Creating an application with eBlocks
Create an application to detect if the garage door is left open at night
We want to detect night – use light sensor
Light Sensor
Light Sensor
LED
Need something to indicate garage open at night – use led
LED
Plug pieces together and the system is done!
2-Input Logic
A’B’
2-Input Logic
Configure Logic Block to turn led on when it’s night and when door is open
A’B’
Need a function of light sensor output and contact switch output – use Logic Block
2-Input Logic
We want to know if garage door open – use contact switch
Magnetic Contact Switch
Magnetic Contact Switch 1
C Code

7. Building eBlocks Systems
The same basic blocks can be used in a variety of applications
Sleepwalker at Night Alarm
Tripper
Motion Sensor
2-Input Logic
A’B
Light Sensor
Button
Beeper
2-Input Logic
A’B’
Light Sensor
Magnetic Contact Switch
LED
Garage Door Open At Night Detector
Motion on Property Detector
Motion Sensor
2-Input Logic
A+B
Prolonger
Beeper
Animal Videoing System
Motion Sensor
2-Input Logic
A+B
Prolonger
eBlock to Camera Interface
Light Sensor 1
C Code

8. Motivation - Programmable Blocks
Programmable blocks are desirable
Allows for smaller designs
Results in reduced cost and power consumption
Limitation - Programmable blocks hard to use by non-programmers (requires “2.5 Ph.D.s” – SECON’04 keynote)
Solution – eBlocks capture tool, automated synthesis generates equivalent programs
eBlocks limit potential functionality
But range is still useful, and accessible to non-programmers
Button
2-Input Logic
Inverter 1
Splitter
Prolonger
LED
PROG 1
C Code

9. Design Entry/ Simulation
Synthesis
Synthesis tool
Must map network of pre-defined blocks to programmable blocks
Three stages
Design entry/simulation
Synthesis -- Partitioning
Synthesis -- Code generation
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning
Code Generation 1
C Code

10. Design Entry/Simulation
User specifies and tests block design
Java-based simulator
Blocks added to workspace by dragging blocks from “Available eBlocks” tray
Connections created by drawing lines between blocks
User can create, experiment, test and configure design
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning
Code Generation 1
C Code

11. Synthesis -- Partitioning
Mapping of pre-defined blocks to programmable blocks
Problem – map pre-defined blocks to minimum number of programmable blocks
Intermediate blocks (non-sensor, non-output)
We assume 2-input/2-output programmable block available
Partitioning problem differs from existing problems
Classic bin-packing or knapsack algorithms
But we need to be conscious of two constraints – number of inputs and number of outputs
Two-dimensional bin-packing problem (cutting stock problem)
But number of inputs and outputs of programmable block are mutually independent
FPGA synthesis, namely DAG covering
But we do not require all nodes to be covered
Our goal is to minimize block count, many focus on minimum-delay solutions or approximations
Many solutions permit replications – contrary to our goal of minimizing block count
Button
2-Input Logic
Inverter 1
Splitter
Prolonger
LED
PROG
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning
Code Generation 1
C Code

12. Design Entry/ Simulation
Synthesis -- Partitioning Strategies
Exhaustive
Search every combination of n blocks into n programmable blocks
Extremely long run times (hours)
Aggregation
Clusters nodes into subgraphs, continue adding blocks until unable to fit into programmable block
Unable to take advantage of convergence thus yields non-optimal results
1-input / 2-output 3 5 7 8 10 11 12 9 1 2 4 6 3 5 7 8 10 11 12 9 1 2 4 6
2-input / 3-output
Invalid configuration - packing terminated
2-input / 2-output 3 5 7 8 10 11 12 9 1 2 4 6
Developed a new heuristic – PareDown
Based on a decomposition method
Takes advantage of convergence
Unconstrained by depth at which heuristic looks ahead
Runtime complexity O(n2)
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning
Code Generation 1
C Code

13. Synthesis -- Code Generation
For each partition a syntax tree is generated to represent equivalent functionality of the partition
Able to generate C code for each partition to download unto a programmable block
Simulator’s interpreter able to evaluate syntax tree and simulate corresponding behavior
Button
Splitter
LED
PROG
C Code
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning
Code Generation 1
C Code

14. Experiments - Real Designs
Executed decomposition and exhaustive search algorithms
2 GHz AMD Athlon XP PC
Partitioned 15 real designs, developed independently from our purposes of synthesis
Averages for Exhaustive Search
Averages for “PareDown” Decomposition
Inner Blocks (Original)
Design Name
Inner Blocks (Total)
Inner Blocks (Prog.)
Time
Block Overhead
% Overhead 2
Ignition Illuminator 1
< 1 ms
0 %
Night Lamp Controller
Entry Gate Detector
Carpool Alert 3
Cafeteria Food Alert
Podium Timer 2
Any Window Open Alarm
Two Button Light 5
Doorbell Extender 1 6
Doorbell Extender 2
9 ms 8
Podium Timer 3
125 ms 10
Noise At Night Detector 4
4.79 s 19
Two-Zone Security System --
Motion on Property Alert 23
Timed Passage 14
Corresponding runtime
Notice – unable to partition larger designs (did not finish after hours)
Initial # of internal blocks
Using exhaustive search, resulting # of internal blocks after partitioning
Of the resulting # of internal block, the # that are programmable blocks
All designs yield optimal partition
Executed in reasonable amount of time
Ran decomposition heuristic to obtain
# of inner nodes
# of programmable nodes
runtime

15. Results - Random Designs
Nearly 10,000 randomly-generated designs were also tested
Averages for Exhaustive Search
Averages for “PareDown” Decomposition
Inner Blocks (Original)
Number of Designs
Inner Blocks (Total)
Inner Blocks (Prog.)
Time
Block Overhead
% Overhead 3
1531
1.83
0.81
< 1 ms
1.87
0.79
0.04
2 % 4
982
2.24
1.22
2.33
1.10
0.09
4 % 5
542
2.51
1.52
1.33 ms
2.62
1.32
0.11 6
432
3.08
1.74
6.56 ms
3.36
1.49
0.28
9 % 7
447
3.77
2.00
25.52 ms
4.09
1.73
0.32
8 % 8
350
4.11
2.32 ms
4.56
1.93
0.45
11 % 9
340
4.67
2.60 ms
5.24
2.17
0.57
12 % 10
199
5.04
2.93
4.53 s
5.76
2.45
0.69
14 % 11
170
5.47
3.20
31.77 s
6.29
2.59
0.82
15 % 12 31
4.58
3.23
3.67 min
4.87
2.58
0.29
6 % 13
6.84
3.17
29.93 min
7.83
2.83
0.99 14
1311 --
8.11
3.05 15
1184
8.67
3.32 20
928
11.09
4.70 25
691
13.93
5.97
1.86 ms 35
354
19.63
8.26
4.82 ms 45
165
25.43
10.62
13.28 ms
Randomly generated designs with varying internal block counts
Within 15% of optimal
(within 1 programmable block for most cases)
Maintains reasonable runs times at even at larger sizes
Ran exhaustive search to obtain
# of inner nodes
# of programmable nodes
runtime
Ran decomposition heuristic to obtain
# of inner nodes
# of programmable nodes
runtime

16. Conclusions and Future Work
Developed synthesis tool that:
Converts eBlocks network to minimum number of programmable nodes
With accompanying C code
Uses new partitioning heuristic that is fast and near-optimal
Present/Future Work
Variety of programmable blocks
Also consider more criteria (i.e. input/output, cost, power, delay)
Introduce higher-level eBlocks for more powerful capture
Apply tool to real applications
Pro-active healthcare (w/ Intel)
Agricultural monitoring (w/ Isca)
Environment monitoring (w/ UCR/UCLA)
Button
2-Input Logic
Inverter 1
Splitter
Prolonger
LED
PROG
C Code

17. Thank you for your attention.