1. Presented by Frank Gennari
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
Vote Collection: Each handler returns a set of votes on activating/deactivating modes
Vote Reconciliation: Votes and ACTs are examined to determine what mode changes should be made • Conflicts are resolved by vote priority
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
Shown
seqLoop W
Update
Reg
Set WS
Watch
WatchUI SS AS Z R L
Zero
Run
Shown
Lap
Stopwatch
StopwatchUI
ACTs
Enb E
Shown A
Chime
Modal
Processes C
Reg
Set
Alarm
AlarmUI
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
Allow verification of mode liveliness and safety properties
Expand debugging to directly use coordination information
Expand the mode manager framework to include hardware IP
Broaden the communication synthesis to support networked distributed embedded systems