Presentation is loading. Please wait.

Presentation is loading. Please wait.

System Synthesis for Networks of Programmable Blocks Ryan Mannion, Harry Hsieh, Susan Cotterell, Frank Vahid * Department of Computer Science and Engineering.

Similar presentations


Presentation on theme: "System Synthesis for Networks of Programmable Blocks Ryan Mannion, Harry Hsieh, Susan Cotterell, Frank Vahid * Department of Computer Science and Engineering."— Presentation transcript:

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, 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 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 Automation http://www.smarthome.com Environmental Monitoring http://www.greatduckisland.net/ http://today.cs.berkeley.edu/retreat-6-03/ Military Applications http://robotics.eecs.berkeley.edu/~pister/29Palms0103/ Medical Monitoring http://www.eecs.harvard.edu/~mdw/proj/codeblue/ Structure/Building Monitoring http://www.mrr.dot.state.mn.us/research/MnROAD_Project/MnROADProject.asp

3 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 Hill http://www.dustnetworks.com/ http://www.smarthome.com http://www.xbow.com/ Flexible, hard to program Easy to use, inflexible

4 4 of 17 Talk Outline  Brief introduction to eBlocks  Synthesis Motivation Methodology  Experiments Button 2-Input Logic Inverter 1 0 1 0 Splitter Prolonger 123456789 Prolonger 123456789 LED Button Splitter LED PROG C Code eBlock capture tool Synthesis Network nodes and programs

5 5 of 17 eBlocks Overview 1 0 1 0 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 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 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 7 of 17 Building eBlocks Systems  The same basic blocks can be used in a variety of applications 1 0 1 0 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 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 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 Button 2-Input Logic Inverter 1 0 1 0 Splitter Prolonger 1 2 3 4 5 6 7 8 9 Prolonger 1 2 3 4 5 6 7 8 9 LED Button LED PROG

9 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 Design Entry/ Simulation Interpreter GUI Synthesis PartitioningCode Generation

10 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 PartitioningCode Generation 1 0 1 0 C Code

11 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 PartitioningCode Generation 1 0 1 0 C Code Button 2-Input Logic Inverter 1 0 1 0 Splitter Prolonger 123456789 Prolonger 123456789 LED Button Splitter LED PROG

12 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 12 9 1 2 4 6 2-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 Design Entry/ Simulation Interpreter GUI Synthesis PartitioningCode Generation 1 0 1 0 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(n 2 )

13 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 PartitioningCode Generation 1 0 1 0 C Code Button Splitter LED PROG C Code

14 14 of 17 Experiments - Real Designs Averages for Exhaustive SearchAverages for “PareDown” Decomposition Inner Blocks (Original) Design Name Inner Blocks (Total) Inner Blocks (Prog.) TimeInner Blocks (Total) Inner Blocks (Prog.) TimeBlock Overhead % Overhead 2Ignition Illuminator11< 1 ms11 00 % 2Night Lamp Controller11< 1 ms11 00 % 2Entry Gate Detector11< 1 ms11 00 % 2Carpool Alert11< 1 ms11 00 % 3Cafeteria Food Alert11< 1 ms11 00 % 3Podium Timer 211< 1 ms11 00 % 3Any Window Open Alarm30< 1 ms30 00 % 3Two Button Light31< 1 ms31 00 % 5Doorbell Extender 150< 1 ms50 00 % 6Doorbell Extender 2609 ms60< 1 ms00 % 8Podium Timer 333125 ms32< 1 ms00 % 10Noise At Night Detector644.79 s64< 1 ms00 % 19Two-Zone Security System-- 103< 1 ms-- 19Motion on Property Alert-- 190< 1 ms-- 23Timed Passage-- 145< 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 blocks Using exhaustive search, resulting # of internal blocks after partitioning Of the resulting # of internal block, the # that are programmable blocks Corresponding runtime Notice – 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 15 of 17 Results - Random Designs Averages for Exhaustive SearchAverages for “PareDown” Decomposition Inner Blocks (Original) Number of Designs Inner Blocks (Total) Inner Blocks (Prog.) TimeInner Blocks (Total) Inner Blocks (Prog.) TimeBlock Overhead % Overhead 315311.830.81< 1 ms1.870.79< 1 ms0.042 % 49822.241.22< 1 ms2.331.10< 1 ms0.094 % 55422.511.521.33 ms2.621.32< 1 ms0.114 % 64323.081.746.56 ms3.361.49< 1 ms0.289 % 74473.772.0025.52 ms4.091.73< 1 ms0.328 % 83504.112.32122.97 ms4.561.93< 1 ms0.4511 % 93404.672.60719.90 ms5.242.17< 1 ms0.5712 % 101995.042.934.53 s5.762.45< 1 ms0.6914 % 111705.473.2031.77 s6.292.59< 1 ms0.8215 % 12314.583.233.67 min4.872.58< 1 ms0.296 % 1366.843.1729.93 min7.832.83< 1 ms0.9914 % 141311-- 8.113.05< 1 ms-- 151184-- 8.673.32< 1 ms-- 20928-- 11.094.70< 1 ms-- 25691-- 13.935.971.86 ms-- 35354-- 19.638.264.82 ms-- 45165-- 25.4310.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 counts Ran 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 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 1 0 Splitter Prolonger 123456789 Prolonger 123456789 LED Button Splitter LED PROG C Code

17 17 of 17 Thank you for your attention.


Download ppt "System Synthesis for Networks of Programmable Blocks Ryan Mannion, Harry Hsieh, Susan Cotterell, Frank Vahid * Department of Computer Science and Engineering."

Similar presentations


Ads by Google