The Chinook hardware/software co-synthesis system.
Abstract: Designers of embedded systems are facing ever tighter constraints on design time, but computer-aided design tools for embedded systems have not kept pace with these trends. The Chinook co-synthesis system addresses the automation of the most time-consuming and error-prone tasks in embedded controller design, namely the synthesis of interface hardware and software needed to integrate system components, the migration of functions between processors or custom logic, and the co-simulation of the design before, during and after synthesis. This paper describes the principal elements of Chinook and discuss its application to a variety of embedded designs.
Introduction
Embedded system designers, in varied industry segments that include consumer electronics, automotive
control, and medical equipment, are facing increased pressure to create products quickly
and inexpensively. This trend is coupled to the increasing levels of integration, performance,
and programmability achievable in off-the-shelf integrated circuits including microprocessors, programmable
logic, and devices such as LCDs, network interface controllers, and speech generators.
Designers find using these devices to be advantageous because of their low cost and the way in
which they facilitate rapid realization of designs not only for prototyping but for production as
well. In fact, with embedded controllers now found in everything from consumer electronics and
automobiles to smart credit cards and medical equipment, many products have declining lifetimes
that make custom integrated circuits a less economically viable option.
The job of the embedded system designer has also changed. In addition to time to market
constraints, the designer must worry about correctness and cost effectiveness of the implementation.
Thus, designers have a need to explore a large design space of potential solutions, yet no integrated
CAD tools are available to help them with this task. The design must be quickly defined and
simulated and then mapped onto the cheapest combination of components. Unlike general-purpose
computers embedded systems are designed and optimized to provide specific functionality. Thus,
the most time consuming and error-prone task in embedded system design is precisely the detailed
mapping of the abstract functional specification onto the target components. In fact, the process
is so time-consuming that many designers fix the target architecture and system components well
before a complete evaluation of the final system and perform only one mapping. This often leads
designers to over-design their systems with faster processors or larger capacity logic devices then
really needed, thereby increasing the cost. If the target architecture were to prove inadequate due
to performance or capacity constraints, designers would face a costly re-mapping process.
It is clear that design exploration tools to automate the mapping process and thus provide faster
feedback on design decisions are sorely needed. Many design automation tools and frameworks
have been proposed to address a few of these problems. These tools either look at high-level
specifications but do not assist with the actual implementation, or they help with individual parts
of the implementation but do not provide a system view. Examples of the former include behavioral
simulators and formal specification languages while examples of the latter include compilers, board
layout tools, and logic synthesis systems. Recently, tools for dealing with the hardware and software
portions of the system have been proposed, but these have not addressed the system integration
issues that dominate the design cycle.
2 Taxonomy of Hardware/Software Co-design
The field of hardware/software co-design of real-time embedded systems can be organized along
three principal dimensions: the implementation technology, the application domain, and the aspect
of the design cycle.
2.1 Technology
An embedded system may be implemented with a number of technologies, including off-the-shelf
components, programmable logic, and full-custom or semi-custom ASICs. Examples of such technologies
include interface controllers, FPGAs, standard processor cores, or cores that are either
custom designed or enhanced with custom datapath and I/O logic. The choice of technologies has
a significant impact on the price/performance of the embedded system. ASICs provide higher performance
but can be expensive to design and are difficult to modify once fabricated. FPGAs and
processors are reprogrammable and can be used to quickly prototype a system. Because they are
available in large quantities, they often have competitive price/performance ratios to custom logic.
Increasingly, more functionality is being moved into software because microprocessors can deliver
the desired performance, obviating the need for much custom logic. Thus, the design burden is
shifting to software and increases pressure to automate tasks such as device driver generation and
scheduling to meet real-time constraints.
2.2 Domains
Embedded systems can be divided into two principal domains, control-dominated and data-flow,
based upon the characteristics of the application. In the data-flow domain, data is sampled at
regular intervals and processed in the same order. The behavior of the system remains the same
over time. In each time step, a set of mathematical operators are applied to a window of data
samples. Digital signal processing (DSP) systems are the canonical example for the data-flow
domain. Control dominated-systems span a much wider range and are characterized by complex
conditional or modal behavior rather than math-intensive computations. An example of a control-dominated
system is a network controller or avionics control system. Of course, many systems
contain elements of both domains but usually one or the other dominates the designer's attention.
2.3 Design Problems
The problems in embedded systems design include specification of behavior and timing constraints,
partitioning, interfacing, scheduling, code-generation, analysis, simulation and debugging. Point
tools either exist or are being contemplated for all these aspects of the design process. We focus
our discussion of this dimension on control-dominated applications.
Specification captures the behavior and requirements of a design. This is for the most part done
informally using a mixture of natural language documents, pseudo-code, and block diagrams. This
approach has made design maintenance, upgrading, and retargeting very time intensive and sometimes
impossible. Several formal specification methods have been proposed including finite state
machines [4], Petri nets [18], and CSP [15]. Today's tools lie somewhere in the middle - specifications
are written in a high-level programming or hardware description language that is simulatable.
This enables some early validation of the design. There is still no accepted formalization of the
timing and performance constraints that are critical in many embedded applications.
these constraints explicitly represented, designers must devise and validate software schedules and
interactions between components by hand. Simulators can help with this task but are limited to
the tests performed explicitly. Formal verification or synthesis techniques are needed to guarantee
that constraints are satisfied.
Partitioning is the process of determining the components on which to implement portions of
system functionality. This may be a split between a processor and auxiliary logic or between a set
of processors. Attempts at automating partitioning have included simulated annealing algorithms
[9] and hardware to software migration [12] but have for the most part ignored the problems of
interfacing and communication between the parts. In fact, designers spend a large fraction of the
time in interfacing system components to each other and the operating environment (including
user interfaces) because it is where the bulk of errors lie. Yet, interfacing remains one of the least
addressed areas in many co-synthesis tools. The interfacing task may involve both hardware and
software aspects of the interface as well as low level timing concerns that may require glue logic.
Interface generation has been described in [20], though the synthesis of interface software is not
addressed.
Other aspects of the embedded system design cycle include retargetable code-generation (for
different off-the-shelf processors as well as custom designed ones). Performance estimation of software
is of critical importance and is required if partitioning to meet timing constraints is to be
done with confidence. Analysis tools are needed to predict execution times, and possibly the size,
of code fragments. Finally, simulators, debuggers, and profilers are needed to evaluate the final
design at a detailed level.
3 The Chinook Co-Synthesis System
At the University of Washington, our approach to the co-synthesis of real-time reactive embedded
systems is embodied in Chinook, a tool that generates complete design specifications given a single
high-level specification of the desired system functionality. Several features distinguish Chinook
from other work in this area. Each is motivated by the observations and concerns outlined in the
previous two sections. Using the taxonomy of section 2, Chinook is intended for control-dominated
designs constructed from off-the-shelf components. It addresses the aspects of the design process
whose automation will provide the most benefit to designers in terms of shortening the design
cycle, permitting more design space exploration, and automating tasks that are error-prone or
cumbersome.
The following elements of the Chinook system are where the principal innovations lie. It is
important to note that what makes Chinook unique is the combination of these elements rather
than any single one.
ffl Single specification. A designer writes one specification in a single specification language
with explicit timing/performance constraints rather than separate netlist, hardware descrip-
tion, and software languages all with implicit constraints. This is key to the retargetability
and maintainability of the design.
ffl One simulation environment. The high-level specification of the design can be simulated
directly to help debug the designer's intent as well as operational aspects of the design. The
final synthesized result, and any intermediate steps, can be simulated in the same environment
and augmented with additional tools (e.g., debuggers and profilers for software).
Comprehensive software scheduling. Chinook synthesizes the appropriate software architecture
for the timing requirements of the system: low-level partitioning to ensure signal-
4Verilog
Specification
parser
Processor &
Device Libraries
driver
synthesizer
scheduler
comm.
synthesizer
interface
synthesizer
code
generator
netlist
program
Behavioral
Simulation
Structural
Simulation
Mixed
Simulation

