IP C HINOOK: An Integrated IP- based Design Framework for Distributed Embedded Systems Written by...
-
date post
20-Dec-2015 -
Category
Documents
-
view
221 -
download
1
Transcript of IP C HINOOK: An Integrated IP- based Design Framework for Distributed Embedded Systems Written by...
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
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
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
Overview of IPCHINOOK Design Framework
SystemFunctionality
Available Devices,Hardware Topology
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
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
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
Esterel Wristwatch Example
Update
Zero Run
Lap
ShownSetReg
Shown
ChimeEnb
StopwatchUI
WatchUI
AlarmUI
AS
SS
WS
seqLoop
ShownSetReg
UI-independent composition UI-specific composition
Watch
Z R
E
L
CA
W
Alarm
Stopwatch
Modal Processes
ACTs
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
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
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
Generated Communication Structure
Producer Process
OutPort
Device Driver
Comm. Chip Comm. Chip
Device Driver
Message Router
InPort
Consumer ProcessDesignerAbstraction
GeneratedInfrastructure
Communication Synthesis Steps
1. Multi-hop deadline distribution Automatically creates hop processes to route a message
through intermediate processors and busses Deadline is distributed along entire path
2. 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
3. Message router generation
4. 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
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
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
IrDA Protocol Stack
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
ConclusionsIPCHINOOK 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
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