IPCHINOOK: An Integrated IP-based Design Framework for Distributed Embedded Systems - PowerPoint PPT Presentation

Loading...

PPT – IPCHINOOK: An Integrated IP-based Design Framework for Distributed Embedded Systems PowerPoint presentation | free to view - id: 779542-MzRiN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

IPCHINOOK: An Integrated IP-based Design Framework for Distributed Embedded Systems

Description:

IPCHINOOK: An Integrated IP-based Design Framework for Distributed Embedded Systems Written by Pai Chou, Ross Ortega, Ken Hines, Kurt Partridge, and Gaetano Borriello – PowerPoint PPT presentation

Number of Views:112
Avg rating:3.0/5.0
Slides: 20
Provided by: genn166
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: IPCHINOOK: An Integrated IP-based Design Framework for Distributed Embedded Systems


1
IPCHINOOK An Integrated IP-based Design
Framework for Distributed Embedded Systems
  • Written by Pai Chou, Ross Ortega, Ken Hines, Kurt
    Partridge, and Gaetano Borriello
  • Presented by Frank Gennari

2
Overview of IPCHINOOK
  • IPCHINOOK is a distributed embedded system
    design,
  • synthesis, and simulation tool.
  • Component-based design
  • Stresses reuse of software modules
  • Synthesizes communication and synchronization
    instructions
  • Co-simulation engine for rapid evaluation
  • Integrated user interface
  • High-level abstractions of hardware and software
  • Automated generation of error-prone details

3
Problems Addressed by IPCHINOOK
  • IP Composition
  • Problem Limitations of fixed APIs, time
    consuming custom integration
  • code, duplicated component state
  • Solution ipChinook uses a separate component
    assembly step leading to
  • reusable composition constructs
  • Communication Synthesis
  • Problem Custom intermodule communication
    software must be written
  • based on system architecture
  • Solution Automating this process quickly
    leads to a more portable solution
  • Rapid Evaluation
  • Problem Fast co-simulation is needed at
    different levels of the design
  • process and profiling is
    required for feedback to the designer
  • Solution Selective focus provides more
    details for parts of the simulation

4
Overview of IPCHINOOK Design Framework
Available Devices, Hardware Topology
System Functionality
5
Modal Processes
  • Consist of
  • Ports provide logical communication contact
    points for
  • interprocess communication
  • Channels connect an output port to one or more
    input ports
  • Events are arrivals of messages that trigger a
    handler
  • Handlers send messages and return mode changes
    in steps
  • Can send messages to output ports with one
    step delay
  • due to input buffering
  • Modes specify a mapping from ports to handlers
  • They can be independently active or
    inactive

6
Active Mode Change Process
  1. Vote Collection Each handler returns a set of
    votes on activating/deactivating modes
  2. Vote Reconciliation Votes and ACTs are examined
    to determine what mode changes should be made
    Conflicts are resolved by vote
    priority
  3. Vote Distribution New set of active and inactive
    modes are distributed to affected modal processes

7
Abstract Control Types (ACTs)
ACTs are high-level primitives that coordinate,
adapt, and define protocols and modify votes to
maintain mode relationships ipChinook supports a
library of reusable ACTs as well as user-defined
ACTs The seqLoop ACT controls the mode of the
stopwatch, an Esterel example
8
Esterel Wristwatch Example
seqLoop
Shown
W
Update
Set
Reg
WS
Watch
WatchUI
SS
AS
Z
R
L
Zero
Run
Shown
Lap
Stopwatch
StopwatchUI
ACTs
Enb
Shown
E
Chime
A
Modal Processes
Set
Reg
C
AlarmUI
Alarm
UI-independent composition
UI-specific composition
9
Target Description
  • Target description
  • Defines a target architecture
  • Processors (microprocessor or FPGA)
  • Operating System
  • Communication Protocols (I2C, CAN, SCSI, USB,
  • IrDA,
    Ethernet)
  • Defines the allocation function that maps modal
    processes and channels to the architecture
  • Processes Processors (running multiple
    processes)
  • Logical comm channels architectural comm links

10
Mode Manager Synthesis
  • A mode manager is the part of the run-time
    system that manages control communications
    according to the ACTs
  • Mode managers handle system state maintenance
  • A mode manager for each processor is
    automatically
  • synthesized for heterogeneous distributed systems
  • Tradeoff of space, performance, and determinism
  • Mode, event, comm., and dataflow synchrony
    models
  • A centralized mode manager is synthesized for
    simulation
  • Single processor mode synchrony

11
Communication and Interface Synthesis
  • Communication synthesis
  • Abstract communication protocols implemented on
    the target architecture allow modal processes to
    exchange messages
  • Interface Synthesis
  • Generates interfacing logic and low-level device
    drivers to connect processing elements together
  • Abstract communication protocols implemented with
    busses
  • Output port annotated with blocking style and
    deadline constraints
  • Input port annotated with queuing info (size and
    overflow behavior)
  • Target independent target dependent
  • System architects can investigate tradeoffs,
    explore design space

12
Generated Communication Structure
Designer Abstraction
Producer Process
Consumer Process
OutPort
InPort
Message Router
Device Driver
Device Driver
Generated Infrastructure
Comm. Chip
Comm. Chip
13
Communication Synthesis Steps
  • Multi-hop deadline distribution
  • Automatically creates hop processes to route a
    message through intermediate processors and
    busses
  • Deadline is distributed along entire path
  • Bus protocol attribute synthesis
  • Protocol determined based on parameters of all
    messages
  • Message Ids, processor Ids, priorities, and
    queues
  • Synthesized with routing information for RTOS
  • Message router generation
  • Device driver instantiation
  • Device drivers abstract the designer from the
    protocol
  • Instantiated from a protocol library
  • Read and write to physical processor pins
  • Glue logic for I/O ports or memory mapped IO

14
HW/SW Co-Simulation - Pia
  • Designers can execute a model at any synthesis
    stage
  • Selective focus
  • Highest level of abstraction fastest
    simulation speed
  • Designers can view low-level details of regions
    of interest
  • Can dynamically zoom in and out of simulation
    regions
  • Support for high-level debugging
  • Modal processes and ACTs
  • Step through mode traces and event traces

15
Selective Focus
  • Pia keeps track of several versions of interface
    entry calls and selects the best version
    (runlevel) based on level of detail
  • Coordinate runlevels between communicating
    interfaces
  • Must not leave residual state behind
  • Runlevel must be indistinguishable to the
    applications and interfaces that use it
  • Communications are tagged with runlevel to solve
    these problems
  • Example WubbleU
  • Small PDA with wireless connection

16
IrDA Protocol Stack
17
Hardware Simulation
  • Real hardware can also be simulated
  • Simulator nodes can be distributed across the
    internet
  • Vendors can put parts on the web and allow
    designers to test them remotely
  • Designers can avoid building a hardware
    prototype
  • IP providers can limit access to their products
  • Can exploit parallel simulation with remote hosts

18
Conclusions
  • IPCHINOOK is a comprehensive HW/SW cosynthesis
    framework for distributed embedded systems.
  • Design space exploration is enabled through
    mapping a high-level design onto various target
    architectures
  • Design reuse and retargetability are important
    aspects to system design
  • Simulation allows validation of design at
    different synthesis stages
  • Selective focus results in an efficient yet
    detailed simulation
  • Handlers and tools were written in Java

19
Future Work
  1. Allow verification of mode liveliness and safety
    properties
  2. Expand debugging to directly use coordination
    information
  3. Expand the mode manager framework to include
    hardware IP
  4. Broaden the communication synthesis to support
    networked distributed embedded systems
About PowerShow.com