Figure

1: The Chinook Co-Synthesis System
ing constraints are satisfied (possibly by synthesized hardware modules), static fine-grained
scheduling to tailor device drivers, and customized dynamic schedulers and interrupt handlers.
ffl Interface synthesis. Interface hardware and software between system components (in-
cluding peripheral devices as well as multiple processors) is automatically synthesized with
appropriate changes reflected in interprocessor communication and device drivers.
ffl Complete information for physical prototyping. Chinook generates a complete netlist
for assembling the system and complete code for its processors to run. After co-synthesis, the
system is ready to be assembled and evaluated in its intended environment.
The Chinook co-synthesis system consists of the parser, the processor/device library, the
device-driver synthesizer, the interface synthesizer, the communication synthesizer, the scheduler,
and the simulator (see Figure 1). The parser accepts a system description in annotated Verilog. In
addition to a behavioral specification, it also contains a structural specification that instantiates
the principal components of the system, including processors, peripheral devices, and standard
interfaces. The device library contains detailed generic specification of device interfaces (in the
form of timing diagrams and Verilog code) and models for their simulation (in C). For processors it
contains specifications of their interfaces as well as timing schemas for software run-time estimation
[19]. The device-driver synthesizer compiles the timing diagrams and Verilog device drivers into
customized code for the given processor and makes low-level partitioning decisions to meet signaling
constraints. The interface synthesizer allocates I/O resources to connect a processor to the peripheral
devices it will control, and customizes the access routines to reflect these assignments. The
communication synthesizer generates the hardware and software needed for interprocessor commu-
nication. With all resources allocated, the scheduler generates C code to meet real-time constraints
in software. The C code is compiled by a processor-specific compiler. Chinook also outputs the
netlist, including the necessary glue logic, to construct the desired system.
Chinook does not attempt does not attempt several tasks. It does no high-level partitioning
of functionality between hardware or software or between processors. Instead, it assumes that
designers involved in design exploration are in a better position to make these assignments at the
module and/or task level. Chinook does not compile code to the target processor(s). It assumes
not only the existence of the appropriate C compilers but also that these will be able to provide
the scheduler with feedback on the expected run-time of code fragments. Finally, in its focus on
real-time reactive systems, it assumes that caches are not employed.
4 Specification
The single Verilog file provided as input to Chinook contains both behavioral and structural con-
structs. The behavioral style imposed by Chinook enables the expression of real-time reactive
behavior as well as facilitating partitioning. The structural component merely lists the proces-
sors, peripheral devices, and communication interfaces that will be used. That is, the principal
components of the system to which the designer would like to evaluate a mapping of the desired
functionality. Chinook expects the designer to tag tasks and/or modules with the processor that is
preferred for their implementation. The implementation of untagged modules/tasks is assumed to
be in hardware. This separation of functionality from components allows the designer to quickly
explore the design space by instantiating different processors and alternative peripheral devices
without modifying the behavioral specification. All interactions with the devices and interfaces are
specified using a procedural abstraction layer. As long as two interfaces (e.g., SCSI and PCMCIA)
support the same access routines (e.g, read and write) they can be easily interchanged.
To model the reactive behavior of control-dominated applications, we organize the control
states of the system as a set of modes. Each mode defines a behavioral regime, that is, how the
system should respond to its inputs. A mode also defines a scope for a set of timing constraints
that must be satisfied while the system is within that mode but not necessarily when it is operating
outside of it. Modes are similar to the hierarchical states of [14] in that they can capture both
sequential and concurrent behavior.
Chinook allows the specification of real-time requirements in terms of minimum and maximum
separation between I/O events, namely events between system components or between the system
and the environment. At the low level, the constraints may correspond to setup and hold times, or
simply the sequencing constraints between successive I/Os. At the high level, min/max separation
can also be used to express response times to system inputs and rate constraints on performance
[8].
In a given mode, the system's responses are defined by a set of handlers. Conceptually, they
are event-triggered routines, but their activation conditions are checked by a time-triggered loop.
Handlers respond by generating I/O events and/or causing a mode transition. A handler consists
of a trigger condition and a body. The trigger condition is an event expression consisting of inputs
from the environment and other handlers. When the trigger condition evaluates to true, the handler
body is executed. For example, a network interface chip may signal that a message is pending and
this triggers a handler to read that message. Note that the handler body can be in software,
hardware, or a combination of the two, depending on its tag and the ability of the processor to
meet the timing constraints in the handler. From a specification point of view, a handler is executed
atomically, but may be interleaved by the scheduler.
Scheduling
Embedded systems have timing constraints at different levels. Their interaction with the devices
and the environment must respect not only low-level signaling constraints but also performance
requirements such as rate and response time constraints. To satisfy these high-level constraints,
designers have used process-based scheduling techniques based on operating systems concepts [17, 3].
These techniques are coarse-grained, priority-driven, and dynamically preemptive. They assume
that the processor does not perform I/O directly and the processes are independent of each other.
Since all timing constraints are coarse-grained, overhead incurred by the executive during pre-emption
can be dismissed. However, many embedded systems must perform direct I/O and meet
fine-grained timing constraints. These constraints are much more difficult to meet because the
scheduler cannot afford to incur much, if any, run-time overhead, and at the same time must handle
uncertainties in the execution delays. Instead, Chinook statically schedules all low-level I/O
and high-level operations as grouped in modes. A customized dynamic scheduler may be generated
for the larger modes (i.e., those at the top of the mode hierarchy).
Chinook uses a static, nonpreemptive scheduling algorithm to meet min/max timing constraints
on fine-grained operations with delay ranges [6]. It determines a serial ordering for the
operations, and inserts delays to meet minimum constraints, if necessary. Because the complexity
of the problem is NP-hard, we employ heuristic ordering functions to help the exact algorithm
quickly find a valid and short schedule. Experimental results show that our best heuristic consistently
outperforms a heuristic that solves the same problem inexactly [13].
At the high level, rate constraints are specified on a reference event between successive itera-
tions, and response times are constraints on the time it takes to do a mode transition. In statically
scheduling the software, Chinook first converts handlers within a mode into a single handler containing
their bodies, possibly using unrolling, and then schedules this single partially-ordered handler
by interleaving [8]. Note that a mode transition may be triggered by one of the handlers before other
handlers run to completion, and the scheduler must maintain the integrity of all handler states. We
do not use critical regions to achieve atomic execution because they disable interleaving, which is
necessary when servicing devices with long separation between sequential events. Instead, Chinook
allows the user to define safe points in the handlers, where potential mode transitions can safely
occur [5]. All parallel handlers must reach their safe points before a mode transition is allowed to
take effect.
6 Interface Synthesis
Interface synthesis is the realization of communication between components via both hardware and
software elements. Chinook handles a wide range of interface synthesis problems. At the lowest
level, Chinook synthesizes device drivers directly from timing diagrams. It generates customized
code for the particular processor being used, and separates out the portions that cannot be implemented
in software by synthesizing the required external hardware. For processors with general
purpose I/O ports, Chinook employs an efficient heuristic for connecting devices and processors
using minimal interface hardware. For processors without I/O ports, Chinook automatically implements
the interface using memory-mapped I/O including allocating address spaces and generating
the required bus logic and instructions.
These synthesis solutions require knowledge about the interfaces of the processors and the
devices, which are captured in the libraries. A processor is defined by its I/O resources, built-in
functionality (e.g., serial-line controller, timer, etc.), and detailed architecture templates (e.g.,
down to the specific resistors and capacitors required for power-up reset). A device description
contains interface information including ports and skeletal access routines that encapsulate timing
diagrams. After successful interface synthesis, Chinook updates the access routines by binding the
device ports to the processor's I/O ports or memory bus, and taking into account any intervening
glue logic that it may have synthesized. By managing these connectivity details and generating
the interface across the hardware/software boundary, the interface synthesizer completes the design
and enables simulation and evaluation at the final implementation level.
6.1 Driver Synthesis from Timing Diagrams
At the most detailed level, device interfaces are described in data sheets in the form of timing
diagrams. They show the sequences of signaling events that make up I/O transactions across
the interface. These timing diagrams are usually annotated with timing requirements, timing
delays, and timing guarantees. The first of these three are requirements imposed on the user of
the interface, while the second two are timing promises made by the device as long as the user
conforms to the requirements. When new devices are added to the device library, these constraints
and their corresponding timing diagrams are entered via a waveform editor [11]. Chinook parses
these waveforms and synthesizes the device driver code by choosing a linear schedule of controller
events, and inserting additional interface glue logic where necessary [22].
6.2 I/O Port Allocation
Many processors used in embedded systems include I/O ports that can be used to directly sense and
manipulate the processor's environment. These ports can be accessed from software like registers
thus providing a low-cost and straightforward interfacing mechanism. Chinook provides a port
allocation scheme that uses the minimal amount of glue logic. Furthermore, device access routines
are customized to reflect the assignments of pins [7]. The key idea is that an I/O port may be able to
service multiple devices without glue logic and without performance penalties. These devices have
interfaces that are able to isolate themselves from the shared bus, and become active only when the
appropriate control signals, or guards, enable them. Thus, a guarded interface of a device can share
the same I/O port with other devices because their interfaces cannot be active at the same time.
If necessary, the port allocator inserts glue logic to add guards to previously unguarded interfaces,
so that they can share busses. Chinook can also synthesize ports to create a new interfacing point
for additional devices. Hardware is synthesized to create a new port on the processor's memory
bus. This module decodes addresses and translates them into control signals to read and write the
new I/O pins.
6.3 Memory-Mapped I/O
When I/O ports are too inefficient (due to multiple instructions to manipulate their values or too
much additional hardware) or are unavailable (as is the case for higher-performance processors),
Chinook synthesizes the interface using memory-mapped I/O. First, many parts, processors as
well as peripheral devices, are designed with memory-mapped I/O in mind. They contain built-in
address matching logic and can be connected to the memory bus with little or no glue logic.
Second, many components without built-in address comparators can still be connected with little
or no glue logic, depending on the available address space the user reserves for I/O. Devices are
allocated portions of the address space of the processor controlling them. If the allocation is done
intelligently (i.e., using one-hot, binary, or Huffman encodings when possible) the amount of address
matching logic required can be minimized.
Memory-mapped I/O is also a preferred method of interprocessor communication and can be
used to support both point-to-point and shared memory schemes. If we are to allow a designer to
explore mapping of functions to multiple processors, then the mapping tools must automatically
synthesize the interprocessor communication hardware and software. Essentially, the view from one
processor is that the other processors are just more peripheral devices requiring their own device
drivers.
7 Communication Synthesis
Requirements for faster response times and increased modularity frequently guide embedded system
designers to employ multiple processors. These processors are often heterogeneous as cost and
modularity concerns drive designers to tailor processors to specific functions. CAD support is non-existent
for these types of systems. There are not even debuggers to support concurrent development
of programs on two identical processors. Designers find heterogeneous multiple processor systems
the most difficult to debug and thus constrain designs unnecessarily just to make debugging tasks
tractable.
Chinook provides support for interprocessor communication by synthesizing the hardware and
software needed to transfer data between processors. A designer tags the procedures and modules
with the processor that should be used to implement them. Chinook then determines the data that
must be transferred and the mechanism to use for those transfers including the interconnections
between the processors, glue logic, and/or buffers and memory.
In meeting timing constraints, Chinook will adjust the interface between the software running
on the processors. Consider the case of a fast processor communicating with a slow one. Handshaking
with the slow processor may cause the fast one to violate its constraints. Buffers can reduce
the load on the fast processor by eliminating direct handshaking. The communication becomes
non-blocking and data may be processed in bursts.
7.1 Interprocessor Communication Synthesis
When considering communication in multiple processor systems, many new issues arise including
predictability, interconnect topology, access to peripheral devices, and communication protocols.
The interconnect topology could be bus-based, point-to-point, or a hybrid scheme. A peripheral
device may only be accessible via a designated processor or many processors may have shared
access. The communication protocol may be contention based or statically scheduled, blocking or
non-blocking, and master-slave or peers. Each choice has impacts on performance, predictability,
and the complexity of scheduling and hardware required. Chinook supports most of these choices,
but by default uses a model suitable for real-time control-dominated applications. It is based on
non-blocking communication among peers with designated peripheral processors. The interconnect
may be either point-to-point or bus-based.
A handler communicates with the environment through device driver calls and with other
handlers via messages. A message is an event that triggers another handler with an optional data
value. Intraprocessor messages are implemented with shared variables. Interprocessor messages
are transmitted via communication channels synthesized with elements from a communication
library that contains buffers, FIFOs, arbiters, and interconnect templates. Given a partitioning of
handlers provided by the user, Chinook will synthesize communication channels to satisfy timing
and resource constraints. Once the communication components are chosen, they are connected
to the respective processors using the interfacing techniques in section 6. If there are multiple
communication channels between processors, each channel may be mapped to its own physical
connection or they may share connections.
7.2 Migration between Processors
Keeping in mind Chinook's focus on aiding the designer's exploration of the design space, it is
important that the designer be free to easily allocate functionality to different processors. Through
assignment tags in the high-level specification, a designer can rapidly change the partitioning of
functionality - between two processors, or between a processor and a direct hardware implementa-
tion. Because Chinook synthesizes interprocessor communication channels and optimizes their use,
this task is greatly simplified for the designer. No longer does the designer need to radically alter
code running on one processor and then propagate the changes to the others while keeping track of
all the potential implications on timing requirements and resource access. These adjustments are
made automatically by Chinook.
Migrating functionality is divided into three parts: input parameter sending, control sequenc-
ing, and output parameter receiving. Input and output parameters are mapped to latches or
memory locations which are connected to the processor using the interfacing techniques discussed
earlier. The control sequencing may simply be moved to another processor or be moved to hardware
where it will be instantiated as a finite-state-machine and data-path. The general solution to this
requires behavioral synthesis but is quite straightforward in most cases involving I/O. The original
software is replaced with routines that pass the inputs, kick-start the hardware or the software
handler on the other processor, and then read back the outputs.
8 Simulation
The design can be simulated at different levels of detail. The initial specification is compatible
with behavioral Verilog and is simulated without exact timing or detailed I/O. As the synthesis
steps refine abstract communications and operations into more concrete signals and components,
outputs from intermediate design steps and the final implementation can also be simulated with
cycle-level accuracy.
The simulator uses the Verilog-XL Programming Language Interface [2] to communicate with
peripheral device models. The device models are written in C and make X-window calls to visually
from p2.6
from P2.0
ALE
P2/
P0/
SPEAKER/
RxD
from p2.1
(a)
Network
Processor
I/O Devices
I/O
driver
net driver
mem
driver
proc driver
I/O
handler proc handler
net handler
MAGIC
(b)

