1. Communication-Based Design

2. Why is System Design difficult?
Semiconductor capability has outstripped design capability
High-end consumer electronics (time-to-market) is driving the most complex chips now
Consumer products combine multiple vastly disparate application areas (heterogeneity):
video
DSP
analog
protocols
Nobody can possibly know all these areas in depth

3. Coping with Complexity
Decomposition
of the problem: separation of concerns
of the object: exploit compositionality
Formalization
precise unambiguous semantics
properties and formal techniques
Abstraction
eliminate unnecessary details
Incremental Refinement
include details while preserving properties

4. Coping with Complexity
Automatic Synthesis
Formal Verification
Simulation
Design Reuse - IP

5. Why separating computation and communication?
Verification (debugging). If not:
Communication hard-wired with computation
Often hard to tell who is at fault
Bugs may be distributed, difficult to track down
Changes in the system may require rewriting of entire blocks, often leading to new bugs
Reuse
Component may be plugged in different environments
Functions and interface behavior are difficult to separate
Architecture exploration
Design components with abstract communication primitives
Explore different implementations without touching the component

6. Orthogonalizing Communication from Behavior
Historically lots of work on Behavior
hierarchy well established
several descriptions available (with variable levels of precision)
synthesis
Communication less well investigated
hard to separate from behavior, usually intertwined
telecomm protocols are the best existing example
Need to understand Formalism, Abstraction, and Refinement for communication

7. Formalism, Abstraction, and Refinement
Formalism for Communication
Precise semantics for complex transactions
Multi-way communication, arbitration, addressing
Distributed control
Abstraction and Refinement
Complex transaction mapped onto more primitive transactions
Elements of transaction refined onto concrete resources (pins, times)

8. Phone call

9. Decomposition of Phone Call
Connect
Talk
Disconnect
ATM Cell
Bus Write

10. Refinement - Simple
substitute
repartition

11. Refinement - More Complex
200
1000 1

12. Abstraction Performance Model Abstraction Levels
Budget number, constant
Stochastic model with variation
Estimation based on approximate use of lower level abstraction
Actual simulation using lower level abstraction

13. Properties and Refinement
Each model of computation guarantees some properties
Protocols also imply properties
out of order, error correction, reliable packet delivery
As you refine, must preserve properties
if order must be preserved
can refine to out-of-order communication method (like ethernet)
but have to reassemble in proper order

14. Elements of Refinement
Time vs Space
fewer resources means spreading out over time
extra handshaking means spreading out over space
Arbitration
sharing resource between independent communication paths
data dependent arbitration
Uneven source/sink speeds may require buffering
Access to & storage for buffer memories may be shared
address computation
arbitration again

15. MPEG Algorithm Audio Decode Audio In Video In Video Decode
Frame buffer
Onscreen Display
Host I/F
Video out

16. MPEG Architecture Audio Decode Audio In Video In Video Decode
Onscreen Display
Host I/F
Video out
MMU/AGU
Memory
buffers + frame buffer
shared bus
Registers

17. Description Method Algorithm Map Architecture Audio Decode Audio In
Video In
Video Decode
Frame buffer
Onscreen Display
Host I/F
Video out
Algorithm
Audio In
Audio Decode
Video In
Video Decode
Onscreen Display
Host I/F
Video out
MMU/AGU
Memory
Registers
Architecture
Map

18. Simulation Speed - Cheetah
Take advantage of abstraction and decomposition
Note that protocol has “anchor points”
timing is data or contention dependent
other actions shift with constant offset from anchor
Should only need to simulate the anchor points
Constant offset actions are “inevitable” and can be abstracted
GUI can recreate inevitable behavior on demand
Replacing non-branching state sequences with delay
Source: James Rowson

19. ATM Example Tokens Transactions Values C T C T C T
Source: James Rowson

20. ATM Example
Must simulate the bus, because contention is a major factor
Can abstract away the PI bus detail because
anchor point is when arbitration grants master the bus
might be another anchor point when slave is ready (here constant time)
all other actions follow with constant offset from these
Important to note that cell creator and transmitter code is unmodified in these examples
Source: James Rowson

21. Cheetah Most Abstract
Source: James Rowson

22. Mapping ATM cell onto Bus
53 bytes
Token
decompose
Bus
write 500
write 501
...
Source: James Rowson

23. Cheetah Abstract Bus - burst == 1
Expand
Source: James Rowson

24. Cheetah Abstract Bus - burst == 10
Expand
Source: James Rowson

25. Cheetah PI Bus - burst == 1
Expand
Source: James Rowson

26. Cheetah PI Bus - burst == 10
Expand
Source: James Rowson

27. Zoomed In
Source: James Rowson

