ESIDE:ESIDE:An Integrated Development Environment forAn Integrated Development Environment for

Component-Based Embedded SystemsComponent-Based Embedded Systems

Nicholas T. Pilkington, Juncao Li, and Fei XieDepartment of Computer Science

Portland State University

2

Agenda

1.1. Problems and Our ContributionProblems and Our Contribution

2. EADL Language as Basis of ESIDE

3. The ESIDE Environment

4. Case Study: the TinyOS Platform

5. Experiences with ESIDE

6. Future Work

3

Problems of Co-Development

• The hardware/software boundary…The hardware/software boundary…– interface is often specified implicitly.– tradeoffs insufficiently exploited.

• Simulation and formal verification…Simulation and formal verification…– are left as a final step before deployment.– require separate tools and interfaces.

• Embedded system development…Embedded system development…– is done without explicit support for re-use– or re-used modules introduce high overhead

4

Our Contribution

• The Embedded System IDE (ESIDE)The Embedded System IDE (ESIDE)– Based on the EADL language

– Provides a unified environment for…• Concurrent Hardware/Software Co-Development

• Co-Simulation, Co-Verification & Co-Synthesis

– Abstracts architecture from implementation

– Unifies development across all “platforms”

• Experiences with ESIDE Experiences with ESIDE – Remodel existing component-based embedded systems

– Education tool on component-based design in Advanced Software Engineering Course

5

Agenda

1. Problems and Our Contribution

2.2. EADL Language as Basis of ESIDEEADL Language as Basis of ESIDE

3. The ESIDE Environment

4. Case Study: the TinyOS Platform

5. Experiences with ESIDE

6. Future Work

6

Embedded Architecture Description Language (EADL)

• Architecture-only specification– No runtime semantics

– Can be initialized to different embedded platforms

• Encourages re-use on multiple levels of abstraction– Ports, components, component templates, and patterns

• Formal properties specified at design-time

• E.g., initialization of EADL to a platform

SW Semantics(e.g., nesC)

Bridge Semantics(BSL)

HW Semantics(e.g., Verilog)

Embedded Architecture Description Language

7

Overview of the Language Constructs

Entities Templates

Port• Service-oriented grouping of events

• Service provides-uses relationship

Port Type• Event co-relation similarity

Component• Unit of reuse

• Component interface based on ports

Component Template• Component external similarity

Architecture• Sub-components

• Sub-component inter-connections

Architectural Pattern• Component internal similarity

8

EADL - An Example

software component TimerC { interface { provides StdControl, TimerP as Timer; uses PowerManagement, Clock, IOH; mapping(Timer, TimerM.Timer); mapping(StdControl, TimerM.StdControl); mapping(PowerManagement,TimerM.PowerManagement); mapping(Clock, TimerM.Clock); mapping(IOH, TimerM.IOH); } configuration { component TimerM; component NoLeds; connection(NoLeds.Leds, TimerM.Leds); } properties { assertion ClockP1 s1: After_Eventually_(StdControl.init.call=TRUE, Clock.setRate.call=TRUE) } }

9

Agenda

1. Problems and Our Contribution

2. EADL Language as Basis of ESIDE

3.3. The ESIDE EnvironmentThe ESIDE Environment

4. Case Study: the TinyOS Platform

5. Experiences with ESIDE

6. Future Work

10

Main Features of ESIDE

• Platform-Based DevelopmentPlatform-Based Development– Choose your own native languages– Platform induces semantics into EADL architecture

• Component-Based Co-Design InterfaceComponent-Based Co-Design Interface– The central aspect of Co-Development– Simple, GUI-based drag ‘n drop interface

• Highly Accessible Simulation & VerificationHighly Accessible Simulation & Verification– Same interface for all development stages– Invoke at any time, on partial implementations

• One-Touch Native Language SynthesisOne-Touch Native Language Synthesis– Leverage native language tools to compile…– The tools are included in the platform package

11

ESIDE Architecture and Features

12

Platform-Based Development

• Platforms Provide…– Semantics

• Native Languages (HW, SW & Bridge)

– Native Tools• Co-Simulation Tools and Features• Co-Verification Tools and Features• Synthesizers from EADL to native languages

– A Platform Library of Reusable EADL Constructs• Ports, components, component templates, and architecture

patterns

13

14

Co-Design