Figure

2: Examples synthesized in Chinook. (a) Portable Electronic Phonebook. (b) Communication
in the MAGIC system.
represent the simulated device. Each device model exports the same API (application program
for simulation and synthesis. To simulate the specification during the early stages of the
design, the API is bound to a behavioral simulation model. For example, a SCSI device exports
a send routine. During simulation, the user may pop-up a window containing the various fields
of a SCSI packet. After creating a new packet, the designer selects the send option which calls
the send routine. This enables the user to simulate the environment of the system being designed
in a consistent manner. During structural simulation of the system, the device's pin interface is
modeled by running multiple FSMs to recognize all possible I/O sequencings in parallel. The FSM
that matches the given I/O invokes the corresponding behavioral routine to simulate the device's
reaction to the given waveform.
Chinook uses RTL-level processor models for simulating the final system implementation. The
processor model, also written in C, interprets the same machine code that runs on the actual
processor. At this stage, it is possible to execute the software with a debugger (although this
is the synthesized code and not the original Verilog source). The binary code is disassembled
and the registers, program counter, stack, internal memory, and built-in devices are visible in the
processor status window. The processor model faithfully reproduces, within cycle-level accuracy,
the appropriate waveforms on the processor's pins.
9 Examples
Several embedded systems have been designed using the Chinook tools. The following examples
show the type of complexity that the current version supports. They are a portable electronic
phonebook, a node controller for a distributed system, and a mobile defibrillator.
9.1 Portable Electronic Phonebook
The Portable Electronic Phonebook was originally designed by senior undergraduate students.
Taking their implementation, we reverse-engineered a high level specification which was run through
the Chinook tools (see Figure 2a). The generated solution required less hardware than the original
implementation due to the interface synthesis algorithm. We were able to simulate the entire system
at the behavioral and structural levels to validate the design. After building this application in
hardware according to the generated netlist, the system operated correctly upon applying power.
9.2 MAGIC
The MAGIC (Memory and General Interconnect Controller) is a custom node controller for the
FLASH architecture [16]. It communicates with a processor, network, I/O devices and DRAM (see
Figure 2b). We modeled this architecture with three handlers, one for the processor requests, one
for the network requests and one for the I/O requests. Since the DRAM does not initiate activity, it
does not require its own handler. All communication with the DRAM occurs via device driver calls.
We used the MAGIC application to experiment with using a common API for different peripherals.
The specification was written so that it is easy to select a SCSI or Ethernet network interface chip.
This demonstrates that designers can easily explore different high level options and observe their
ramifications on other parts of the system. Now that we have both SCSI and Ethernet chips and
drivers in the device library, it is straightforward to implement other systems that require these
protocol chips. Using the results synthesized by Chinook, we performed our experiments with the
simulator.
9.3 A Mobile Defibrillator
The purpose of the mobile defibrillator is to revive heart-attack victims with a powerful electrical
shock. We consider the digital control subsystem containing an extensive interface including
display of ECG waveforms, voice synthesis, digital audio recording, and PC-Card non-volatile stor-
age. Because of the difficulty of guaranteeing that all timing constraints would be respected, the
commercial version of this application was designed with a microcontroller and an ASIC. We are
currently exploring solutions using reprogrammable components.
With the increasing availability of inexpensive and powerful microprocessors and FPGAs, designers
of embedded systems are faced with more implementation choices than ever and given less time
to realize their designs. Unfortunately, computer aided design tools are not tracking these trends.
The Chinook co-synthesis system facilitates design space exploration and automates many aspects
of system integration. These are often the most time-consuming and error-prone tasks in the
embedded system design process.
Design space exploration is enabled by the use a single system specification that captures
the reactive real-time behavior of the system and appropriately abstracts interactions with the
environment to enhance retargetability. Since timing requirements are critical for many embedded
applications, Chinook uses static scheduling to guarantee their satisfaction by construction. Several
interface synthesis techniques are employed to interconnect system components. The necessary
interface hardware and software is generated automatically and minimal glue logic is introduced.
At a higher level, Chinook facilitates easy migration of functionality among processing elements and
manages the communication requirements between processors. This enables designers to rapidly
evaluate different architectural templates and partitionings. Simulation is supported throughout the
design cycle from the initial behavioral specification through the final structural implementation.
Chinook's output consists of a netlist, logic specification, and code for each processor - all the
elements needed for the construction of the complete system.
We have used to Chinook to synthesize several embedded systems including an electronic
phonebook, SCSI interface to a VLSI chip tester, hand-held logic analyzer, and an infrared net-work
transceiver. We are currently experimenting with its use in evaluating the design spaces for
an automatic defibrillator and a multi-processor I/O subsystem. Future work includes developing
synthesis methods for more efficient communication using higher level knowledge about the
dataflow and control dependencies of the handlers. For instance, routing data around a processor
may reduce processor load and yield higher performance at the cost of additional hardware.
Ongoing work includes making Chinook more robust and more integrated, especially between the
scheduler and compiler/estimator. In addition, we are investigating techniques to permit partitioning
between software running on a workstation/PC and functionality in a peripheral device, which
is an embedded system on a board attached to the system bus or other standard interface such as
serial-line or PCMCIA slot.



--R

The Esterel language.
CADENCE Design Systems
All things considered.

Software scheduling in the co-synthesis of reactive real-time systems
Interval scheduling: Fine-grained software scheduling for embedded systems
Synthesis of the hardware/software interface in microcontroller-based systems
Scheduling for reactive real-time systems

Specification and design of embedded hardware-software systems
Specification of timing in a digital system.

Constrained software generation for hardware-software systems
StateCharts: a visual formalism for complex systems.
Communicating Sequential Processes.
The Stanford FLASH multiprocessor.
The design of real-time programming systems based on process models
Petri nets: Properties
Predicting Deterministic Execution Times of Real-Time Programs
System level hardware module generation.
The Verilog Hardware Description Language.
Interface timing verification with application to synthesis.
--TR
Communicating sequential processes
Statecharts: A visual formalism for complex systems
Predicting deterministic execution times of real-time programs
The Stanford FLASH multiprocessor
Software scheduling in the co-synthesis of reactive real-time systems
Interface timing verification with application to synthesis
System level hardware module generation
Interval scheduling
Interface co-synthesis techniques for embedded systems
The Verilog hardware description language (4th ed.)
Synthesis fo the hardware/software interface in microcontroller-based systems
Hardware-Software Cosynthesis for Digital Systems
Hardware-Software Cosynthesis for Microcontrollers
Specification and Design of Embedded Hardware-Software Systems
Hardware-Software Codesign of Embedded Systems
Scheduling for Reactive Real-Time Systems
Constrained software generation for hardware-software systems

--CTR
Michael Gasteier , Manfred Glesner, Bus-based communication synthesis on system level, ACM Transactions on Design Automation of Electronic Systems (TODAES), v.4 n.1, p.1-11, Jan. 1999
Petru Eles , Zebo Peng1 , Krzysztof Kuchcinski , Alexa Doboli, Hardware/Software Partitioning with Iterative Improvement Heuristics, Proceedings of the 9th international symposium on System synthesis, p.71, November 06-08, 1996
Paul Pop , Petru Eles , Zebo Peng, Bus access optimization for distributed embedded systems based on schedulability analysis, Proceedings of the conference on Design, automation and test in Europe, p.567-575, March 27-30, 2000, Paris, France
R. Niemann , P. Marwedel, Synthesis of communicating controllers for concurrent hardware/software systems, Proceedings of the conference on Design, automation and test in Europe, p.912-913, February 23-26, 1998, Le Palais des Congrs de Paris, France
Verkest , Julio Leao Da Silva Jr. , Chantal Ykman , Kris Croes , Miguel Miranda , Sven Wuytack , Francky Catthoor , Gjalt De Jong , Hugo De Man, Matisse: A System-on-Chip Design Methodology Emphasizing Dynamic Memory Management, Journal of VLSI Signal Processing Systems, v.21 n.3, p.185-194, July 1999
Thomas Benner , Rolf Ernst, An Approach to Mixed Systems Co-Synthesis, Proceedings of the 5th International Workshop on Hardware/Software Co-Design, p.9, March 24-26, 1997
Pai Chou , Ross B. Ortega , Gaetano Borriello, Interface co-synthesis techniques for embedded systems, Proceedings of the 1995 IEEE/ACM international conference on Computer-aided design, p.280-287, November 05-09, 1995, San Jose, California, United States
Osamu Ogawa , Sylvain Bayon de Noyer , Pascal Chauvet , Katsuya Shinohara , Yoshiharu Watanabe , Hiroshi Niizuma , Takayuki Sasaki , Yuji Takai, A Practical Approach for Bus Architecture Optimization at Transaction Level, Proceedings of the conference on Design, Automation and Test in Europe: Designers' Forum, p.20176, March 03-07,
Pai Chou , Ross B. Ortega , Gaetano Borriello, Interface co-synthesis techniques for embedded systems, Readings in hardware/software co-design, Kluwer Academic Publishers, Norwell, MA, 2001
K. Van Rompaey , I. Bolsens , H. De Man , D. Verkest, CoWarea design environment for heterogenous hardware/software systems, Proceedings of the conference on European design automation, p.252-257, September 1996, Geneva, Switzerland
Steven Vercauteren , Bill Lin , Hugo De Man, A strategy for real-time kernel support in application-specific HW/SW embedded architectures, Proceedings of the 33rd annual conference on Design automation, p.678-683, June 03-07, 1996, Las Vegas, Nevada, United States
Koen Danckaert , Francky Catthoor , Hugo de Man, System level memory optimization for hardware-software co-design, Proceedings of the 5th International Workshop on Hardware/Software Co-Design, p.55, March 24-26, 1997
Bill Lin , Steven Vercauteren , Hugo de Man Imec, Embedded Architecture Co-Synthesis and System Integration, Proceedings of the 4th International Workshop on Hardware/Software Co-Design, p.2, March 18-20, 1996
Vincenza Carchiolo , Michele Malgeri , Giuseppe Mangioni, Approach to the Synthesis of HW and SW in Codesign, Proceedings of the 5th International Workshop on Hardware/Software Co-Design, p.173, March 24-26, 1997
Koen Danckaert , Francky Catthoor , Hugo De Man, System level memory optimization for hardware-software co-design, Readings in hardware/software co-design, Kluwer Academic Publishers, Norwell, MA, 2001
Robert P. Dick , Niraj K. Jha, MOCSYN: multiobjective core-based single-chip system synthesis, Proceedings of the conference on Design, automation and test in Europe, p.55-es, January 1999, Munich, Germany
Steven Vercauteren , Bill Lin , Hugo De Man, Constructing application-specific heterogeneous embedded architectures from custom HW/SW applications, Proceedings of the 33rd annual conference on Design automation, p.521-526, June 03-07, 1996, Las Vegas, Nevada, United States
Joerg Henkel , Rolf Ernst, The Interplay of Run-Time Estimation and Granularity in HW/SW Partitioning, Proceedings of the 4th International Workshop on Hardware/Software Co-Design, p.52, March 18-20, 1996
An algorithm for synthesis of large time-constrained heterogeneous adaptive systems, ACM Transactions on Design Automation of Electronic Systems (TODAES), v.6 n.2, p.207-225, April 2001
A. Baghdadi , D. Lyonnard , N. Zergainoh , A. Jerraya, An efficient architecture model for systematic design of application-specific multiprocessor SoC, Proceedings of the conference on Design, automation and test in Europe, p.55-63, March 2001, Munich, Germany
Steven Vercauteren , Jan Van Der Steen , Diederik Berkest, Combining software synthesis and hardware/software interface generation to meet hard real-time constraints, Proceedings of the conference on Design, automation and test in Europe, p.112-es, January 1999, Munich, Germany
Jean-Marc Daveau , Gilberto Fernandes Marchioro , Tarek Ben-Ismail , Ahmed Amine Jerraya, Protocol selection and interface generation for HW-SW codesign, Readings in hardware/software co-design, Kluwer Academic Publishers, Norwell, MA, 2001
Kanishka Lahiri , Anand Raghunathan , Sujit Dey, Efficient exploration of the SoC communication architecture design space, Proceedings of the 2000 IEEE/ACM international conference on Computer-aided design, November 05-09, 2000, San Jose, California
Kanishka Lahiri , Anand Raghunathan , Ganesh Lakshminarayana , Sujit Dey, Communication architecture tuners: a methodology for the design of high-performance communication architectures for systems-on-chips, Proceedings of the 37th conference on Design automation, p.513-518, June 05-09, 2000, Los Angeles, California, United States
Paul Lieverse , Pieter Van Der Wolf , Kees Vissers , Ed Deprettere, A Methodology for Architecture Exploration of Heterogeneous Signal Processing Systems, Journal of VLSI Signal Processing Systems, v.29 n.3, p.197-207, November 2001
L. Freund , M. Israel , F. Rousseau , J. M. Berg , M. Auguin , C. Belleudy , G. Gogniat, A codesign experiment in acoustic echo cancellation: GMDF&agr;, ACM Transactions on Design Automation of Electronic Systems (TODAES), v.2 n.4, p.365-383, Oct. 1997
M. Abid , A. Changuel , A. Jerraya, Exploration of hardware/software design space through a codesign of robot arm controller, Proceedings of the conference on European design automation, p.42-47, September 1996, Geneva, Switzerland
Jason Cong , Yiping Fan , Guoling Han , Wei Jiang , Zhiru Zhang, Behavior and communication co-optimization for systems with sequential communication media, Proceedings of the 43rd annual conference on Design automation, July 24-28, 2006, San Francisco, CA, USA
A. Baganne , J. L. Philippe , E. Martin, A Co-Design Methodology for Telecommunication Systems: A Case Study of an Acoustic Echo Canceller, Journal of VLSI Signal Processing Systems, v.22 n.1, p.21-29, Aug. 1999
Pao-Ann Hsiung, Timing coverification of concurrent embedded real-time systems, Proceedings of the seventh international workshop on Hardware/software codesign, p.110-114, March 1999, Rome, Italy
Ansgar Bredenfeld, Co-design tool construction using APICES, Proceedings of the seventh international workshop on Hardware/software codesign, p.126-130, March 1999, Rome, Italy
Vincent Mooney , Toshiyuki Sakamoto , Giovanni De Micheli, Run-Time Scheduler Synthesis for Hardware-Software Systems and Application to Robot Control Design (Abstract), Proceedings of the 5th International Workshop on Hardware/Software Co-Design, p.95, March 24-26, 1997
Felice Balarin , Massimiliano Chiodo , Attila Jurecska , Luciano Lavagno , Bassam Tabbara , Alberto Sangiovanni-Vincentelli, Automatic Generation of a Real-Time Operating System for Embedded Systems, Proceedings of the 5th International Workshop on Hardware/Software Co-Design, p.95.5, March 24-26, 1997
Octvio P. Dias , Isabel C. Teixeira , J. Paulo Teixeira, Metrics and Criteria for Quality Assessment of Testable Hw/Sw Systems Architectures, Journal of Electronic Testing: Theory and Applications, v.14 n.1-2, p.149-158, Feb./April 1999
M. Abid , T. Ben Ismail , A. Changuel , C. A. Valderrama , M. Romdhani , G. F. Marchioro , J. M. Daveau , A. A. Jerraya, Hardware/Software Co-Design Methodology for Design of Embedded Systems, Integrated Computer-Aided Engineering, v.5 n.1, p.69-84, January 1998
Jay K. Adams , Donald E. Thomas, The design of mixed hardware/software systems, Proceedings of the 33rd annual conference on Design automation, p.515-520, June 03-07, 1996, Las Vegas, Nevada, United States
Vincent J.  Mooney Iii, Path-Based Edge Activation for Dynamic Run-Time Scheduling, Proceedings of the 12th international symposium on System synthesis, p.30, November 01-04, 1999
Vincent J. Mooney, III , Giovanni De Micheli, Real time analysis and priority scheduler generation for hardware-software systems with a synthesized run-time system, Proceedings of the 1997 IEEE/ACM international conference on Computer-aided design, p.605-612, November 09-13, 1997, San Jose, California, United States
Vincenza Carchiolo , Michele Malgeri , Guiseppe Mangioni, Hardware/software synthesis of formal specifications in codesign of embedded systems, ACM Transactions on Design Automation of Electronic Systems (TODAES), v.5 n.3, p.399-432, July 2000
Gabriela Nicolescu , Sungjoo Yoo , Aimen Bouchhima , Ahmed Amine Jerraya, Validation in a component-based design flow for multicore SoCs, Proceedings of the 15th international symposium on System Synthesis, October 02-04, 2002, Kyoto, Japan
Dirk Ziegenbein , Kai Richter , Rolf Ernst , Lothar Thiele , Jrgen Teich, SPI: a system model for heterogeneously specified embedded systems, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, v.10 n.4, p.379-389, August 2002
Jrg Henkel , Rolf Ernst, A hardware/software partitioner using a dynamically determined granularity, Proceedings of the 34th annual conference on Design automation, p.691-696, June 09-13, 1997, Anaheim, California, United States
R. Marculescu , A. Nandi, Probabilistic application modeling for system-level perfromance analysis, Proceedings of the conference on Design, automation and test in Europe, p.572-579, March 2001, Munich, Germany
Giovanni De Micheli , Rajesh K. Gupta, Hardware/software co-design, Readings in hardware/software co-design, Kluwer Academic Publishers, Norwell, MA, 2001
custom logic;software tools;microprocessors;logic CAD;error-prone tasks;real-time systems;computer-aided design tools;interface software;system components integration;chinook hardware/software co-synthesis system;interface hardware;microcontrollers;function migration;embedded controller design;logic design;design co-simulation;design time constraints