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


Outline

• Introduction• System Level Specification• PeaCE Demo• Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion


Spectrum of Target Architecture

ProcessorCore

Memory

ASIC

CPU Add-onboard

System bus

MCU

interconnection

DSP

ASIC DSP

SOC(system on chip)

Distributedembedded system


Design environment of embedded system

SystemFunction

SystemMicroarchitecture

mapping

Function on Microarchitecture

Implementationof system

Refine

Algorithm 개발- Functional Simulation

HW/SW 분할- 평가

Architecture 최적화검증

HW/SW /Interface합성


Adhoc Design Procedure

시스템의 명세 전문가에 의한 구조의 결정

하드웨어의 개발 소프트웨어 개발

시제품 제작 및테스트

고비용 ,저효율설계 루프

알고리즘 시뮬레이션

ECAD tools

오류 정정 , 성능 개선

시제품 완성

SW 개발 tools


Productivity Gap

Productivity Gap

Source: ©SEMATECH


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


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


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”


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


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


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


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


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


Software Structure

Client (Java)Server (c++, itcl)

PeaCE Daemon

PeaCE (Ptcl)

Library

Hae (GUI for PeaCE)

XServer(weirdX)

XServer(weirdX)

PeaCE


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


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


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


Outline



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


(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


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


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


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


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


Formal Framework 의 단점• 새로운 명세 방법

– 새로운 것을 배우고 이해하고 적용하는 시간과 노력– 이득이 크면 문제가 되지 않을 것 ( 예 : CASE 도구 )

• 제한된 표현 능력– 시스템의 모든 기능을 다 표현할 수 있는가 ?– 제한된 응용에만 사용

• 합성의 비효율성– Refinement 결과가 manually optimized 결과보다 많이 나쁘다

• 현황– 응용에 특화된 설계도구만 개발됨– 기능의 시뮬레이션에 국한됨 . 합성까지 지원되는 도구의 부재


Outline



PeaCE Demos

• Multi-mode Multi-media terminal• Software synthesis for H.263 encoder• Hardware synthesis for H.263 decoder


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


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.


Demo Scenario

• Look over hierarchically nested block diagram specification.• Run the application and see the generated code.• Run the demo.


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


Dataflow Specification

• FRDF specification– Sample can be a

fractional number

• SPDF specification– Allow shared variable

between blocks– Can express

dynamic constructs

MotionEstimation

MacroBlock

Encoding


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


MacroBlock

Decoding

MotionCompensation

WriteTo

Device

ReadFrom

Device

1 9911 1

1

99

991

DistributorSDF specification


Demo Scenario

• Look over hierarchically nested block diagram specification.

• Run the application and see the generated code.


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


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


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


Outline



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


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


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)


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


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


Example : Traffic Light

hierarchy

concurrency


Design Frameworks

• iLogix STATEMATE– Statechart

• UC Berkeley POLIS– CFSM: Codesign FSM


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


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


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)


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


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


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


Key Messages


– Dataflow


– Discrete Event


Synchronous Dataflow

enabled fired

1 1

1

UPSAMPLE

2

1

UPSAMPLE

enabled fired

DOWNSAMPLE

1

2

DOWNSAMPLE


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)


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


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


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


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.


Data Dependent Iteration

• Dynamic dataflow: sample rate changes at run-time

UpSample

DownSample

A

y

xc

SDF ?c


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


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)


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.


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 }


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


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


Key Messages


– Dataflow


– Discrete Event


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


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


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


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


Synopsys CoCentric System Studio


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


Seamless C-Bridge Technology

• Accelerated verification• Mixture of RTL and C models of

hardware


Mentor Platform Express

GUI for platform and IP selection Interface code generation for Seamless CVE


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


Outline

• Introduction• System Level Specification• PeaCE Demo• Inside PeaCE • Formal Specification Models and Design Frameworks• Design Workflow in PeaCE • Conclusion


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




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


Modularized PeaCE: Basic

• Functional Simulation

• Manual Mapping

• Software synthesis

• Hardware synthesis

FunctionArchi-

tecture

mapping

SW HW

Block / componentlibrary

Other CAD tools


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


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


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)


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


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


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


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


FunctionArchi-

tecture

SW HW


PeaCE-Map( 가칭 )mapping

PeaCE-DSE( 가칭 )up simulator

Design Space Exploration in PeaCE


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 합성


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?


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


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


FunctionArchi-

tecture

mapping

SW HW


PeaCE-SIM ( 가칭 )

Up simulator HW simulator IP simulator

Cosimulator in PeaCE


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


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


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


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


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


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


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 이 필요

Date post:	17-Jan-2016
Category:	Documents
Upload:	victoria-lawrence
View:	214 times
Download:	0 times

CAP Laboratory, SNU 1 PeaCE: Codesign Environment for Modeling, Simulation, and Synthesis of...

Documents