Communication/Component-Based Design

(Theme Leader: Alberto SV)

Roberto Passerone (UC Berkeley)

Radu Marculescu (CMU)

GSRC Symposium & Workshop

June 9-10, 2002

DUSD(Labs)
 Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
ΠAnalysis (Radu Marculescu)
ΠCommunication Synthesis (Radu Marculescu)
Motivation:
Distributed Applications
The PicoRadio Networking Playground
actuator Properties:
sensor • system consisting of sensors
(sources), monitors (controllers),
and actuators (sinks)

Assumptions:
monitor • no or minimal infrastructure
• range of any node << network size
• any node can act as repeater

Optimization Goals:
• Global energy
• System survivability
• nodes can go down
node range temporarily lacking energy
• delivery of information to be
ensured
Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
Platforms
‹ Texas Instruments OMAP, Philips nExperia, Infineon MGold
‹ Concentrates on full application
ΠDelivers comprehensive set of libraries hardware and software
ΠDelivers several mapping and application examples
‹ Hardware Platform
ΠA coordinated family of architectures that satisfy a set of
architectural constraints imposed to support re-use of hardware
and software components

Texas Instruments
OMAP
Beyond Hardware Platforms
Platforms Examples

Cisco: ONS 15800 DWDM Platform

Service Ericsson: Internet Services platform

Nokia: Mobile Internet Architecture

Application Intel: Personal Internet Client Architecture
Sony: Playstation 2

System
TI: OMAP
SW Philips: Nexperia
HW ARM: PrimeXSys

Implementation
Fabrics
Xilinx: Virtex II
Manufacturing eASIC: eUnit
ASV Platforms

In general, a platform is an abstraction layer that covers a

number of possible refinements into a lower level.

