CAP Laboratory, SNU 1 PeaCE: Codesign Environment for Modeling, Simulation, and Synthesis of...
-
Upload
victoria-lawrence -
Category
Documents
-
view
216 -
download
0
Transcript of CAP Laboratory, SNU 1 PeaCE: Codesign Environment for Modeling, Simulation, and Synthesis of...
CAP Laboratory, SNU 1
PeaCE:PeaCE: Codesign Environment Codesign Environment ffor or Modeling, Modeling, Simulation, and Synthesis of Simulation, and Synthesis of Multimedia EmbMultimedia Emb
edded Systemsedded Systems
Soonhoi HaSeoul National University
CAP Laboratory, SNU 2
Outline
• Introduction• System Level Specification• PeaCE Demo• Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion
CAP Laboratory, SNU 3
Spectrum of Target Architecture
ProcessorCore
Memory
ASIC
CPU Add-onboard
System bus
MCU
interconnection
DSP
ASIC DSP
SOC(system on chip)
Distributedembedded system
CAP Laboratory, SNU 4
Design environment of embedded system
SystemFunction
SystemMicroarchitecture
mapping
Function on Microarchitecture
Implementationof system
Refine
Algorithm 개발- Functional Simulation
HW/SW 분할- 평가
Architecture 최적화검증
HW/SW /Interface합성
CAP Laboratory, SNU 5
Adhoc Design Procedure
시스템의 명세 전문가에 의한 구조의 결정
하드웨어의 개발 소프트웨어 개발
시제품 제작 및테스트
고비용 ,저효율설계 루프
알고리즘 시뮬레이션
ECAD tools
오류 정정 , 성능 개선
시제품 완성
SW 개발 tools
CAP Laboratory, SNU 6
Productivity Gap
Productivity Gap
Source: ©SEMATECH
CAP Laboratory, SNU 7
Technology Trend
1
10
100
1000
10000
100000
1000000
10000000
Algorithmic Complexity
(Shannon’s Law)
Processor Performance (~Moore’s Law)
Battery Capacity
Source: Data compiled from multiple sources (BWRC)
1G
2G
3G
CAP Laboratory, SNU 8
Conflicting Needs
• Unsatiable need for higher performance– Multiprocessors– Hardware + software architecture
• Higher energy efficiency– MIPS/mW is the first-class design objective
• Complexity management– Design space exploration– Design verification
• Increased design productivity– Reduce design cost and design time
• DSM (Deep-submicron) technology– Cross talk, electro-migration, wire-delay– Mask cost increases significantly– Need new CAD tools
CAP Laboratory, SNU 9
Needs of New Methodology
• [1] Kurt Keutzer, et. al. “System-Level Design: Orthogonalization of Concerns and Platform-Based Design," IEEE TCAD, 19(12), December 2000.
“we believe that the lack of appropriate methodology and tool support for modeling of concurrency in its various forms is an essential limiting factor in the use of both RTL and commonly used programming languages to express design complexity”
CAP Laboratory, SNU 10
HW/SW Codesign: Systematic Design
• Concurrent design of HW/SW components• Evaluate the effect of a design decision at early stage
HWSW
Integration
HW
SW
time
cost
time
cost
HW
SWIntegration
iteration
CAP Laboratory, SNU 11
HW/SW Codesign Procedure
System Specification
SW Synthesis
Interface Synthesis
HW SynthesisPrototyping
Algorithm simulation
(new deep submicron) CAD tools and SW Development Tools
Design Space Exploration
HW/SW partitioning
Architecture Optimization
Cosimulation/Coverification
CAP Laboratory, SNU 12
Design Validation
• By construction– property is inherent.
• By verification– property is provable.
• By simulation– check behavior for all inputs.
• By intuition– property is true. I just know it is.
• By assertion– property is true. Believe it.
It is generally better to be higher in this list
Need of formal specification
CAP Laboratory, SNU 13
PeaCE
• PeaCE– 서울대학교 컴퓨터공학부 CAP 연구실에서 개발된 통합설계 환경– 1990 년부터 개발된 Ptolemy 프로그램을 기반으로 함– DAC conference 에서 공개된 open-source 프로그램 (2000, 2003 년 )
– 학술적인 연구의 기반이 되는 시스템
• PeaCE home page– http://peace.snu.ac.kr/research/peace
– papers, manual, tutorial materials, etc
CAP Laboratory, SNU 14
PeaCE Methodology
• 2 key principles: design reuse and formal specification
• Block diagram representation– Reuse as many predefined blocks as possible
• Block diagram is drawn with a well-defined execution rule– Easy design maintenance
– Enable automatic system synthesis and easy design verification
CAP Laboratory, SNU 15
Software Structure
Client (Java)Server (c++, itcl)
PeaCE Daemon
PeaCE (Ptcl)
Library
Hae (GUI for PeaCE)
XServer(weirdX)
XServer(weirdX)
PeaCE
CAP Laboratory, SNU 16
PeaCE Will Help You
• Algorithm development– Functional simulation and performance estimation
• CASE tool for embedded software development– Developing a bug-free efficient C-code is not an easy task
– Code maintenance is important
• Hardware/software codesign
• Design space exploration for optimal architecture
CAP Laboratory, SNU 17
PeaCE vs Other Tools
• Matlab/Simulink– Good for algorithm development and system simulation– No good for system synthesis
• CASE tool (Rational Rose)– Visual modeling and software development tool using the UML (Unified M
odeling Language)– Not suitable for embedded software design: no performance guarantee
• Ptolemy II– Java program with strong simulation and modeling capability– Being developed as a CASE tool for embedded software – way to go
• CAD tools for hardware design– System modeling in C or HDL (VHDL, Verilog): too low level of abstraction
CAP Laboratory, SNU 18
Motivational Example• Multi-mode Multi-media Terminal Example
– Three modes of operation:
• Video phone: H.263 encoder/decoder and G.723 encoder/decoder
• Divx player: H.263 decoder and MP3 player
• MP3 player
Usercontrol
NetworkIF
Internet
Demux
H.263decoder
G.723decoder
Mux
H.263encoder
G.723encoder
camera
mic
Read filePacket decoder
H.263decoder
MP3decoder
MP3 decoder
Mode &Task
control
CAP Laboratory, SNU 19
Outline
• Introduction• System Level Specification• PeaCE Demo• Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion
CAP Laboratory, SNU 20
Where to start?
• System Level Specification– How to specify the system functionality?
• Issues– User friendliness
– Executable / simulatable
– Implementation Independence
– Design validation / error detection capability
– Design Maintenance and collaboration
– Well defined path to synthesis
CAP Laboratory, SNU 21
(Informal) Programming in C, C++?
• Not Good For Initial Specification. Why? – Imperative Language: 병렬화 하기 어렵다 .
Not good for HW implementation
– Simulation 에 의한 검증– Semantic error 찾기가 어렵다 . – 유지 , 보수가 어렵다 .
Code reuse is difficult.– 협력 작업이 어렵다 .
– Productivity is low
Need of Coding Rule: Software Engineering?
Formal Model of Computation
CAP Laboratory, SNU 22
We argue for “Formal Specification”
• CASE tool for software design– Coding rule for design maintenance and easy debugging
– Software design is a subset of system design
• Precise and unambiguous semantics– Functional specification: f (input, output, state)
– Well defined function composition
– Properties and Constraints
f() g()
Module or actor(function)
port
CAP Laboratory, SNU 23
Formal Specification Models
• Coarse-grain task based specification– A module is a task, also a partitioning unit
• Signal processing task should be partitioned manually into smaller sub tasks
– (ex) Kahn Process Network, CSP (Communicating Sequential Processes)
• Application specific specification– Control oriented application: FSM
– Signal processing application: Dataflow
– Network simulation: Discrete event (for simulation)
– Synchronous/reactive, PDE, etc
CAP Laboratory, SNU 24
Dataflow Representation of H.263 Encoder
• Intuitive representation: similar to algorithm flow-chart– suitable for multimedia/DSP applications
• Block reuse possibility• Implementation Independence
Delay – initial sample
MotionEstimation
DistributorMacroBlock
Encoding
VariableLengthCoding
MacroBlock
Decoding
MotionCompensation
WriteTo
Device
ReadFrom
Device
1 11 1 99 1 1
11991
1
99 1
1
CAP Laboratory, SNU 25
Formal Framework 의 장점• 설계 복잡도의 증가
– 엄정한 검증법의 개발이 필요 : “correct by construction”
• 설계 시간의 단축– Early discovery of ambiguities, omissions, and contradictions– 기존 설계의 재사용
• 공동 작업의 효율성– Concurrent and interactive design activities
• 최적의 설계– Design space exploration
• 유지 , 보수– Documentation
– Hierarchical and structural decomposition
CAP Laboratory, SNU 26
Formal Framework 의 단점• 새로운 명세 방법
– 새로운 것을 배우고 이해하고 적용하는 시간과 노력– 이득이 크면 문제가 되지 않을 것 ( 예 : CASE 도구 )
• 제한된 표현 능력– 시스템의 모든 기능을 다 표현할 수 있는가 ?– 제한된 응용에만 사용
• 합성의 비효율성– Refinement 결과가 manually optimized 결과보다 많이 나쁘다
• 현황– 응용에 특화된 설계도구만 개발됨– 기능의 시뮬레이션에 국한됨 . 합성까지 지원되는 도구의 부재
CAP Laboratory, SNU 27
Outline
• Introduction• System Level Specification• PeaCE Demo• Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion
CAP Laboratory, SNU 28
PeaCE Demos
• Multi-mode Multi-media terminal• Software synthesis for H.263 encoder• Hardware synthesis for H.263 decoder
CAP Laboratory, SNU 29
Demo 1. Multi-mode Multi-media Terminal
• Objective– This demo show how system-level specification of a complicated multi-mo
de multi-media embedded systems can be accomplished in PeaCE. And PeaCE automatically synthesizes a multi-threaded software from the specification for a given target platform
• System specification– Three modes of operation:
• Video phone: H.263 encoder/decoder and G.723 encoder/decoder• Divx player: H.263 decoder and MP3 player• MP3 player
– Demo platform• Compaq iPaq H3850 (StrongARM 206MHz) + Pentium 3 notebook• Xscale board + Xilinx FPGA
CAP Laboratory, SNU 30
System Level Specification
Video phone task DivX player task Mp3 player task
User interface
Video phone task DivX player task Mp3 player task
User interface
H.263 Encoder
G.723 Encoder G.723 Decoder
H.263 DecoderTCP/ IP
Video Phone taskH.263 Encoder
G.723 Encoder G.723 Decoder
H.263 DecoderTCP/ IP
Video Phone task
MP3 decoderDivX Player task MP3 decoderDivX Player task MP3 Player taskMP3 Player task
Top-level schematic
Mode control FSM
Three mode schematics:Each mode is a multi-task application.
CAP Laboratory, SNU 31
Demo Scenario
• Look over hierarchically nested block diagram specification.• Run the application and see the generated code.• Run the demo.
CAP Laboratory, SNU 32
Demo 2. Software Synthesis for H.263 Encoder
• Objective– This demo shows that PeaCE can generate high quality (= low memory re
quirement) embedded software for signal processing tasks from dataflow specification in PeaCE. Good performance is attributed to the extended SDF model (SPDF + FRDF) and a buffer sharing technique.
• Result Summary
Specification
Memory requirement(kB)
Reference (TMN 2.0)
361
SDF
686
SDF(b/s)
410
CSDF
291
FRDF
219
FRDF
225
CAP Laboratory, SNU 33
Dataflow Specification
• FRDF specification– Sample can be a
fractional number
• SPDF specification– Allow shared variable
between blocks– Can express
dynamic constructs
MotionEstimation
MacroBlock
Encoding
VariableLengthCoding
MacroBlock
Decoding
MotionCompensation
WriteTo
Device
ReadFrom
Device
11/99
1 1 1
1111/99
1/99
1 1/99
1
1/99
MotionEstimation
MacroBlock
Encoding
VariableLengthCoding
MacroBlock
Decoding
MotionCompensation
WriteTo
Device
ReadFrom
Device
1 9911 1
1
99
991
DistributorSDF specification
CAP Laboratory, SNU 34
Demo Scenario
• Look over hierarchically nested block diagram specification.
• Run the application and see the generated code.
CAP Laboratory, SNU 35
Demo 3. Hardware Synthesis for H.263 Decoder
• Objective– This demo shows the hardware synthesis capability from dataflow specific
ation (higher-level synthesis) in PeaCE.
• Synthesis result– Simulation Tool: ModelSim
– Synthesis Tool: Synplify Pro
– Target: Xilinx Virtex2 XC2V6000
– Register bits: 30407 (44%)
– Total LUTs: 59749 (88%)
– Estimated Frequency: 20.5 MHz
CAP Laboratory, SNU 36
Hardware Synthesis
• Input– FRDF specification
– Resource usage information + schedule information
• Features– Automatic controller generation
– Glue logic generation
– Resource sharing consideration
Schedule InformationNode : start_time exe_time
B : 0 10C : 0 8D : 10 5
DFGB
CDDFG
B
CD
BlockLibraries
B C DBlockLibraries
B C D controllerC
B
clk
rst D
controllerC
B
clk
rst D
CAP Laboratory, SNU 37
Demo Scenario
• Look over hierarchically nested block diagram specification.
• Run the application and see the generated code.
• Run the demo.
Y Block Decode ( rate : 4 )Dequantize, Inverse Zigzag, IDCT
V BlockDecode
U BlockDecode
MotionCompensation
Input File Read &VLD
Color Conversion &Output File Write
Libraries only for simulation using CLI
Y Block Decode ( rate : 4 )Dequantize, Inverse Zigzag, IDCT
V BlockDecode
U BlockDecode
MotionCompensation
Input File Read &VLD
Color Conversion &Output File Write
Libraries only for simulation using CLI
memory read
compute half pixel
memory write state
CAP Laboratory, SNU 38
Outline
• Introduction• System Level Specification• PeaCE Demo• Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion
CAP Laboratory, SNU 39
Key Messages
• System-level design environments (will) use some model of computation --- Understanding of the model of computation is essential to understand the capabilities of the design environment– FSM
– Dataflow
– Kahn Process Network
– Discrete Event
CAP Laboratory, SNU 40
FSM
• Well-known semantics• Rich analytical properties
– Reachability analysis, liveness
SystemUnderDesign
timer
time-out
power_on
ainit
on
done error
power_on/timer
time-outa
CAP Laboratory, SNU 41
Problems of Pure FSMs
• Flat and and unstructured• Inherently sequential
• very large number of states and transitions
• representation and analysis become difficult
Harel’s extension
(1) hierarchy (OR decomposition)(2) Concurrency (AND decomposition)
CAP Laboratory, SNU 42
FSM Hierarchy
• Structural description: does not reduce the number of states• Does reduce the number of transitions• What happens when input c and b both exist in state C?
– (one solution) external FSM take actions first.
A
a
b/v
C Dc/u
B
A BC
BD
a
b/v
b/v b’c/u
CAP Laboratory, SNU 43
AND Decomposition
• Concurrent execution of multiple FSMs• Solve state explosion problem • How to support inter-FSM communication?
– Internal events
AC BC
AD BD
ac’bc’
a
b
a’c b’cbcac
A B
C D
a
b
c
CAP Laboratory, SNU 44
Example : Traffic Light
hierarchy
concurrency
CAP Laboratory, SNU 45
Design Frameworks
• iLogix STATEMATE– Statechart
• UC Berkeley POLIS– CFSM: Codesign FSM
CAP Laboratory, SNU 46
iLogix’s STATEMATE
• Control-oriented reactive applications
FUNCTIONALITYfunctional decomposition
& information flow
FUNCTIONALITYfunctional decomposition
& information flow
BEHAVIORcontrol and
temporal relation
BEHAVIORcontrol and
temporal relation
STRUCTUREphysical decomposition
STRUCTUREphysical decomposition
activity chart statechart
module chart
Conceptual model
CAP Laboratory, SNU 47
Harel’s Statechart
• D.Harel, “Statecharts: A visual formalism for complex systems”, Science of Computer Programming, Vol. 8, pp. 231-274, 1987.
• Hierarchy, AND decomposition, reset states• Transitions are NOT level restricted.• Perfect synchrony hypothesis
A
B
C
D
E
x
y
z
w
F
G
H
u
CAP Laboratory, SNU 48
Activity chart
• 3 types of objects– transformation
– data-store
– control activity (content: Statechart)
• 2 types of arcs– dataflow: solid line
– control flow: dashed line
• connection between activity chart and statechart– transition labeling (ex)
– forms language
T
C
D
Statechartinside
S1 S2suspend(T)
CAP Laboratory, SNU 49
POLIS: Codesign FSM
• Politecnico di Torino, Italy and U.C.Berkeley CAD group -Alberto Sangiovanni-Vincentelli et. al.
• CFSM– Formal model as an intermediate representation during the system design
process. (relatively small real-time control systems)
• Front-end specification: Esterel, StateCharts, a subset of VHDL
– Low level enough to be efficiently co-synthesized.
– a network of interacting FSMs
– FSMs communicate through “events”
• broadcast communication model
– each computing element takes a non-zero unbounded time
CAP Laboratory, SNU 50
CFSM Example
• Five seconds after the key is turned on, if the belt has not been fastened, an alarm will beep for ten seconds or until the key is turned off.
WAIT
OFF
ALARM
*KEY=OFF or*BELT = ON => *END = 5 =>
*ALARM = ON
*KEY=ON =>*START
*END = 10 or*BELT = ON or*KEY = OFF =>*ALARM = OFF
TimerFSM
*START
*TICK
*END
CAP Laboratory, SNU 51
ACFSM
• Abstract CFSM– CFSM is too low level
– A network of (extended) FSMs over an unbounded FIFO channel
• Homogeneous framework to specify both DF and control aspects– Finite state coordinates multirate transitions and data-intensive computati
ons
CAP Laboratory, SNU 52
Key Messages
• System-level design environments (will) use some model of computation --- Understanding of the model of computation is essential to understand the capabilities of the design environment– FSM
– Dataflow
– Kahn Process Network
– Discrete Event
CAP Laboratory, SNU 53
Synchronous Dataflow
enabled fired
1 1
1
UPSAMPLE
2
1
UPSAMPLE
enabled fired
DOWNSAMPLE
1
2
DOWNSAMPLE
CAP Laboratory, SNU 54
Synchronous Dataflow Model
• Useful to describe Multi-rate DSP algorithms• A node represents a function block (ex: FIR, DCT) • An arc represents the data dependency (FIFO queue)• A block is fireable (executable when it receives all required number of i
nput samples) • Statically scheduled at compile-time.
A B
C
D2
11
1
1 2 1 1Repetition counts: A(2),B(1),C(2),D(1)Schedule: A-C-A-C-B-D
Buffer size: AB(2), AC(1), CD(2), BD(1)
CAP Laboratory, SNU 55
SDF Scheduling
• repetition counts– A: 3 B: 2 C: 4
• Valid schedules are not unique because the graph describes the partial order (true dependency) between blocks– (ex) AABCCABCC – schedule for minimum buffer size– (3A)(2(B(2C))) – schedule with loop structure
• What is the best schedule?– Depends on the design objectives– (informal) programming describes just one schedule – no quarantee of opt
imality !!
A B C2 3 2 1
CAP Laboratory, SNU 56
Syntax check
• Sample rate inconsistency– Some arc accumulates tokens without bound
• Deadlock– Graph can not start its execution
A B
C
1 1
1 2
1 1 A
B1
1
1
1
CAP Laboratory, SNU 57
Design Frameworks
• SPW: Alta group of Cadence (Comdisco)• COSSAP: Synopsis (Cadis)• Grape-II (or Virtuoso Synchro) from Intelligent Systems, Belgium
– Use CSDF: Cyclo Static Data Flow
A
B
C
1,0,0
1,1 0,2
1
1,1,1 3
CAP Laboratory, SNU 58
SDF Limitations
• Expression Capability– SDF model can not express control structures (dynamic constructs) such
as conditional execution and data dependent iteration
• SDF model does not allow shared memory (global states) between blocks due to side effect. – why? memory update order may vary depending on the schedule.
• SDF model does not allow pointer operation, but copies structured data as a token.
CAP Laboratory, SNU 59
Data Dependent Iteration
• Dynamic dataflow: sample rate changes at run-time
UpSample
DownSample
A
y
xc
SDF ?c
CAP Laboratory, SNU 60
Need of Global States
• Arises in many multimedia applications.– MP3 decoder, OpenGL machine
Frame Header Subband samples
MPEG-1 frame structure
MPEG-1 decoder structure
PacketDecoder
(PD)HuffmanDecoding Dequantize
InverseMDCT
SynthesisFilterbank
block_type global_gain subblock_gain[] scale_table[]
Sync,systeminformation
Sideinformation
Scalefactors
PacketDecoder
(PD)
Use shared global states!
State update (SU) request
CAP Laboratory, SNU 61
H.263 Example
• SDF model has inherent limitation of handling the mixture of composite data type and its constituents(example: video frame and macro blocks)
ME 1 D EN1 99 1 1currentframepreviousframe
11
SDF 119
176x144 99x(16x16)
Schedule : (ME,D)99(EN)
CAP Laboratory, SNU 62
Buffer Requirement
• Reference Code: Telenor “tmn”– Code clean-up: remove other options and make the code compact for fair
comparison
– Change dynamic allocation to static allocation
• Experiments with Armulator
Reference code SDF basic
global
stack
Total (kB)
358.5
2.5
361
38
648
686
Buffer size is largely dependent on the number of framestructures the code defines.
CAP Laboratory, SNU 63
Kahn Process Networks
• Blocking read, non-blocking write• Concurrent processes communicate only through one-way FIFO channe
ls with unbounded capacity.
AB
C D
Determinate: independent of execution order of A and B
{ read AC read BC }
CAP Laboratory, SNU 64
User Control
StreamParser
MPEGDecoder
ImageDisplaydata path
data path data pathdata path
control path control path control path
Design Framework : COSY
• IP-based real-time design methodology• YAPI: extension of the Kahn process network model
– Kahn process network + “select” operation
• coarse grain mix-and-match of several IP blocks
CAP Laboratory, SNU 65
YAPI
• Processes– read, write are blocked when data is not available or cannot be delivered
– “select” takes two input ports as input and returns a port ID, If neither input port has data available, it blocks. If both have, select one non-deterministically.
• Directed FIFO• Process network
n = select (in1, in2)if (n == 0) { read (in1, x); f1(x);} else if (n == 1) { read (in2, y); f2(y);}Code fragment
CAP Laboratory, SNU 66
Key Messages
• System-level design environments (will) use some model of computation --- Understanding of the model of computation is essential to understand the capabilities of the design environment– FSM
– Dataflow
– Kahn Process Network
– Discrete Event
CAP Laboratory, SNU 67
Discrete-Event Model
• Event-driven Simulation– Processing events in the chronological order
– Reveal the system dynamic characteristics
• Application– (queueing) network simulation, hardware simulation
AB
C
A-C, 5us, 1.0B-C, 5us, 0.0B-C, 2us, 3.0A-C, 1us, 2.0
EventQueue
event path event time value
CAP Laboratory, SNU 68
CAD Tools for System-level Design
• Co-verification Tools– Transaction level verification for fast design space exploration
• CoWare ConvergenSC, Synopysis CoCocentric System Studio
• SystemC software simulator + TLM model + C based hardware simulator
• Execute 100K instructions/second
• 15% error bound
– RTL level verification
• Mento Graphics Platform Express + Seamless CVE
• ISS + wrapper + RTL channel model + RTL HW model
• Time accurate simulation
• Execute 1K instructions/second
CAP Laboratory, SNU 69
CoCentric System Studio
• Synopsys’s SystemC Design and Verification tool suite– SystemC simulator and specification environment at multiple levels of abst
raction
– Joint verification and analysis of algorithms, architectures, hardware, and software
• System Specification– Hierarchical, graphical and language abstractions – unlimited hierarchical
composition of dataflow graphs (DFGs) and finite state machines (FSMs)
• Dynamic data flow + hierarchical and concurrent FSM(cf) *-chart
– Block specification: C, C++, or SystemC
CAP Laboratory, SNU 70
Synopsys CoCentric System Studio
• Verification at multiple levels of abstraction with SystemC• Untimed functional level
– Models communicate with each other in a point-to-point fashion using FIFO– Arbitrarily nested dataflow (Dynamic Data Flow) and FSM models
• Timed functional level– Delay annotation to functional models: use wait(sc_time) or next_trigger(sc_time) st
atements– Still assume point-to-point communication
• Transaction level model (TLM) or Bus cycle accurate level– Model communication infra-structure (its behavior) in terms of transaction – Pin-level adapter translates between transactions and hardware signals to run with
RTL HW model if desired– Good for SW development in SoC context
• Pin accurate level (Behavioral hardware model)• Register transfer level
CAP Laboratory, SNU 71
Synopsys CoCentric System Studio
CAP Laboratory, SNU 72
Mentor Graphics Seamless CVE
• Optimization– Fetch optimization: make instruction fetches (~200 insts/sec)
– Memory optimization: suppress unnecessary memory accesses (~1K insts/sec)
– Time optimization: suppress clock synchronization (~10K insts/sec)
SW debugger
ISS
Coverificationkernel
HW Simulator
BIM
Mem HWchannel
CoherentMemory server
CAP Laboratory, SNU 73
Seamless C-Bridge Technology
• Accelerated verification• Mixture of RTL and C models of
hardware
CAP Laboratory, SNU 74
Mentor Platform Express
GUI for platform and IP selection Interface code generation for Seamless CVE
CAP Laboratory, SNU 75
Codesign Tool Summary
• It’s time for co-verification tools – Most competitive market
• No system-level design framework yet– No consensus on system level specification
– Manual partitioning and platform selection
CAP Laboratory, SNU 76
Outline
• Introduction• System Level Specification• PeaCE Demo• Inside PeaCE • Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion
CAP Laboratory, SNU 77
system specification(SPDF + fFSM + BP)
system specification(SPDF + fFSM + BP)
fFSM tasksfFSM tasks
SPDF tasksSPDF tasks
C-code synthesis
SW performanceestimation
database update
component selectionand mapping
component selectionand mapping
architecturespecification
architecturespecification
Block-PEDB
Block-PEDB
partitionedSPDF graph
partitionedSPDF graph
partitionedSPDF graph
partitionedSPDF graph
HW code synthesis HW/SW synthesis
code synthesis
ISS for SWISS for SW
HW simulatorHW simulator
cosimulation / coverificationcosimulation / coverification
prototypingprototyping
trace generationtrace generation
architectureoptimization
architectureoptimization
ISSISS
C codeC codeRTL codeRTL code RTL codeRTL code
channelmodel
channelmodel
SW code synthesis
static analysis &functional simulation
static analysis &functional simulation
PeaCECodesignWorkflow
CAP Laboratory, SNU 78
Modularized PeaCE: Basic
• Functional Simulation
• Manual Mapping
• Software synthesis
• Hardware synthesis
FunctionArchi-
tecture
mapping
SW HW
Block / componentlibrary
Other CAD tools
CAP Laboratory, SNU 79
System-level Specification
A2 B C D
A1
E
Ff1 f2
B1B2
B3
snd
sndrcv
rcv D1rcv
rcvsnd
fFSM
Dataflow wormholeDataflow wormhole (super-block withdifferent domain inside)
Backplane: Discrete Event
Eventgenerators
Display
CAP Laboratory, SNU 80
PeaCE Technique
• SDF Extension for Memory Optimization– FRDF (Fractional Rate Data Flow)
– Buffer Sharing
• SDF Extension to enhance expression capability– SPDF (Synchronous Piggybacked Data Flow)
• RTL-level HDL Synthesis from FRDF + SPDF
• fFSM: Hierarchical and Concurrent FSM Model– A variant of statechart
CAP Laboratory, SNU 81
Reminder
• SDF model is poor in performance when dealing with composite data types
ME 1 D EN1 99 1 1currentframepreviousframe
1
1
SDF 11
9
176x144 99x(16x16)
Schedule : (ME,D)99(EN)
CAP Laboratory, SNU 82
Fractional Rate Dataflow
Schedule : 99(ME,EN)
The macro block is 1/99 of the video frame in its size.
For each execution of the ME node, it consumes a macro-blockfrom the input frame, and produces a macro-block output.
ME1
EN1 1
1/99
1/99 16x16
CAP Laboratory, SNU 83
Synchronous Piggybacked Dataflow
• global structure for global states with limited access• each data sample is piggybacked with an SU request• a block updates its internal parameters depending on
applicability of SU request
PD A B C
“gain”= 5
SU
data
piggyback
202nd iteration
“gain”= 10
C
“gain” 10
….
State name 1st iteration
CAP Laboratory, SNU 84
For construct in SPDF
• Dynamic FRDF star at the boundary
UpSample
DownSample
A
y
xc
PB
c
y
type:forconName: ix
name:ixperiod:1offset:0
galaxy state :ixx
Up1/c
A
Down1/c
count: ix
CAP Laboratory, SNU 85
Hardware Synthesis in PeaCE
• Input– FRDF specification
– Resource usage information + schedule information
• Features– Automatic controller generation
– Glue logic generation
– Resource sharing consideration
Schedule InformationNode : start_time exe_time
B : 0 10C : 0 8D : 10 5
DFGB
CDDFG
B
CD
BlockLibraries
B C DBlockLibraries
B C D controllerC
B
clk
rst D
controllerC
B
clk
rst D
CAP Laboratory, SNU 86
FunctionArchi-
tecture
SW HW
Block / componentlibrary
PeaCE-Map( 가칭 )mapping
PeaCE-DSE( 가칭 )up simulator
Design Space Exploration in PeaCE
CAP Laboratory, SNU 87
communication model
I/O DSP ASIC
micro controller IP
Architecture Graph and Mapping
A2 B C D
A1
E
F
IP
Architecturegraph
Algorithmgraph
SW 합성HW 합성
CAP Laboratory, SNU 88
Partitioning Problem
HW
DSP
PE1
MEM
A DB
C
Component library
Input task graph
PE1
HW
Component selection
A
B
D
C
Mapping Scheduling
HW
PE1 A
C
B D
Is architecture given?
CAP Laboratory, SNU 89
Current Status
Fixed architecture
Synthesizable architecture(component selection, interface synthesis, memory structure synthesis)
Problem space Solution space
PartitioningalgorithmsConstraints
(HW area, power, timing,memory)
Input specification(fixed acyclic task graph,time-shared multiple task graph)
Heuristics : list scheduling, clustering hardly extensiblewell-formulated techs: simulated annealing, genetic algorithm)mathematical programming : ILP too time consuming
CAP Laboratory, SNU 90
PeaCE Cosynthesis Framework
Success
Heterogeneous Multiprocessor Scheduler
Block-PE Allocation Controller
performance eval. &schedulability analysis
Fail
SPDF graphs
{Pm }{Pn }
Block-PE table
Block-PE DBArchitecture/platform
partitioned SPDF graphs
CAP Laboratory, SNU 91
FunctionArchi-
tecture
mapping
SW HW
Block / componentlibrary
PeaCE-SIM ( 가칭 )
Up simulator HW simulator IP simulator
Cosimulator in PeaCE
CAP Laboratory, SNU 92
Distributed Cosimulation
processorsimulator B
IPsimulator C
hardwaresimulator D
micro-controllersimulator F
A2
A1
E
BP
communication channel
Two issues: Timing Synchronization Data Synchronization
VHDL codeC code
CAP Laboratory, SNU 93
Solutions for Timing Synchronization
• Conservative Approach
• Optimistic Approach– Roll-back mechanism
– Large overhead: state savings at check points + roll-back
– Simulators should support roll-back mechanism
• Conservative/Distributed Cosimulation– Virtual Synchronization in PeaCE
CAP Laboratory, SNU 94
Conservative Approach
1
1
2
2
3
3
4
4
5
5
6
6
7
7
8
8
9
9
synchronization point
simulation time
HW
SW
Synchronize simulators at every simulated time Pros : simple Cons : huge synchronization overhead
n nth time unit of simulator
synchronization time
CAP Laboratory, SNU 95
Virtual Synchronization Technique
• Component simulator clock is NOT synchronized with the global clock of the channel
• Exchanged data is still associated with the CORRECT time stamp
SWsimulator
HWsimulator
Channel
Wrapper Wrapper
CAP Laboratory, SNU 96
Time Adjustment in Wrapper
1 2 3 4
2
6 7 85HW
SW
simulation time
1
(0,0) 0+4 (4) 4+1 (5,8) 8+4 (12) 12+1wrapper
HWB (4)
SWC (1)
SourceA (8)
local time
local time
global time
CAP Laboratory, SNU 97
Design Workflow in PeaCE
기능Status
Done 구현중 개발중
Functional Simulation
Block performance estimation
Component Selection and Mapping
SW/HW/Interface synthesis SW HW
Architecture Optimization
HW/SW Cosimulation and Coverification
Prototyping
CAP Laboratory, SNU 98
Conclusion
• PeaCE 의 특징– Dataflow + FSM + DE Model 로 전체 시스템을 명세한다– Simulation 과 Synthesis 기능을 제공한다 .
– Simulation capability 가 뛰어나다– Open source program, easy customization
– Stable system: 검증된 Ptolemy tool 에 기반함
• Experience on System-level Design Environment Development – 진입장벽이 높다 .
– Inter-disciplinary work
– Abundant research topics but only a few commercial products
– Feedback 이 필요