28. Cheetah - Performance Most abstract 38x faster than most detailed
measured by CPU time
Most detailed (PI bus, burst==1) expands by 7x
each bus transaction expands into 7 “assignments” in history
Postulate performance comparison with HDL
dominated by event traffic
event traffic proportional to size of simulation history
can compare relative performance through history expansion
Worst case is 7x performance improvement over HDL
as bursts get longer, get proportionally better performance
Source: James Rowson

29. Cheetah Performance Analysis
Space == # wires
Time = # clocks
Speedup ~ space expansion * time expansion
as burst size increases, so does speedup
Source: James Rowson

30. Metropolis Metropolis Project Team University of California Berkeley
Cadence Berkeley Laboratories
etropolis

31. Design of Communication Media Architecture Components
Metropolis Framework
Design of
Function Processes
Design of Communication Media
Design of
Architecture Components
Metropolis Infrastructure
Model of computation
Design methodology
- Abstraction levels
- Refinement
Base tools
- Design imports
- User interface
- Simulation
Metropolis Point Tools:
Synthesis/Refinement
Metropolis Point Tools:
Analysis/Verification

32. Metropolis: Model of Computation
System function: a network of processes
process: sequential function + ports
Do not commit to particular communication semantics
ports: interconnected by communication media
communication media: define communication semantics
e.g. queues, shared memory, … , generic, ...
Do not commit to particular firing rules of processes
a special construct to define interaction between processes and media CM CM CM

33. Design Methodology Functional Decomposition Behavior Adaptation
Communication Media Insertion
MoC Wrapping
Communication Refinement
Channel Adaptation
Mapping and Optimizations

34. Functional Decomposition
at the highest abstraction level, a system is a single process
it is refined into a set of concurrent processes
Process:
relation between an input domain and an output co-domain
only behavior, no communication
denotational specification
System P2 P1 P4 P5 P3

35. Functional Decomposition (ex.)
MPEG Decoder
VLD
IDCT MC
DISPLAY

36. Behavior Adaptation Behavior adapters
match different domains, so that processes can understand each other
relation between two domains
not part of original system specification: needed because of the particular decomposition
needed independently of how the communication is performed P1
relation
Output
domain
behavior
adapter
Input
domain P2
relation P2 P1 BA P4 P5 P3 BA

37. Behavior Adaptation (ex.)
vect
VLD
blkvect
IDCT
Mblock MC
Mblock
DISPLAY
block
block
Frame
mot. vect
mot. vect
VLD
IDCT MC
DISPLAY BA
IZ,IQ BA
MEM BA
MEM

38. Communication and MoC Communication medium MoC wrapper
each link needs a communication medium
does not affect or change the relation inside processes
MoC wrapper
used to establish a firing rule and a communication semantics for each process
only the Moc wrapper is modified if a medium is changed P2 P1 BA CM CM P4 CM CM CM P3 P5 BA CM CM W CM CM P CM CM CM P

39. Communication and Moc (ex.)
VLD
IDCT MC
DISPLAY BA
IZ,IQ BA
MEM BA
MEM
VLD
IDCT MC
DISPLAY CM BA
IZ,IQ CM CM BA
MEM CM CM BA
MEM CM CM

40. Refinement Refinement Channel adapters
any communication medium can be refined into an arbitrary netlist, as long as the interface is not changed
Channel adapters
used to preserve properties of a given interface
example:
lossless communication realized with a lossy medium
( retransmission + acknowledge) P2 P1 BA CM CM P4 CM CM CM P3
Lossless P5 BA CM CM
Lossy CA CA CM CM CM CM

41. Refinement (ex.) VLD MC DISPLAY VLD MC DISPLAY IDCT IDCT CM CM CM CMBA
IZ,IQ CM CM BA
MEM CM CM BA
MEM CM CM
VLD
IDCT MC
DISPLAY BA
IZ,IQ CM BA
MEM CM CM BA
MEM CM CM CM CM CM CM CM
SEG
SEG
REAS
SEG
REAS
REAS CM CM CM CM CM CM
ARB
ARB
ADDR
ARB
ADDR
ADDR
BUS

42. Mapping and OptimizationCM P1 P2 BA P5 P3 P4 CA
Lossless
Lossy
Optimization
map each element (processes, adapters, media) onto architecture
merge processes, adapters and media into a single process, when applicable
provide an imperative description for each process

43. Mapping and Optimization (ex.)
VLD
IDCT
MC’
DISPLAY BA
IZ,IQ CM CM CM CM CM CM CM CM
SEG
SEG
REAS
SEG
REAS
REAS CM CM CM CM CM CM
ARB
ARB
ADDR
ARB
ADDR
ADDR
BUS MC BA
MEM CM CM BA
MEM