Platform stack { Platform

Mapping Tools

Platform
ASV Platforms
The design process is meet-in-
the-middle:
•Top-down: map an instance of
the top platform into an instance Upper layer of abstraction
of the lower platform and
propagate constraints Constraints Performance Annotation
•Bottom-up: build a platform by
defining the “library” that Lower layer of abstraction
characterizes it and a
performance abstraction (e.g.,
number of literals for tech. For
Forevery
everyplatform,
platform,there
thereisisaaview
viewthat
thatisis
Independent optimization, area used
usedtotomap
mapthetheupper
upperlayers
layersof ofabstraction
abstraction
and propagation delay for a cell into
intothe
theplatform
platformand
andaaview
viewthat
thatisisused
usedto to
in a standard cell library) define
definethe
theclass
classofoflower
lowerlevel
levelabstractions
abstractions
implied
impliedby
bythe
theplatform.
platform.
The library has elements and
interconnects
Platform-Based Implementation
‹ Platforms eliminate large loop iterations for affordable design

‹ Restrict design space via new forms of regularity and structure that surrender
some design potential for lower cost and first-pass success
‹ The number and location of intermediate platforms is the essence of platform-
based design
Application Space
Application Instance Application

Platform
Specification

System
Platform
Platform
Design-Space
Exploration

Platform Instance
Silicon Implementation
Architectural Space
Design Methodology: Orthogonalize Concerns
Software Components Virtual Architectural Components
IPs
C-Code Buses
CPUs Buses
Buses Operating
Matlab ASCET Systems

Analysis
System Behavior System Platform
Development Process

Specification f1 f2 ECU-
ECU-1 ECU-
ECU-2
Bus
f3 ECU-
ECU-3

Mapping Evaluation of
Implementation
Architectural
Performance and
Simulation Partitioning
Calibration Alternatives
Refinement
After Sales Service
UML-Platform: Notation and Methodology for PBD
‹ Overview: – a projection of platforms into the UML notation space
‹ Results: – a new UML profile for platform-based design (PBD)
– a methodology for representation of platform layers,
relations, QoS, constraints, extension points, etc.
‹ Directions: – a front-end language for Metropolis
– a full-fledged design methodology based on Metropolis

• Identify platform layers • Build stereotypes and hierarchy

ASP application domain-specific <<use/need>>
services (functions, user interfaces)

API network device

RTOS communication
subsystem driver
<<stack>> <<peer>>

µP and inter-
ARC
memory connection HW I/O <<transparent stack>> <<opaque stack>>
Model and Design of Network Platforms
z Formalization of Network Platforms
z APIs: sets of Communication Services

z Application: Design of Picoradio networks

z Communication Refinement

Application Layer

CS: Pull Push

Max Power, BER

Network Layer

CS: Multi-hop Request delivery, multi-hop Response delivery

Analog Platforms
z System Specs

Exploration
‹ Analog Platforms are parametrized z Behavioral models

System
Level
architectural components z Performance models
‹ Analog Platforms along with
Analog IP
hierarchies of behavioral models

synthesis
z Circuit design
define an Analog IP

sizing &
Circuit
– Size, Simulate and iterate
z Layout design
– Verify and iterate with both prior levels
‹ Roles of the Analog IP
ΠSeparate System Level Design from Circuit Design
ΠHide all implementation details, only export performances
‹ The goal of Analog IPs is to support optimizations at the system level
ΠDefine optimal specs for individual blocks, thus selecting particular instances of the
Analog Platforms
Communication-Network Centric U1 P1 P2 U2

‹ Ulysses: Protocol Synthesis from Scenario- read a write b

based Specifications
ΠAvoid early partitioning into components
ΠSpecify scenarios independently
ΠCompose scenarios
‹ Interface Synthesis
ΠSynthesis of converters from property
specification
ΠBlend of synthesis and verification techniques 0- 1a 0b

(with T. Henzinger and L. de Alfaro)

0- 1a 0- 0b
0-
‹ Directions
0- 0-
1a 1a 1a 1a 1a 0b
0-
1a1a 1a 0b
ΠGeneralization of synthesis techniques to 1a
1a 0-
0b 0b 1a 0b 0b
0b
arbitrary abstraction layer 0-
0b 1a 0b 0b
0b
0b 0-
Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
Metropolis
etropolis

Communication Spec Architecture

Functional Spec Constraints

Meta
Meta Model
model

Meta model
Front end
compiler

Abstract syntax tree

Back end1 Back end2 Back end3 ... Back endN

Verification
Simulator Synthesis
Analysis
tool tool
tool Metro Shell
Command Interpreter
Metropolis: meta model
‹ Must describe objects at different levels of abstraction
ΠDo not commit to the semantics of a particular Model of Computation
‹ Define a set of “building blocks”:
Πspecifications with many useful MoCs can be described using the building blocks
ΠProcesses, communication media and schedulers separate computation,
communication and coordination
‹ Represent behavior at all design phases - mapped or unmapped

Computation
P1 P2
M
pX pZ pX pZ

Communication M’ M’

S
Coordination
P1.pZ.write() ‹ P2.pX.read()
Emphasis
p0
m0 c0
p1
‹ Refinement
p2
ΠFunctional refinement p3
m1 c1

ΠCommunication refinement
refm0
w0
‹ Constraints w1
r0

ΠQuantities, Temporal logic, Schedulers mb

w0
‹ Architecture definition w1
r0
refm1

CPU ASIC1 ASIC2 SYSTEM:

Sw1 Sw2 Hw
Hardware - SW modules, HW
module
- bounded FIFO, lossy channels
C-Ctl Channel Ctl C-Ctl - no address, bus independent
Sw I/F Channel I/F

CPU-IOs Wrappers
TRANSACTION:
Bus I/F B-I/F
- address, data split in chunk
- no detailed bus protocol or width

RTOS
e.g. PIBus 32b PHYSICAL:
e.g. OtherBus 64b... - specific bus protocol
- detailed RTOS characterization
Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
Simulating the MetaModel in the Metropolis
Framework
‹ Multi-threaded (single or multi-processor) simulation code
ΠJavaTM, SystemC, C++
‹ Extension to performance simulation
ΠArchitecture: netlist of blocks that provide services
ΠQuantities: manage performance metrics (time, power, area, etc.)
ΠMapping: annotation of functional processes using quantities and architecture services
‹ Simulator Performance
ΠConstructed and profiled various models in SystemC and Metropolis
ΠIdentified bottlenecks and implemented changes to match the performance of System C
and Metropolis model simulators
Metropolis benefits come at no extra simulation cost
‹ Directions:
ΠTechniques for Interactive & batch based simulation
ΠSimulation Coverage Enhancement [Ip, ICCAD 2000]
ΠHeuristics to guide the simulator for finding bugs [Dill, DAC 1998]
Formal Specification and Analysis:
Metropolis at UC-Riverside (H. Hsieh, et al)
1. Defining MOCs in MMM
Œ SDF, Dataflow PN, Synchronous FSM network, SystemC subset, …
2. Translating Ptolemy/CAL designs into MMM
ΠSDF, Dataflow PN
3. Formal verification of MMM designs using SPIN
ΠProperty verification, implementation verification
4. Conformance checking of MMM design using SPIN
ΠSimulation trace containment of implementation vs. spec
5. Verifying constraint formulae with simulation
ΠSimulation monitor for quantitative constraints
Communication
Processes Architecture
2 1
MMM
3 4 5
Synthesis Verification
Successive Refinement in Metropolis
‹ Verify properties of components : well-timedness, liveness
ΠProperties preserved by
 Composition of components (compositionality)
 Restriction by constraints (composability)
ΠIntegration of the incremental modeling tool Prometheus in Metropolis (work in
progress).
ΠCase study: TinyOS networking application.

‹ Directions
ΠProvide modeling guidelines for the meta-model to support incremental
modeling.
Œ Extend results to more “difficult” properties, e.g. schedulability of processes.
ΠEfficiently synthesize a refinement satisfying required, more specific
properties.
Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
Wheel control
unit
Force
Settin
gs
Wheel control
unit
Application Driven Scheduling
Scheduling for real-time feedback controllers
LAN Bus Wh
Braking central Desired eel
control unit Decelerati Spe

http://www-cad.eecs.berkeley.edu/~pinello
on ed

Driv
Wheel control er Wheel control
unit unit

DRAFTS: Distributed Real-time Applications RACS: Resource-Aware Control

Fault Tolerant Scheduling Synthesis

‹ Automatic (off-line) synthesis of fault ‹Optimal Synthesis of control gains

tolerant schedules for periodic algorithms and scheduling parameters
on a distributed architecture ‹Performance metric: stability
‹ Automatic (off-line) verification that all robustness
intended faults are covered ‹Constraints: execution capacity and
scheduling policy (e.g. EDF, RM)

Long-term goals:
‹ Design Methodology for Safety Critical Stabilizing gains
Distributed Systems Stability Center
‹ Manage the design complexity of modern Stability Radius
Drive-By-Wire applications
Software Synthesis: Quasi-Static Scheduling
‹ Sequentialize concurrent operations
ΠCan handle data-dependent control, multi-rate communication
ΠBetter starting point for code generation
‹ Philips MPEG2 decoder: Performance increased by 45%
Πreduction of communication (no internal FIFOs between statically scheduled processes)
Πreduction of run-time scheduling (OS)
Πno reduction in computation
‹ Future directions
ΠFalse path analysis, design partitioning, multiprocessor systems

QSS
Communication Driven HW Synthesis(CDHWSYNTH )
for High-Performance Microprocessor Design
‹ From ISA to micro-architecture ISA Architectural
ΠLeverage Communication Based Design Specification Library
ΠHigh Performance
ΠCorrect by Construction Design
Methodology:
ΠReusability and Flexibility Mappings,
‹ Case Study Specification of a MIPS 32 Refinements,
Transformations
ΠDeveloped a Trace-Driven Simulator for
Multiprocessor Cache Coherence in SystemC
ΠPreliminary results for
 Representing Speculation
 Modeling various levels of abstraction using Process
Networks and Synchronous Languages

‹ Directions
ΠExamples From Industry (Intel and Cypress)
ΠFurther exploration of modeling memory systems
Intel Pentium IV Die (source: Intel web site)
Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
Metropolis Semantics: Action Automata
‹ One for each action (statement, function call, expressions, etc.) of each
process
‹ Composed synchronously
‹ May update shared memory variables:
Πprocess and media member variables
Πvalues of actions-expressions
‹ Have guards that depend on states of other action automata and memory
variables

By=x+1 Bx+1 Ex+1 Ey=x+1

y=x+1 c c
Y := Vx+1
* * * * = write y
Bx+1 Ex+1 Ey=x+1
c c
Y := any
Bx+1 Ex+1
x+1 c
Vx+1 := x + 1
write x
Ey=x+1
c
Vx+1 := any
Algebraic Theory of Models
Pre-Post

Process Networks

Data Flow P1
M
P2
pX pZ pX pZ

M’ M’
S

Non-metric Time P1.pZ.write() ‹ P2.pX.read()

Discrete Time
Meta Model

Continuous Time

Trace Algebras
Conservative Approximations

‹Directions
ŒGeneralization to Agent Algebras

ŒGeneralization to sequential composition

 Outline
‹ Motivation

‹ Platform and Communication-based Design

ΠDefinition
ΠDesign Methodology
ΠNetwork Platforms
ΠAnalog Platforms

‹ The Metropolis Framework

ΠMetamodel
ΠVerification
ΠSynthesis
ΠTheory of Models
ΠAnalysis (Radu Marculescu)
ΠCommunication Synthesis (Radu Marculescu)
Where does the Analysis Module fit?

Design of Design of Design of

Function Processes Communication Media Architecture Components

Metropolis Infrastructure

Metropolis Point Tools: Metropolis Point Tools:

Synthesis/Refinement Verification

abstract mapping +
Analysis scheduling policy +
performance numbers adaptation mechanisms
The Big Picture
Informal
description

Possibly several
inputs here! λ)…| …(b,µ
P: (a,λ µ) System description
formal semantics

λ
a,λ µ
b,µ
λ
d,λ Semantic model
λ
a,λ

Our choice: SANs

performance evaluation

deadlock power … Results

temporal functional non-functional

A Multimedia Stream: Informal Description
Send frames Play frames

Data Data
Source channel Sink

‹Constraints on behavior -> QoS requirements

ΠThe data source repeatedly transmits data frames every 50ms (e.g. 20fps)
ΠAfter generation of a frame, 5ms elapse before it is transmitted
ΠCommunication is asynchronous and channel may have errors
ΠSuccessfully transmitted frames arrive at sink between 80ms and 90ms (latency)
ΠIf the number of frames arriving at the data sink is not within 15 to 20 fps (channel
throughput), then an error should be reported
ΠEnd-to-end latency should be between 100ms and 120 ms (this is the acceptable jitter
on latency). A frame taking longer than 120ms is assumed to be lost

‹Note
ΠMay change through system development (parameters that change should be easily
identifiable and easy to change) (mostly a research issue)
ΠSpecify and work w/ probabilities (mostly a research issue)
What is our Driver Application?

Baseline Unit
MPEG
Header IDCT
coded VLD Decoded
decoder IQ Recovery
video + Unit
video

Buffer

MC Unit
How do we Model the Application?
“Processes” and “medium” participate in communication!

…
void Fast_IDCT(block)
short *block;
{
int i;
for (i=0; i<8; i++)
idctrow(block+8*i);
for (i=0; i<8; i++)
idctcol(block+i);
This is Hard!
}
…

( α,r)
(C, Act, { →
 : (α,r ) ∈ T})
SOC
action rate ∈R+
We talk about MCs and steady-state analysis because
we assume exponentially distributed RVs (that is, F(t) = 1 - e–rt)!
How do we Build a SAN-based Semantic Model?
Four concurrent automata, five states each

625
λ
d,λ λ
a,λ µ
b,µ One iteration
λ
a,λ

625
How do we Model the Architecture?

Model of a CPU

Model of the memory

Putting Everything Together
This is a guarded transition

This is a shared resource!

… and Getting the Results: the Node-Centric
Perspective

buffer length 1.15

… and Getting the Results: the Node-Centric
Perspective

This comes from steady-state analysis

How about the Communication Channel?

∞ Buffer
Encoder Decoder Application level

Finite Buffer
HW Application
Encoder Tx Rx Decoder mapped to
Buffer-Tx Buffer-Rx scheduler Hardware
Ideal Channel

Communication Error
HW
Encoder Tx Error Rx Decoder
Buffer-Tx Model scheduler
Buffer-Rx
Real Channel

The ‘node’ behavior depends dramatically on channel behavior!

What are we Trying to Analyze?
Communication Error

B1 B2
Error
Tx Model Rx
Buffer-Tx Buffer-Rx
Real Channel
Again, the Network-Centric Perspective…
Communication Error

B1 B2
Error
Tx Model Rx
Buffer-Tx Buffer-Rx
Real Channel

0% 0%
15% 15%
30% 30%
50% 50%
1
0.6
0.8 0.5
0.6 0.4
50% 0.3 50%
0.4
30% 0.2 30%
0.2 15% 15%
0.1
0% 0%
0
0
36fps 30fps 24fps 20fps
36fps 30fps 24fps 20fps
Constraint-Driven, Platform-based Synthesis of
Communication Architectures
Point-to-Point
Channel
Communication
Requirements
Communication
Synthesis Architecture
Library of Implementation
pre-designed
Communication
Components
(platform)

ŒSystem modules communicate by means of point-to-point channels

ŒHigh-level communication constraints for each channel in the system are captured as
a Constraint Graph
ŒSimilarly, the characteristics of all
components in the Communication Library are
captured as a set of feature resources together with their cost figure
ŒThe synthesis result is represented by anImplementation Graph and obtained by
solving a constrained optimization problem
 Latency-Insensitive Design

RS
Relay Stations
P1 RS
RS
P3 RS

P2
P4

P5
RS
RS RS

Pearls (synchronous IP cores)

Shells (interface logic blocks) P6 RS
Channels (short wires)
P7
Channels (long wires)
Summary
‹ Main ideas
ΠFormal models emphasis
 SAN analysis reduces the gap between simulation and verification
ΠCommunication architectures can be synthesized from requirements

‹ Current research
ΠExploiting regularity in system-level analysis
 Efficient analysis enabled by symmetries (Nick Zamora)
‹ We expect orders of magnitude reduction in the complexity of the analysis
 Connect system-level analysis w/ lower levels of abstraction (Jingcao Hu)
‹ Efficient mapping techniques for regular architectures
ΠCommunication Architectures: On- and off-chip
 Analytical models for traffic analysis (Girish Varatkar)
‹ Architecture/design implications
‹ Build fast and realistic simulators
 Communication architecture synthesis (Luca Carloni, Alessandro Pinto)
 Protocol design for efficient on-chip communication (Luca Carloni, Tudor Dumitras)
Summary
‹ Interdisciplinary, intercontinental project (10 institutions in 5 countries)
‹ Goal:
ΠDesign methodologies: abstraction levels, design problem formulations
ΠEDA: formal methods for automatic synthesis and verification,
a modeling mechanism: heterogeneous semantics, concurrency
‹ Primary thrusts:
ΠMetropolis Meta Model:
 Building blocks for modular descriptions of heterogeneous semantics
 The internal modeling mechanism for function, architecture, and constraints
ΠDesign Methodology:
 Multi-media digital systems
 Wireless communication
 Fault-tolerant automotive systems
 Microprocessors
ΠFormal Methods
 Metropolis Project: Participants
‹ UC Berkeley (USA): methodologies, modeling, formal methods
‹ CMU (USA): methodologies, modeling, formal methods
‹ Politecnico di Torino (Italy): methodologies, modeling, formal methods
‹ Universita Politecnica de Catalunya (Spain): modeling, formal methods
‹ UC Riverside (USA): modeling, formal methods
‹ Cadence Berkeley Labs (USA): methodologies, modeling, formal methods
‹ PARADES (Italy): methodologies, modeling, formal methods
‹ ST (USA, France-Italy): methodologies, modeling
‹ Philips (USA, Netherlands): methodologies (multi-media)
‹ Nokia (USA, Finland): methodologies (wireless communication)
‹ BWRC (USA): methodologies (wireless communication)
‹ Magneti-Marelli (Italy): methodologies (power train control)
‹ BMW (USA, Germany): methodologies (fault-tolerant automotive controls)
‹ Intel (USA): methodologies (microprocessors)
‹ Cypress (USA): methodologies (network processors, USB platforms)
‹ Honeywell (USA): methodologies (FADEC)
References
• Platform-Based Design
• Alberto Sangiovanni-Vincentelli, “Defining Platform-Based Design”, EE Design, March
5, 2002.
• Alberto Sangiovanni-Vincentelli and Grant Martin, A Vision for Embedded
Systems: Platform-Based Design and Software Methodology, IEEE Design and Test of
Computers, Volume 18, Number 6, November-December, 2001, pp. 23-33
• K. Keutzer, S. Malik, A. R. Newton, J. M. Rabaey, and A. Sangiovanni-Vincentelli,
“System Level Design: Orthogonalization of Concerns and Platform-Based Design”,
IEEE Transactions on Computer-Aided Design, Vol. 19, No. 12, December 2000
• Metropolis
• F. Balarin et al., “Modeling and Designing Heterogeneous Systems”, in J. Cortadella
and A. Yakovlev editors, Advances in Concurrency and System Design, Springer-
Verlag, 2002.
• F. Balarin et al., “Constraints Specification at Higher Levels of Abstraction”, in
Proceedings of the IEEE International High Level Design Validation and Test
Workshop, Monterey, California, November 7-9, 2001.
References
• Quasi-Static Scheduling
• C. Passerone, Y. Watanabe, L. Lavagno, “Generation of Minimal Size Code for
Schedule Graphs”, Proceedings of the Design Automation and Test in Europe, Munich,
Germany, 2001.
• Cortadella et al: “Task generation and compile-time scheduling for mixed data-control
embedded software”, Proceedings of the 37th Design Automation Conference, Los
Angeles, CA, June 2000.
• Application Driven Scheduling
• L. Palopoli, C. Pinello, A. Sangiovanni Vincentelli, L. Elghaoui, A. Bicchi, “Synthesis of
robust control systems under resource constraints”, HSCC2002, Lecture Notes in
Computer Science, March 2002.
• Algebraic Theory
• J. Burch, R. Passerone, A. Sangiovanni-Vincentelli, “Using Multiple Levels of
Abstraction in Embedded Software Design”, Proceedings of the First International
Workshop on Embedded Software, Tahoe City, CA, October 2001.
• J. Burch, R. Passerone, A. Sangiovanni-Vincentelli, ”Overcoming Heterophobia:
Modeling Concurrency in Heterogeneous Systems”, Proceedings of Application of
Concurrency to System Design, Newcastle (UK), 2001.
References
‹ Power/performance analysis for platform-based design
ΠR. Marculescu, A. Nandi, L. Lavagno, and A. Sangiovanni-Vincentelli, 'System-Level
Power/Performance Analysis of Portable Multimedia Systems Communicating over
Wireless Channels', in Proc. ICCAD, Nov. 2001.
ΠA. Nandi, R. Marculescu, 'System-Level Power/Performance Analysis for Embedded
Systems Design', in Proc. DAC, June 2001.
ΠR. Marculescu, A. Nandi, 'Probabilistic Application Modeling for System-Level
Performance Analysis', in Proc. DATE, March 2001.

‹ On-chip communication
ΠG. Varatkar and R. Marculescu, 'Traffic Analysis for On-chip Networks Design of
Multimedia Applications', in Proc. DAC, June 2002.
ΠJ. Hu, Y. Deng, R. Marculescu, 'System-Level Point-to-Point Communication Synthesis
Using Floorplanning Information', in Proc. ASP-DAC, Jan. 2002.
References – continue
‹ Constraint-Driven Communication Synthesis
Œ A. Pinto, L.P. Carloni, and A. Sangiovanni-Vincentelli, ‘Constraint-Driven
Communication Synthesis’, in Proc. DAC June 2002.
‹ Latency-Insensitive Design
Œ L.P. Carloni, K. McMillan and A. Sangiovanni-Vincentelli, ‘Theory of Latency-Insensitive
Design’, IEEE Transactions On Computer-Aided Design, Vol. 20, No. 9, Sept. 2001.
Œ L.P. Carloni and A. Sangiovanni-Vincentelli, ‘Performance Analysis of Latency-
Insensitive Systems’, in Proc. DAC June 2000.
‹ Communication Driven Hardware Synthesis
ΠSRC Technical Report, Report on problem formulation, state of the art and theory
review, SRC Task 837.001, Sept. 2001
ΠSRC Technical Report, Report on Case Study Specification, SRC Task 837.001, Sept
2001
ΠGraduate Computer Architecture Project Report, Available at:
http://www.cs.berkeley.edu/~densmore/documents/252_Final.pdf