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

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

17 of 17

Thank you for your attention.