• Re-thinking the HW/SW relationshipRe-thinking the HW/SW relationship– Do away with the old stack-based approach– Hybrid components join HW and SW

• Re-use is independent of the HW/SW boundary

– Bridge hides HW/SW communication details• Makes the HW/SW component interfaces explicit and

clear

• Component-Based DevelopmentComponent-Based Development– Interface functionality encapsulated by ports– Behavioral functionality by components– Common design trends captured by patterns

15

Co-Simulation

• Co-Simulation is a view-based feature• Simulation is supported at TL or RTL levels• Native language tools run HW/SW simultaneously• Nature of the simulator is highly platform-dependent

16

Co-Verification

• Properties are specified at design-time, not afterward • Verify at any time, even on partial implementations• CBD allows for property-based abstractions (efficiency)• Current system supports temporal-based assertions

17

Agenda

1. Problems and Our Contribution

2. EADL Language as Basis of ESIDE

3. The ESIDE Environment

4.4. Case Study: the TinyOS PlatformCase Study: the TinyOS Platform

5. Experiences with ESIDE

6. Future Work

18

The Platform Languages

• The nesC software languageThe nesC software language– Developed at UC Berkeley for TinyOS– Component-based specification language– No dynamic memory allocation– Intrinsic support for concurrency and atomicity

• The Verilog hardware languageThe Verilog hardware language– TinyOS is a software language only– We re-designed the Mica platform in Verilog

• The BSL bridge languageThe BSL bridge language– Developed by our team specifically for this platform– Explicitly describes the interface between HW&SW– Provides Transactors for transaction-level simulation– Compiles to C (nesC compatible) and Verilog code

19

Simulation on the TinyOS Platform

20

Agenda

1. Problems and Our Contribution

2. EADL Language as Basis of ESIDE

3. The ESIDE Environment

4. Case Study: the TinyOS Platform

5.5. Experiences with ESIDEExperiences with ESIDE

6. Future Work

21

Experiences with ESIDE

• We remodeled 12 TinyOS-Based SystemsWe remodeled 12 TinyOS-Based Systems– Faithfully preserved the HW/SW stack architecture– Converted the code base with very little modification

• Encapsulation of components• Componentized HW/SW interfaces• One-to-many port mappings

– Specified formal properties on the systems– Performed verification and simulation– Remodeled systems can be synthesized to TinyOS

deployable code

22

Experiences with ESIDE (cont.)

• We gave ESIDE to students at PSUWe gave ESIDE to students at PSU– were from the Advanced Software Engineering Class – had no experience in embedded system design– had no experience in formal verification– were able to design complex and interesting systems

• A TinyOS networked sensor system (>50 components)• A smart home system (>30 components)

23

Remodeling TinyOS Systems

# of components in Mica platform library 55 64

# of components in PC platform library 58 63

# of ports/interfaces in Mica platform library 30 49

# of ports/interfaces in PC platform library 29 46

# of components specific for each system 38 41

# of ports/interfaces specific for each system 8 10

# of hardware components developed N/A 12

# of bridge components developed N/A 2

24

Simulating the TinyOS Systems

Co-Simulation Co-Verification

System RTL

(sec)

TL

(sec)

Time

(sec)

Memory

(MB)

SenseTask 1.887 0.004 22.34 1.644

SenseToLeds 1.587 0.003 27.02 3.765

SenseToRFM 6.837 0.008 52.61 3.806

CodeBlue 7.456 0.011 34.66 5.792

25

Agenda

1. Problems and Our Contribution

2. EADL Language as Basis of ESIDE

3. The ESIDE Environment

4. Case Study: the TinyOS Platform

5. Experiences with ESIDE

6.6. Future WorkFuture Work

26

Future Work

• Visual error trace playback featureVisual error trace playback feature– Simulation: Show the user what’s happening– Verification: Play back problematic execution

• Expressiveness of formal propertiesExpressiveness of formal properties– Include support for resource utilization, e.g.

• Expand the collection of platformsExpand the collection of platforms– Microsoft Invisible Computing Platform

27

Questions?

http://web.cecs.pdx.edu/~xie/co-ver/co-ver-home.htm

Nicholas T. Pilkington (nickp@cs.pdx.edu)Juncao Li (juncao@cs.pdx.edu)

Dr. Fei Xie (xie@cs.pdx.edu)