System Synthesis for Networks of Programmable Blocks Ryan Mannion, Harry Hsieh, Susan Cotterell,...
-
date post
21-Dec-2015 -
Category
Documents
-
view
214 -
download
0
Transcript of System Synthesis for Networks of Programmable Blocks Ryan Mannion, Harry Hsieh, Susan Cotterell,...
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, vahid}@cs.ucr.edu;
http://www.cs.ucr.edu/eblocks* 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 of 17
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)
Home Automationhttp://www.smarthome.com
Environmental Monitoringhttp://www.greatduckisland.net/http://today.cs.berkeley.edu/retreat-6-03/
Military Applicationshttp://robotics.eecs.berkeley.edu/~pister/29Palms0103/
Medical Monitoringhttp://www.eecs.harvard.edu/~mdw/proj/codeblue/
Structure/Building Monitoringhttp://www.mrr.dot.state.mn.us/research/MnROAD_Project/MnROADProject.asp
3 of 17
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
Introduction
Photo: Jason Hillhttp://www.dustnetworks.com/
http://www.smarthome.com
http://www.xbow.com/
Flexib
le,
hard
to p
rogra
m
Easy
to u
se,
inflexib
le
4 of 17
Talk Outline
Brief introduction to eBlocks Synthesis
Motivation Methodology
Experiments
Button
2-Input Logic
Inverter
1 0
Inverter
1 0
Splitter
Splitter
Splitter
Prolonger
123456789
Prolonger
123456789 LED
LED
LED
Button
Splitter
LED
LED
LED
PROGPROG
C Code C Code
eBlock capture tool
Synthesis
Network nodes and
programs
5 of 17
eBlocks Overview
1 0
1 0
C Code C Code
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
Toggle
Electric Relay
Magnetic Contact Switch
Light Sensor
Splitter
Tripper
Motion Sensor
2-Input Logic
Button
LED
6 of 17
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
Creating an application with eBlocks
Create an application to detect if the garage door is left open at night
1 0
1 0
C Code C Code
Light Sensor
We want to detect night – use light sensor
Light Sensor
Magnetic Contact Switch
We want to know if garage door open – use contact switch
Magnetic Contact Switch
2-Input Logic
A’B’
LED Need something to indicate garage open at night – use led
LED
Plug pieces together and the system is done!
7 of 17
Building eBlocks Systems
The same basic blocks can be used in a variety of applications
1 0
1 0
C Code C Code
2-Input Logic
A’B’
Light Sensor
Magnetic Contact Switch
LED
Garage Door Open At Night Detector
Motion on Property Detector
Motion Sensor
Motion Sensor
2-Input Logic
A+B
Prolonger
1 2 3 4 5 6 7 8 9
Beeper
Sleepwalker at Night Alarm
Tripper
Motion Sensor
2-Input Logic
A’B
Light Sensor
Button
Beeper
Animal Videoing System
Motion Sensor
2-Input Logic
A+B
Prolonger
1 2 3 4 5 6 7 8 9 eBlock to Camera Interface
Light Sensor
8 of 17
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
Motivation - Programmable Blocks
1 0
1 0
C Code C Code
Button
2-Input Logic
Inverter
1 0
Inverter
1 0
Splitter
Splitter
Prolonger
1 2 3 4 5 6 7 8 9
Prolonger
1 2 3 4 5 6 7 8 9LED
LED
ButtonLED
LED
PROG
9 of 17
Synthesis tool Must map network of pre-
defined blocks to programmable blocks
Three stages Design entry/simulation Synthesis -- Partitioning Synthesis -- Code generation
Synthesis
1 0
1 0
C Code C Code
Design Entry/ Simulation
Interpreter
GUI
Synthesis
Partitioning Code Generation
10 of 17
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 0
1 0
C Code C Code
11 of 17
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
Synthesis -- Partitioning
Design Entry/
Simulation
Interpreter
GUI
Synthesis
Partitioning Code Generation
1 0
1 0
C Code C Code
Button
2-Input Logic
Inverter
1 0
Inverter
1 0
Splitter
Splitter
Splitter
Prolonger
123456789
Prolonger
123456789 LED
LED
LED
Button
Splitter
LED
LED
LED
PROGPROG
12 of 17
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
129
1
2
4
6
2-input / 2-output
3
5
7
8
10
11
129
1
2
4
6
3
5
7
8
10
11
129
1
2
4
6
2-input / 3-
outputInvalid configuration -
packing terminated
Design Entry/
Simulation
Interpreter
GUI
Synthesis
Partitioning Code Generation
1 0
1 0
C Code C Code
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)
13 of 17
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
Synthesis -- Code Generation
Design Entry/
Simulation
Interpreter
GUI
Synthesis
Partitioning Code Generation
1 0
1 0
C Code C Code
Button
Splitter
LED
LED
LED
PROGPROG
C Code C Code
14 of 17
Experiments - Real Designs
Averages for Exhaustive Search Averages for “PareDown” Decomposition
Inner Blocks
(Original)Design Name
Inner Blocks (Total)
Inner Blocks (Prog.)
Time Inner Blocks (Total)
Inner Blocks (Prog.)
Time Block Overhead
% Overhead
2 Ignition Illuminator 1 1 < 1 ms 1 1 < 1 ms 0 0 %
2 Night Lamp Controller 1 1 < 1 ms 1 1 < 1 ms 0 0 %
2 Entry Gate Detector 1 1 < 1 ms 1 1 < 1 ms 0 0 %
2 Carpool Alert 1 1 < 1 ms 1 1 < 1 ms 0 0 %
3 Cafeteria Food Alert 1 1 < 1 ms 1 1 < 1 ms 0 0 %
3 Podium Timer 2 1 1 < 1 ms 1 1 < 1 ms 0 0 %
3Any Window Open
Alarm3 0 < 1 ms 3 0 < 1 ms 0 0 %
3 Two Button Light 3 1 < 1 ms 3 1 < 1 ms 0 0 %
5 Doorbell Extender 1 5 0 < 1 ms 5 0 < 1 ms 0 0 %
6 Doorbell Extender 2 6 0 9 ms 6 0 < 1 ms 0 0 %
8 Podium Timer 3 3 3 125 ms 3 2 < 1 ms 0 0 %
10 Noise At Night Detector 6 4 4.79 s 6 4 < 1 ms 0 0 %
19Two-Zone Security
System-- -- -- 10 3 < 1 ms -- --
19 Motion on Property Alert -- -- -- 19 0 < 1 ms -- --
23 Timed Passage -- -- -- 14 5 < 1 ms -- --
Executed decomposition and exhaustive search algorithms 2 GHz AMD Athlon XP PC Partitioned 15 real designs, developed independently from our purposes of
synthesis
Initial # of internal blocksUsing exhaustive search,
resulting # of internal blocks after partitioningOf the resulting # of internal block, the
# that are programmable blocks
Corresponding runtimeNotice – unable to partition larger designs (did not finish after
hours)
• All designs yield optimal partition• Executed in reasonable amount of time
Ran decomposition heuristic to obtain• # of inner nodes• # of programmable nodes• runtime
15 of 17
Results - Random Designs
Averages for Exhaustive Search Averages for “PareDown” Decomposition
Inner Blocks
(Original)
Number of
Designs
Inner Blocks (Total)
Inner Blocks (Prog.)
Time Inner Blocks (Total)
Inner Blocks (Prog.)
Time Block Overhead
% Overhead
3 1531 1.83 0.81 < 1 ms 1.87 0.79 < 1 ms 0.04 2 %
4 982 2.24 1.22 < 1 ms 2.33 1.10 < 1 ms 0.09 4 %
5 542 2.51 1.52 1.33 ms 2.62 1.32 < 1 ms 0.11 4 %
6 432 3.08 1.74 6.56 ms 3.36 1.49 < 1 ms 0.28 9 %
7 447 3.77 2.00 25.52 ms 4.09 1.73 < 1 ms 0.32 8 %
8 350 4.11 2.32122.97
ms4.56 1.93 < 1 ms 0.45 11 %
9 340 4.67 2.60719.90
ms5.24 2.17 < 1 ms 0.57 12 %
10 199 5.04 2.93 4.53 s 5.76 2.45 < 1 ms 0.69 14 %
11 170 5.47 3.20 31.77 s 6.29 2.59 < 1 ms 0.82 15 %
12 31 4.58 3.23 3.67 min 4.87 2.58 < 1 ms 0.29 6 %
13 6 6.84 3.1729.93
min7.83 2.83 < 1 ms 0.99 14 %
14 1311 -- -- -- 8.11 3.05 < 1 ms -- --
15 1184 -- -- -- 8.67 3.32 < 1 ms -- --
20 928 -- -- -- 11.09 4.70 < 1 ms -- --
25 691 -- -- -- 13.93 5.97 1.86 ms -- --
35 354 -- -- -- 19.63 8.26 4.82 ms -- --
45 165 -- -- -- 25.43 10.6213.28
ms-- --
Nearly 10,000 randomly-generated designs were also tested
Within 15% of optimal
(within 1 programmable block for most cases)
Randomly generated designs with varying internal block
countsRan exhaustive search to obtain• # of inner nodes• # of programmable nodes• runtime
Maintains reasonable runs times at even at larger sizes
Ran decomposition heuristic to obtain• # of inner nodes• # of programmable nodes• runtime
16 of 17
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 0
Inverter
1 0
Splitter
Splitter
Splitter
Prolonger
123456789
Prolonger
123456789 LED
LED
LED
Button
Splitter
LED
LED
LED
PROGPROG
C Code C Code